Deployment Web应用程序开发过程-版本控制、错误跟踪、单元测试、部署

描述您在不太高的层次上开发web应用程序的过程，重点是VC、bug跟踪、QA、单元测试、部署和其他类似的东西（不包括规划/客户端通信方面）

我是这方面的新手，所以我的粗略示例（如下所示：未使用此过程）毫无疑问有点离题，可以这么说——指出它的缺陷，以便我可以学习

例如

在本地SVN服务器上创建项目存储库

为DNS映射创建批处理/shell脚本

签出项目，开始本地工作副本的工作

将功能开发为分支

用螳螂跟踪bug（link通过它的SVN集成提交bug（不知道是否存在））

边走边记录

对分支机构进行QA

稳定时合并到主干

单元测试

当功能实现且稳定时提交到存储库

将发布复制到存储库中的标记。例如/项目/标签/rel-123/

使用Phing上载到临时服务器。（除了“测试”之外，是否有人能确切地说明登台服务器的用途？）

使用Phing准备实时站点进行更新，设置DB/deploy等

非常粗略地说：

在SVN中创建存储库

正在检查本地工作副本到开发人员环境

频繁更新/提交更改

使用自定义部署脚本从SVN主干部署到后台

QA在舞台上测试，报告螳螂中的错误

开发人员修复bug，标记为已解决

重新部署到舞台

QA测试错误，如果修复，则关闭

QA完成后，进行回归测试

使用自定义部署脚本部署到生产环境

跳支舞

我们还为将来的版本或功能创建分支。这些最终被合并到主干中

我们将db结构与部署期间执行的自定义db比较工具保持同步

创建/签出标头版本（“主分支”）

开发代码并与主要分支同步-至少每天一次

开发完成后，编写并运行单元测试

进行代码审查，并将代码/更改提交给主要分支机构

让continuous builder在主分支上运行所有单元测试和系统/集成测试

准备好后，挑选修订并将其集成到QA分支

运行系统和集成测试，修复报告的错误，或根据需要回滚；重复步骤4-7

QA签核后，将QA变更整合到发布部门

在发布分支上运行单元测试、系统/集成测试

部署到生产环境并运行健全性测试

暂存服务器是生产环境的一个尽可能最新的副本。在我当前的项目中，我们能够使每个版本彼此独立，所以我们的“暂存服务器”是我们的生产服务器，只是从不同的url访问

注意事项和谨慎：

根据项目的大小，所有步骤都有一些变化。你的项目越大，采摘樱桃和环境分离的好处就越好。在较小的项目中，这些可能只是时间汇，通常被忽略或忽略

为了澄清，有一个开发堆栈、QA堆栈和暂存堆栈。根据您的项目规模，QA可能是阶段性的，生产可能是阶段性的，或者两者的组合。Dev和QA堆栈的分离是最重要的

在上面的步骤中，我假设代码和相关数据都进行了版本控制或跟踪。有一个考虑到控制数据的发布和构建过程使得发布非常非常容易

在中小型项目中，可能有也可能没有发布分支；这取决于代码更改的频率。此外，根据代码更改的频率和项目的大小，您可以将完整的QA分支集成到发布分支，或者选择特定的修订来集成到发布分支

---

FWIW，我发现“迁移脚本”没有什么价值。它们总是一个一次性的脚本，很少重用，使回滚成为一个麻烦。我认为，让应用程序向后兼容要容易得多。在几次发布之后（当回滚是一个可笑的问题时），如果必要的话，应该进行数据清理。

这篇老文章，但有一个有趣的问题

现在在我的公司：

创建新的Github回购协议

配置詹金斯

本地克隆

开设分支机构

开发和添加测试（服务器、客户端和e2e）

提交每个步骤，并获取+重新设置基础以保持分支同步

准备好后，将分支推送到服务器：预提交检查lint和tests，如果不正常则阻塞

为分支创建拉取请求

在这里，jenkins会自动在分支上运行测试，并直接在pull请求中将其标记为“绿色”或“中断测试”

至少让两名同事审查拉动请求并修复他们的发现（返回到步骤5）

当green和两位同事都同意后，最后一个合并pull请求

删除服务器上的分支

准备好后，推送新版本

最新版本立即部署在测试平台上

QA验证纠正措施和引入的功能（如果有问题，返回5）

（TODO）使用与生产相同的参数部署到预生产

部署到生产环境中

请为引入的错误向用户道歉；）并向问题经理报告

获取功能请求并在问题管理器中报告

在步骤2重新启动循环

---

请提供有关自定义数据库比较工具的更多信息？例如，它是否比较实时数据库或它们的某些版本控制的文本表示？它只比较模式对象还是也比较引用