我们正在寻求改进SDLC的几个方面 . 我们现在所拥有的是以下内容，这些都是几年前我们所拥有的相当新的事物和光年：
-
代码：我们主要是.Net商店 . 我们主要开发Web应用程序（MVC / SQL Server） . 但我们也有一些批量控制台应用程序 .
-
SCM：Git和Enterprise GitHub . 大多数工作都直接在master分支（队列boo-hiss）中完成，但我们认识到需要转移到分支模型 . 我们将实现一些Vincent Driessen's model的味道 .
-
CI服务器：Team City . 我们在一两年前的迫切需要是设置部署自动化以避免危险的手动脚本 . 我们现在使用TeamCity通过PowerShell启动部署脚本 . （它使用msbuild来简单地构建目标配置 - 标准是Debug和Release;我们've set up Dev, QA, and Prod configs in each solution -- defined in the Visual Studio solutions.) Sadly, we have yet to actually use TeamCity for it'的目的是持续集成 . 为此，我们需要实现TDD . 部署自动化从每个存储库的主分支中提取 .
-
环境：我们有3个环境，每个环境都有专用的Web，批处理和数据库服务器 . 我们称他们为Dev，QA和Prod . Dev是我们的测试环境 . 质量保证是供最终用户测试的 . 刺激是刺激 . 通常，我们的部署自动化会将每个应用程序推送到每个环境一次 . 它目前无法处理将同一个应用程序推送到单个环境中的多个位置 .
请注意，我们开始遇到需要进行并行开发的情况：在一个分支中正在处理一个功能;另一个分支;另一个是修补程序 . 显然，做主人的一切都是不可接受的 .
这是我想去的地方：
-
在Git中开始分支模型 .
-
将部署自动化移出Team City并进入自定义，强大的部署工具 .
-
实施TDD .
-
使用TeamCity实现其预期目的，持续集成 .
这些都是高级目标，我对如何开始这样做有了粗略的想法（尤其是部署自动化） . 但是，我有一些相当大的突出问题令我（喔哈哈）总体规划感到沮丧 . 以下是我喜欢SO社区提供的项目：
-
当您执行CI并启动自动化测试时，您执行此操作的分支是什么？我'm thinking that, in theory, you don' t想要"develop"和（显然）"master"分支中的"broken"代码 . 你对"develop"或所有分支的CI踢了吗？
-
在将代码移动到prod之前或之后，您是否合并到master中？换句话说，你是推动开发还是掌握？
-
有时我们需要测试（至少在QA中，可能在Dev中）并行更改，例如错误修正和功能 . 你真的设置了多个测试网站（例如myappqa1.blah.com和myappqa2.blah.com等）？这些多个环境如何影响您的部署自动化？
-
只是出于好奇，你是否每晚都会进行构建 - 如果是这样的话，那么哪个分支？你在任何地方部署这个夜间构建吗？
-
如何打包应用程序（即商店发布）？现在，我们使用TeamCity和PowerShell运行msbuild对配置's defined in the VS. It will put all environment builds into a zip file. This is stored as an artifact of the TeamCity build. Here is a visual of what I' m谈论：
然后另一个脚本将从zip文件中选择正确的环境并进行部署 . 我们应该以某种方式将发布包存储在Team City或Git中（使用"release"功能）吗？ -
相关，您的部署自动化：您是部署以前打包/构建的应用程序，还是一次性构建和部署所有应用程序？
您的反馈非常感谢！
谢谢汤姆
1 回答
作为BuildMaster（一个适合TeamCity结束后可能正在寻找的工具）的开发人员，我可以尝试回答其中的大部分内容 .
我们遵循“按规则分支”和“按异常分支”模型，其中开发是针对“发布”分支进行的，或者是针对主干/主服务进行的 . 功能分支也可以存在于本地开发中，但它们本身并不构建并发布到集成中以及之外（即它们与“发布”分支合并，无论它是在主干/主服务器上还是单独的） .
您可以在Source Control Done Right中阅读有关此过程的更多信息 .
强烈建议您不要为单个环境保留单独的分支 . 我知道这最近成为所有分布式源代码控制系统的趋势，但根据我们的经验，如果没有特殊的纪律，它会导致很多问题 . 主要问题是：遗漏/遗忘合并，从一个环境到下一个环境的不兼容合并，未经测试的代码意外地合并到一个新环境中，以及等等 .
因此，要回答这个问题，分支代码（用于“按规则分支”）或主干/主代码（用于“逐个分支”）是在将其发布到先前的测试之后推送到 生产环境 中的内容环境 .
这种类型的测试本质上是一种预集成测试，因为测试人员在没有与其他开发集成的情况下测试功能 . 完全集成的代码是需要测试的 . 您可以拥有任意数量的预集成环境，就像您可以拥有任意数量的本地开发环境一样 .
是的，但它们对我们的团队来说基本上是无用的，因为一旦您自动构建和发布过程，创建新构建就变得微不足道了 . 对于较大的团队或面向公众的下载，它当然可以提供帮助 . 构建适当地部署到“集成”环境 . 使用的分支由为其创建的版本确定 .
每个环境的单独构建是一种反模式 . 对于您部署到的每个环境，部署单位应该相同，当然除外：
应用程序配置 - 例如.NET，
web.config/App.config文件基础架构部署 - 例如设置IIS /网站（这与应用程序部署正交，通常由Ops团队处理，因此需要DevOps，但这是一个完全不同的主题）
数据库更改 - 这些更改本身就是特殊的，因为一旦您
DROP列，就无法再次删除它 . 您可以在以下位置了解更多相关信息：Database Changes Done Right常见的方法是分离构建和部署 . 对于简单的网站（即宣传册网站），没有必要做出这种区分，“连续制作”就足够了 .
当其他零件和零件需要聚集在一起时，这当然会变得模糊 . 例如，发布我们的BuildMaster软件需要一个供公众使用的安装程序 . 在以后的环境中，根本不使用安装程序，通过预打包的构建工件（安装程序也使用）完成对早期环境的部署 . 这是从一开始就保持单个部署单元（即工件集）的地方，可以很容易地部署到有或没有安装程序的任何环境 .
TL,DR - It's really hard to summarize such a broad topic... but I recommend checking out this new Incremental Continuous Delivery paper authored by a colleague if you're looking to get started without investing heavily up-front.