持续集成概念刚刚集成在我的团队中。
假设我们有一个名为Dev的集成分支。
从它派生出3个分支，每个特定的当前项目一个：
首先，Teamcity在专用服务器上配置，其目标是：
从包括Dev在内的每个分支的版本化源编译并启动单元和集成测试
然后，当然，每个项目分支（A，B和C）必须在克隆的生产环境中进行测试，以便可以执行UAT。
但我想知道我们应该部署什么频率？每次源代码更改？
我们是否应该仅将包含3个项目的混合的Dev部署到它之后（对应于下一个生产版本中的实际情况）或3个项目？
如果部署了Dev，则不得考虑将来可能对Dev进行更改。实际上，可能会有一个名为Project D的新项目，并且不得成为下一个版本的一部分。因此，采用Dev进行集成（UAT）是有风险的，因为部署者可以非自愿地整合项目D的内容，因此环境不会揭示下一版本的实际情况。
其他解决方案：我们不是采用Dev而是独立采用3个项目，那么是否必须同时存在3个克隆生产环境？
如果是，UAT可能不可靠，因为集成环境的行为可能经常发生变化......
UAT持续部署的概念对我来说并不清楚......
好家伙。你正在遇到现实世界的CD问题。真是个好问题。
答案取决于高度紧密耦合的开发工作是在各种项目上。
在我理想的情况下，你将拥有一些“努力”的特定测试环境。在一种情况下，您可以考虑每个项目的测试环境。如果项目A已完成构建，则将其推送到环境A，其中包含最新的B / C批准/生产版本，您可以在那里执行基本集成测试。如果它们通过，则将构建升级到集成测试环境，其中最新的好的A部署在最新的B＆C上，用于同一版本。当集成测试环境通过测试时，您可以将其内容作为包含已知版本A，B和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