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

发布于 2024-07-16 00:53:26 字数 613 浏览 6 评论 0原文

描述您用于开发不太高级别的 Web 应用程序的流程，重点是 VC、错误跟踪、QA、单元测试、部署和其他类似的内容（减去规划/客户端通信方面的内容）。

我是这个领域的新手，所以我的粗略示例（阅读：没有使用过这个过程）无疑有点不对劲，可以这么说 - 指出它的缺陷，以便我可以学习。

例如。

在本地SVN服务器上创建项目存储库。
为 DNS 映射创建批处理/shell 脚本。
检查项目，开始处理本地工作副本。
开发功能作为分支。
使用 Mantis 跟踪错误（链接通过 SVN 集成提交错误（不知道是否存在））。
边走边记录。
在分支上进行质量检查。
稳定后合并到主干。
单元测试？
当功能实现且稳定时提交到存储库。
将版本复制到存储库中的标签。例如。 /project/tags/rel-123/
使用 Phing 上传到临时服务器。（有人可以准确说明除了“测试”之外，临时服务器的用途吗？）
使用 Phing 准备实时站点以进行更新、设置数据库/部署等。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

被你宠の有点坏 2024-07-23 00:53:26

创建/签出 HEAD 版本（“主分支”）
开发代码并至少每天与主分支同步开发
完成后，编写并运行单元测试
通过代码审查并向主分支提交代码/更改
让持续构建器在主分支上运行所有单元测试和系统/集成测试
准备好后，挑选修订并将其集成到 QA 分支
运行系统和集成测试，修复报告的错误或根据需要回滚；这将重复步骤 4-7
在 QA 签核后，将 QA 更改集成到发布分支
在发布分支上运行单元测试、系统/集成测试
部署到生产并运行健全性测试。

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

注释和差异：

根据项目的大小，所有步骤都有一些变化。您的项目越大，从樱桃采摘和环境分离中获得的好处就越大。在较小的项目中，这些可能只是时间消耗，并且经常被忽略或绕过。

澄清一下，有一个开发堆栈、QA 堆栈和登台堆栈。根据您的项目规模，质量检查可能正在分阶段，生产可能正在分阶段，或其某种组合。开发和 QA 堆栈的分离是最重要的之一。

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

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

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

Create/checkout HEAD version ("main branch")
Develop code and sync with the main branch -at least- daily
After development is done, write and run unit tests
Go through code review and submit code/changes to the main branch
Let continuous builder run all unit tests and system/integration tests on main branch
When ready, cherry pick revisions and integrate them to the QA branch
Run system and integration tests, fix reported bugs, or rollback as necessary; this repeats steps 4-7
After QA signoff, integrate QA change to release branch
Run unit tests, system/integration tests on release branch
Deploy to production and run sanity tests.

A staging server is a copy of your production environment that is as up-to-date as possible. On my current project, we're able to keep each release independent from each other, so our "staging server" is our production server, just accessed from a different url.

Notes and discreprencies:

All of the steps have some variation depending on the size of your project. The larger your project, the better the benefit from cherry picking and environment separation. In smaller projects, these can just be time sinks and are often ignored or bypassed.

To clarify, there is a Development stack, QA stack, and Staging stack. Depending on your project size, QA might be staging, Production might be staging, or some combination thereof. The separation of the Dev and QA stacks is the most important one.

In the steps above, I'm assuming both code and relevant data is versioned or tracked. Having a release and build process that takes control data into account makes a release very, very easy.

In a small-medium sized project, there may or may not be a release branch; it depends on the frequency of code change. Also, depending on the frequency of code change and size of your project, you may integrate the full QA branch to the Release branch, or cherry pick specific revisions to integrate to the release branch.

FWIW, I've found "migration scripts" to be of little value. They're always a one-off script with little reuse and make rollbacks a pain in the ass. Its much easier, I would argue better, to have the application backwards-compatible. After a few releases (when a rollback is a laughable), data cleanup should be done, if necessary.

回复收藏 0 原文