工作流程：SVN 存储库、签出和内容
我们在内容和代码同步方面面临工作流程挑战。我们的问题是，我们并不确切知道管理网站内容及其代码开发的最佳方法是什么。
我们有以下情况：
- 开发人员 1 进行代码签出。开发一些后端代码，但也对（HIS LOCAL）数据库进行更改。更改涉及数据库结构和数据库内容。
- 开发者 2 将网站的一些内容添加到（HIS LOCAL）数据库（例如新闻项目或其他内容）。他还修改了一些前端代码。数据库结构没有改变。
- Developer 3 添加了一些前端代码。没有对数据库进行任何更改。
- 内容编辑器将一些内容添加到（HIS LOCAL）数据库。数据库结构没有改变。
这一切都是同时发生的。并没有真正的冻结时刻。
管理此工作流程的最佳方法是什么？我们如何才能最佳地使用 SVN？中央数据库是否可取？
We have a workflow challenge regarding content and code synchronization. Our problem is that we do not exactly know what the best approach is, to manage the content of a website and the code development of it.
We have the following situation:
- Developer 1 does a code check out. Develops some back-end code BUT does also make changes to (HIS LOCAL) database. The changes are on the database structure and database content.
- Developer 2 adds some content of the website to (HIS LOCAL) database (such as news items or other content). He also modifies some front-end code. No changes to the database structure.
- Developer 3 adds some front-end code. No changes to the database.
- Content Editor adds some content to (HIS LOCAL) database. No changes to the database structure.
This is happening all simultaneously. There is not really a freeze moment.
What is the best approach to manage this workflow? How can we optimally use SVN and is a central database advisable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
个人意见在此。
您需要保留两组描述数据库模式的文件。
第一个是 sql 文件/脚本，用于从头开始创建数据库到当前规范。
第二个是一系列进行增量更改的 SQL 文件或脚本。
每次数据库发生结构更改时，开发人员都会更新/重新生成主模式并编写一个脚本/增量文件来检查更改是否已应用（测试是否存在新列或表），如果没有应用，执行必要的操作以使架构保持最新。这应该只应用开发人员所做的更改。
然后，当您的其他开发人员签出并执行本地安装时，安装步骤应按顺序执行所有增量更新步骤（如果升级）。这意味着您应该能够安全地应用可能相互补充的连续更新。如果进行全新安装，您只需从完整文件生成数据库即可。
Personal opinion here.
You need to keep two sets of files describing your database schema.
The first is a sql file / script that creates the database from scratch to current spec.
The second is a series of SQL files or scripts that do incremental changes.
Every time there is a structural change to the database, the developer updates/regenerates the master schema and writes a script/incremental file that checks to see if the changes has been applied (tests for existence of a new column or table) and if not, performs the necessary operations to bring the schema up-to-date. This should only apply the changes that the developer made.
Then, as your other developers check out and perform local installations, the installation step should execute ALL the incremental update steps if upgrading, in order. This means that you should be able to safely apply the successive updates which may build off each other. If doing a clean installation, you simply generate the database from the complete file.