持续集成概念刚刚集成在我的团队中 .
假设我们有一个名为 Dev 的集成分支 .
从它衍生出3个分支，每个特定的当前项目一个：
-
项目 A
-
项目 B
-
项目 C
首先，Teamcity在专用服务器上配置，其目标是：
从包括Dev在内的每个分支的版本化源编译并启动单元和集成测试
然后，当然，每个项目分支（A，B和C）必须在克隆的 生产环境 环境中进行测试，以便可以执行UAT .
但我想知道我们应该部署什么频率？每次源代码更改？
我们是否应该仅将包含3个项目的混合的Dev部署到它之后（对应于下一个 生产环境 版本中的实际情况）或3个独立的项目？
如果部署了Dev，则不得考虑将来可能对Dev进行更改 . 实际上，可能会有一个名为 Project D 的新项目，并且不得成为下一个版本的一部分 . 因此，采用Dev进行集成（UAT）是有风险的，因为部署者可以非自愿地整合项目D的内容，因此环境不会揭示下一版本的实际情况 .
其他解决方案：我们不是采用Dev而是独立采用3个项目，那么是否必须同时存在3个克隆 生产环境 环境？
如果是，UAT可能不可靠，因为集成环境的行为可能经常发生变化......
UAT持续部署的概念对我来说并不清楚......
1 回答
好家伙 . 你正在遇到现实世界的CD问题 . 真是个好问题 .
答案取决于高度紧密耦合的开发工作是在各种项目上 .
在我理想的情况下，你将拥有一些“努力”的特定测试环境 . 在一种情况下，您可以考虑每个项目的测试环境 . 如果项目A已完成构建，则将其推入环境A，该环境具有最新的B / C批准/ 生产环境 版本，您可以在那里执行基本集成测试 . 如果它们通过，则将构建升级到集成测试环境，在该环境中，最新的好的A部署在同一版本的最新B＆C上 . 当集成测试环境通过测试时，您可以将其内容作为包含已知版本A，B和C的发行集进行升级 . 该发行集将部署到任何UAT，Staging或Production环境 .
基本思想是为每个项目提供一定程度的隔离，以便即使其他项目（暂时）严重损坏也可以很好地进行测试，同时尽可能快地进行完整集成测试 . 我们还希望确保无论我们发现什么，实际通过集成测试都将一起推广 . 挑选和选择未经测试的项目版本对我来说风险太大 .
这实际上是我要谈的话题 . 如果你不介意的话，我会列出一些关于这些主题的演讲 .
1）Scaling CI for Parallel Development（与Accurev的Chris Lucca合作）
这谈到了 balancer 隔离和集成的广泛策略 . 其中大部分假设子项目正在合并为一个公共代码库，但是主体可以应用于独立构建和部署的模块，只需要一点想象力 .
2）Using uDeploy with Jenkins（需要注册）
这更侧重于产品，但几乎完全表明了为多个项目使用集成测试环境，创建发布集（我们称之为“快照”）并促进这一点 . 我们与TeamCity的整合非常相似，但我认为在那里实施的策略可能更为重要
3）幻灯片可视化多组件管道：
http://www.slideshare.net/Urbancode/adapting-deployment-pipelines-for-complex-applications