我的团队刚刚整合了持续集成概念。
假设我们有一个名为 Dev 的集成分支。
从中派生出3个分支，每个特定的当前项目一个：
首先，Teamcity在专用服务器上配置，其目标是：
从每个分支的版本化源编译并启动单元和集成测试，包括Dev
然后，当然，每个项目分支（A，B和C）必须在克隆的生产环境中进行测试，以便可以执行UAT。
但是我想知道我们应该部署什么频率？每次源代码更改？
我们是否应该仅将包含3个项目混合的Dev部署到它之后（对应于下一个生产版本中的实际情况）或3个项目独立？
如果部署了Dev，则不得考虑将来可能对Dev进行更改。确实， 可能有一个名为 Project D 的新项目，并且该项目不得成为下一个版本的一部分。因此，采用Dev进行集成（UAT）是有风险的，因为部署者可以非自愿地整合项目D的内容，因此环境不会揭示下一版本的实际情况。
其他解决方案：我们不是采用Dev而是独立采用3个项目，那么是否必须同时存在3个克隆生产环境？
如果是，UAT可能不可靠，因为集成环境的行为可能会经常发生变化......
UAT的持续部署概念对我来说并不清楚......
答案 0 :(得分：25)
哦，小伙子。你正在遇到现实世界的CD问题。非常好的问题。
答案取决于高度紧密耦合的开发工作是在各种项目上。
在我理想的情况下，您将拥有一些“努力”特定的测试环境。在一种情况下，您可以考虑每个项目的测试环境。如果项目A已完成构建，则将其推送到环境A，其中包含最新的B / C批准/生产版本，您可以在那里执行基本集成测试。如果它们通过，您将构建升级到集成测试环境，其中最新的优秀A，沿着最新的B＆amp; B部署。 C为同一版本。当集成测试环境通过测试时，您可以将其内容作为包含A，B和A的已知版本的发布集进行提升。 C.该发布集将部署到任何UAT，Staging或Production环境。
基本思想是为每个项目提供一定程度的隔离，以便即使其他项目（暂时）严重损坏也可以很好地进行测试，同时尽可能快地进行完整的集成测试。我们还希望确保无论我们发现什么，实际通过集成测试都将一起推广。挑选和选择未经测试的项目版本对我来说风险太大。
这实际上是我要谈的很多话题。如果你不介意，我会列出一些关于这些主题的演讲。
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