具有源代码控制的 Websphere Commerce 开发设置
我还不熟悉 Commerce Server 及其开发工具。 据我所知，其中包含一个数据库，用于保存正在出售的东西。 是否可以建立一个开发基础设施，其中有一台测试服务器和多个开发工作站，并且让它们共享数据库？ 我还会有一个单独的服务器来容纳 CVS 存储库，多个开发人员将手动从 CVS 服务器拉取、工作并签入。 测试服务器上的构建和部署工具将从 CVS 中提取，并部署到测试服务器。 我关心的是共享数据库，每个开发工作站是否都需要它自己的数据库？ 寻找有关如何最好地处理多个开发人员、一台测试服务器和一个源代码控制系统的总体概述。
I'm not yet familiar with Commerce Server and it's dev tools.
I understand that there is a DB included, to hold the things being sold.
Is it ok to set up a dev infrastructure where there is one test server and multiple dev workstations, and have these share the DB?
I would also have a separate server that housed a CVS repo, and the multiple dev people would manually pull from the CVS server, do work, and check in.
The Build and Deploy tool on the test server would pull from CVS, and deploy to the test server.
My concern is the shared DB, and does each dev workstation need it's own DB?
Looking for a general outline on how to best handle multiple devs, one test server, and a source control system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我从来没有尝试共享数据库，但我认为这不是一个好主意，因为所有开发环境都可以覆盖其他开发更改（在数据库中）。
如果开发人员必须修改数据库结构，那可能会伤害每个人。
我建议每个开发环境都有一个数据库，不必与测试环境相同。
对于您的测试服务器的构建和部署来说是很好的。
I never try to to shared the database, but I don't think it's a good idea, since all dev environment could override other dev changes (in DB).
And if a developper must modify the database structure, that could hurt everyone.
I suggest to have a database on each dev environment, not necessary to be the same as the test one.
For your build and deploy for test server is good.
这要看团队有多大？在我工作的大多数小型项目中，团队中的每个人都有自己的数据库，特别是当数据库是 Derby/Cloudscape 时，但当涉及使用 DB2 或 Oracle 的大型项目时，始终建议使用存储在其他计算机中的共享数据库比每个人的本地机器。如果一个人删除数据，共享机器可能会导致问题，但这可以通过一个小备份等来解决，而在另一端，如果团队中的每个人都有自己的数据库，那么领导将很难确保每个人的数据库都在同步（即小更新 sql 需要在每个人的计算机上运行，以使他们的工作站在每次从 CVS 同步代码后正常工作，这是日常工作）
It depends on how big the team is? In most of the small projects I worked everyone in the team have their own DB and specially when DB is Derby/Cloudscape but when it comes to big project using DB2 or Oracle it is always advisable to use shared DB which is stored in some other machine than everyone's local machine. Shared machine may cause the issue if one person deletes the data but this can get resolved with having just a small backup etc. while on the other end if everyone in team has their own DB it will be hard for Lead to ensure that everyone's DB are in sync (that is small update sql requires to run on everyone's machine to make their workstation working after every time they sync the code from CVS which is everyday job)
你可以这么做。 IBM 确实支持该配置。大多数开发人员使用 WCS Developer 附带的嵌入式 WCS 环境。它具有运行时以及作为数据库的 Apache Derby。
我还建议您与 IBM 产品专家交谈。他们可以告诉您最佳实践，并且您可以在购买软件时与他联系。只需打开 PMR 并提出您的问题即可。
You could do that. IBM does support that configuration. Most developers uses the embedded WCS environment that comes with WCS Developer. That has the runtime along with Apache Derby as the database.
Also I would recommend you to talk to an IBM product expert. They can tell you best practices and you get access to him as part of your software purchase. Just open a PMR and ask your question.
为每个开发人员使用本地数据库。
然后使用 liquibase 之类的工具来管理任何数据库结构更改。
要求将所有数据库更改编写为脚本，并将其放置在源存储库中，然后将 liquibase servlet 添加到您的 Stores 项目中。这样，当开发人员检查新内容时，本地数据库将在重新启动服务器时自动更新。
这样做还有一个额外的好处，即您的 sql 脚本实际上至少经过团队中的 pr 开发人员测试一次。
现在，理想情况下，您也可以为您的开发人员使用 wcbd。但是，由于这不会跟踪哪些脚本已经在您的系统上运行，因此编写超级防御性 sql 脚本（检查该表是否已经将 X 列扩展为 Y 字符）变得非常烦人，或者在以下情况下dataload，您可能会覆盖一些实际上不应该的东西。
Use local databases for each developer.
Then use something like liquibase to manage any database structure changes.
Demand that all database changes be scripted, and placed in source repository, then add the liquibase servlet to your Stores project. That way, when developers check out new stuff, the local database will automatically be updated when they restart the server.
This has the added benefit, that your sql scripts actually gets tested at least once pr developer on the team.
Now, ideally, you'd be using wcbd for your developers also. But since that doesn't track which scripts have already been run on your system, it becomes either very tiresome to write super-defensive sql scripts (to check if this table has already had column X extended to Y characters), or in case of dataload, you might override something that really shouldn't be.