使用数据驱动的Web应用程序和许多devs进行版本控制的最佳实践是什么?[关闭]

虽然您肯定会问一个涉及很多领域的问题,但您需要具备三个主要部分:

1. 使用版本控制系统。类似的东西 Subversion 或 GIT 将自动允许您将应用程序的代码回滚到任何时间点,或者回滚到您“标记”源代码的任何时间点。只要每个人都只提交成功构建和运行的代码,那么每个提交都将是一个有效的点,您可以将更改回滚到该点。您的版本控制系统将为您以及分支机构管理多行代码。有 many strategies 对于处理分支,请找到一个最适合您的流程的分支。

2. 使用生成服务器。像这样的构建服务器 cruise control , Hudson 或 TeamCity 将自动确保每个提交都是一个“好的”提交,可以编译并成功运行(假设您有测试)

3. 将数据库架构和静态数据库数据与代码一起包含在版本控制中。有一些工具 LiquiBase 它允许您管理数据库结构,并设计为与多个开发人员同时工作,甚至跨多个分支工作。如果没有相应的数据库结构,代码就不好用,因此您需要确保两者保持同步。将数据库更改存储在源代码存储库中是最简单的方法。也就是说,您不能将完整的数据库存储在存储库中。它太大,而且变化太大,您的源代码管理的diff/merge支持无法处理。根据你所在行业的不同,由于政府的规定,这也可能是不合法的。如果发现由于版本不正确而需要回滚生产数据库,则需要通过查看存储的更新脚本来确定哪些SQL语句最能撤消应用的更改。

表现很好 white paper 解决你提出的一些问题。从讨论网页的白皮书中,您可以将概念扩展到用于生成/修改表的存储过程和脚本。

至于能够从头开始补充水,这实际上取决于您的灾难恢复计划,以及您如何设置和配置开发和集成测试环境,以及您愿意接受的停机时间。我不是每天都在处理这些问题,所以也许那些拥有更多真实世界经验的人,特别是那些在操作方面有经验的人,可以传授他们的智慧。

120页是“巨大的”?真的。。。

对这样的应用程序进行版本控制非常简单。您有一个生产部署过程,其中包括在版本控制系统中的每个版本退出之前对其进行标记,并且只安装有标记的版本。在升级时,在更改架构之前备份数据库,并将其存储在具有描述性名称的地方,该名称允许您链接代码和数据库备份。如果需要回滚,只需安装旧代码并还原备份。

如果您需要回滚,但是使用当前数据,那么这是一个更困难的问题,而且更多的是关于数据库的结构以及它的结构是如何演变的,但是Rails迁移是一个关于如何完成的有趣的研究。

除此之外,你的问题相当大,涉及很多领域。最好是和以前处理过这些事情的人签约,让你走上正确的道路。

这真的是一个非常正常的中等大小的应用程序。您只需要遵循良好的源代码控制过程,使用适当的单元测试、持续集成等。许多开发组织已经解决了这个问题。

恕我直言,你认为120页是巨大的,你认为这是一件大事,这两个事实都表明你应该考虑现在停止开发,并改进开发过程。

我担心如果你现在不这样做,你以后会知道为什么你应该这样做。

对于这么小的东西,而不是担心能够及时回滚,你真正想要的是能够将最新的版本回滚到最后一个版本。这样,如果您破坏了构建,就可以回滚到先前的构建。怎么用?

1)您的Web服务器从/www/working读取 2)将您的更改推到/www/new 3)将/www/current移到/www/old 4)将/www/new移到/www/current

如果/www/current爆炸,只需将/www/old移回原位。

唯一的捕获是回滚数据库模式不属于此范围。如果不可能的话,回滚模式更改是很困难的。您真正能做的就是从备份中恢复旧版本,并释放活动数据库和备份内容之间的任何活动。如果您考虑一下,这是有意义的——如果您添加了三个新表,并以某种方式将另一个表重构为一个更好的模式,那么之后如何回滚模式更改?你不能——你只需要把所有的新数据都释放掉就行了。道德?认真对待数据库更改——DBA有时被认为是混蛋的原因之一。它们必须——它们不能像回滚bug代码那样只回滚数据库中的错误。