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

Question

描述用于开发不太高级别的Web应用程序的过程，重点关注VC，错误跟踪，QA，单元测试，部署以及其他类似的东西（减去规划/客户端通信方面的事情）。

我是这方面的新手，所以我粗略的例子（读：没有用过这个过程）无疑是放弃了，可以这么说 - 指出它的缺陷所以我可以学习。

例如

1. 在本地SVN服务器上创建项目存储库。
2. 为DNS映射创建批处理/ shell脚本。
3. 查看项目，开始处理本地工作副本。
4. 将功能开发为分支。
5. 使用Mantis跟踪错误（链接通过它的SVN集成提交错误（不知道是否存在））。
6. 你去的文件。
7. 在分支上做QA。
8. 稳定后合并到行李箱。
9. 单元测试？
10. 在功能实施且稳定时提交到存储库。
11. 将版本复制到存储库中的标记。例如。 /项目/标签/ REL-123 /
12. 使用Phing上传到登台服务器。 （有人可以确切地说明除了“测试”之外用于临时服务器的内容吗？）
13. 使用Phing准备实时网站以进行更新，设置数据库/部署等

Answer 1

1. 创建/结帐HEAD版本（“主分支”）
2. 开发代码并与主分支同步 - 每日至少
3. 开发完成后，编写并运行单元测试
4. 完成代码审核并将代码/更改提交到主分支
5. 让连续构建器在主分支上运行所有单元测试和系统/集成测试
6. 准备好后，挑选修订并将其整合到QA分支
7. 运行系统和集成测试，修复报告的错误或根据需要回滚;这重复步骤4-7
8. 在QA签收后，将QA更改集成到发布分支
9. 在发布分支上运行单元测试，系统/集成测试
10. 部署到生产并运行健全性测试。

登台服务器是您的生产环境的副本，该副本尽可能是最新的。在我目前的项目中，我们能够保持每个版本彼此独立，因此我们的“登台服务器”是我们的生产服务器，只需从不同的URL访问。

注释和不符点：

所有步骤都有一些变化，具体取决于项目的大小。您的项目越大，樱桃采摘和环境分离的好处就越大。在较小的项目中，这些可能只是时间汇，经常被忽略或绕过。

为了澄清，有一个开发堆栈，QA堆栈和Staging堆栈。根据您的项目规模，QA可能正在升级，生产可能正在升级，或者它们的某些组合。 Dev和QA堆栈的分离是最重要的。

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

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

FWIW，我发现“迁移脚本”没什么价值。它们总是一个一次性的脚本，几乎没有重用，并使回滚成为屁股的痛苦。我认为更容易让应用程序向后兼容。在几次发布之后（当回滚是可笑的时候），如果需要，应该进行数据清理。

Answer 2

非常粗略：

1. 在SVN中创建存储库
2. 检查本地工作副本到开发人员环境
3. 经常更新/提交更改
4. 使用自定义部署脚本从SVN中继部署到舞台
5. 舞台上的QA测试，报告Mantis中的错误
6. 开发人员修复错误，标记为已解决
7. 重新部署到舞台
8. QA测试错误，如果已修复则关闭
9. 质量检查已完成，进行回归测试
10. 使用自定义部署脚本部署到生产
11. 做一点舞蹈

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

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

Answer 3

老帖子，但有趣的问题！

现在在我的公司：

1. 创建新的Github repo
2. 配置Jenkins
3. 本地克隆
4. 开始分支
5. 开发和添加测试（服务器，客户端和e2e）
6. 提交每一步，并获取+ rebase以保持分支同步
7. 准备好后，将分支推送到服务器：预先提交检查lint并测试并阻止（如果不正常）
8. 为分支创建拉取请求
9. 在这里，jenkins会自动在分支上运行测试，并直接在pull请求中将其标记为“green”或“broken tests”
10. 最后有2位同事审核了拉取请求并修复了他们的发现（回到第5步）
11. 当所有绿色和2位同事同意时，最后一个合并拉取请求
12. 删除服务器上的分支
13. 准备好后，推送新版本
14. 最新版本立即部署在测试平台上
15. QA验证所引入的更正和功能（如果出现问题则返回5）
16. （TODO）部署到具有与生产
相同参数的预生产
17. 部署到生产
18. 向用户道歉，了解引入的错误;）并在问题管理器中报告
19. 获取功能请求并在问题管理器中报告
20. 在步骤2重启周期