25

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

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

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

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

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

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

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

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

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

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

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

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

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

4

1 回答 1

28

好家伙。你遇到了现实世界的 CD 问题。真的很好的问题。

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

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

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

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

1)为并行开发扩展 CI（与 Accurev 的 Chris Lucca 共同提出）

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

2)将 uDeploy 与 Jenkins 一起使用 （需要注册）

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

3）幻灯片可视化多组件管道：

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

于 2012-02-02T18:33:55.687 回答