持续集成和部署的最佳实践

Question

持续集成和部署的最佳实践

testingcontinuous-integrationteamcitycontinuous-deploymentcontinuous-delivery

26

持续集成概念刚被整合到我的团队中。

假设我们有一个名为 Dev 的集成分支。

从它派生出3个分支，每个分支都针对当前特定的项目:

项目 A
项目 B
项目 C

首先，在专用服务器上配置了 Teamcity ，其目标是：

从每个分支（包括 Dev）的版本化源代码编译和启动单元和集成测试

然后，当然，必须在克隆的生产环境中测试每个项目分支（A、B和C），以便进行用户验收测试。

但我想知道应该多频繁地部署？每次源代码更改时吗？

我们应该仅部署 Dev，其中包含将每个项目合并到其中的混合内容（对应于下一个生产发布的现实情况）还是这3个项目独立部署？

如果部署 Dev，则未来可能更改 Dev 的内容不应纳入考虑。确实，可能会有一个名为 Project D 的新项目开始，它不应是下一版本的一部分。因此，将 Dev 用于集成（UAT）是有风险的，因为部署人员可能会无意中集成 Project D 的内容，从而环境将无法揭示下一版本的现实情况。

另一个解决方案：我们不使用 Dev，而是独立使用这3个项目，因此必须并行拥有 3 个克隆生产环境？

如果是这样，UAT 可能就不可靠了，因为集成环境的行为可能经常发生变化...

持续部署的 UAT 概念对我来说不太清楚...

- Mik378

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- EricMinick · Accepted Answer

哦，你遇到了现实世界中的连续部署问题。非常好的问题。

答案有点取决于各个项目开发工作之间的紧密程度。

在我看来，最理想的情况是拥有若干个“努力”特定的测试环境。例如，在每个项目中考虑一个测试环境。当完成 Project A 的构建时，您将其推入 Environment A 中，其中包含 B/C 的最新批准/生产版本，并且可以在那里执行基本集成测试。如果它们通过了测试，则将构建升级为集成测试环境，其中部署了相同发布中的最新的良好的 A、B 和 C。当集成测试环境通过测试时，您可以将其内容提升为包含已知版本的 A、B 和 C 的发行套件。该发行套件将部署到任何 UAT、Staging 或 Production 环境中。

基本思路是给每个项目一定程度的隔离，以便即使其他项目（暂时）出现问题，也能够进行良好的测试，并尽快进行完整的集成测试。我们还希望确保我们发现的任何通过集成测试的东西都会被一起提升。选择要发布的项目版本并没有经过一起测试的风险太大，不符合我的口味。

这实际上是我经常谈论的一个话题。如果您不介意，我会列出我在这些话题周围所发表的一些演示文稿。

1) 扩展并行开发的 CI 策略（与 Accurev 的 Chris Lucca 共同展示）

这个演讲探讨了在平衡隔离和集成方面的广泛策略。其中很多内容都假定子项目正在合并到一个共同的代码库中，但是只需要稍微想象一下就可以将其应用于独立构建和部署的模块。

2) 使用 Jenkins 进行 uDeploy （需要注册）

这更多地关注产品，但几乎完全表达了使用集成测试环境来进行多个项目的构建、创建发布集合（我们称之为“快照”）并推广的思想。我们与TeamCity的整合非常相似，但我认为其中所持有的策略可能更重要。

3) 幻灯片可视化多组件流水线:

http://www.slideshare.net/Urbancode/adapting-deployment-pipelines-for-complex-applications