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

Question

我的团队刚刚集成了持续集成的概念。

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

从中派生出 3 个分支，每个特定当前项目一个：

• 项目A
• 项目B
• 项目C

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

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

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

但我想知道我们应该以什么频率部署？每次源代码更改？

我们应该只部署包含 3 个项目的混合的开发，然后将每个项目合并到它（对应于下一个生产版本中的实际情况）还是独立部署 3 个项目？

如果部署了 Dev，则不得考虑 Dev 未来可能发生的变化。确实， 可能会有一个名为 Project D 的新项目开始，它不能成为下一个版本的一部分。所以采用 Dev for integration (UAT) 是有风险的，因为部署者可能会非自愿地集成 Project D 的内容，因此环境不会揭示下一个版本的现实。

其他解决方案：我们不是拿 Dev 而是独立的 3 个项目，所以必须有 3 个并行的克隆生产环境吗？

如果是，则 UAT 不可靠，因为集成环境的行为可能会经常变化...

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

Answer 1

哦，孩子。你遇到了现实世界的 CD 问题。非常好的问题。

答案在一定程度上取决于开发工作在各个项目上的高度紧密耦合。

在我的理想情况下，您将拥有许多“努力”特定的测试环境。在一种情况下，您可以为每个项目考虑一个测试环境。当项目 A 完成构建时，您将其推送到具有最新批准/生产 B/C 版本的环境 A，您可以在那里执行基本的集成测试。如果他们通过了，您将构建提升到一个集成测试环境，在该环境中，最新的好 A 与最新的 B 和 C 一起部署，用于相同的版本。当集成测试环境通过测试时，您可以将其内容提升为包含已知版本 A、B 和 C 的发布集。该发布集将部署到任何 UAT、暂存或生产环境。

基本思想是为每个项目提供一定程度的隔离，以便即使其他项目（暂时）严重损坏，也可以对其进行良好测试，同时尽快进行完整的集成测试。我们还希望确保我们发现实际上通过集成测试的任何东西都将被一起推广。挑选和选择尚未一起测试的项目版本来发布对我来说太冒险了。

这实际上是我经常谈论的话题。如果您不介意，我将列出我围绕这些主题所做的一些演示。

1) Scaling CI for Parallel Development（与 Accurev 的 Chris Lucca 共同出席）

这很好地讨论了平衡隔离和集成的广泛策略。其中大部分假设子项目正在被合并到一个公共代码库中，但原理可以应用于独立构建和部署的模块，只需一点想象力。

2) Using uDeploy with Jenkins （需要注册）

这更侧重于产品，但几乎完全展示了将集成测试环境用于多个项目、创建发布集（我们称之为“快照”）并进行推广的想法。我们与 TeamCity 的集成非常相似，但我认为其中的策略可能更重要

3) 显示多组件管道的幻灯片：

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