持续集成和Web部署工作流程

Question

我们正在寻求改进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;我们在每个解决方案中设置了Dev，QA和Prod配置 - 在Visual Studio解决方案中定义。）可悲的是，我们还没有实际上使用TeamCity是为了它的预期目的，即持续集成。为此，我们需要实施TDD。部署自动化从每个存储库的主分支中提取。
• 环境：我们有3个环境，每个环境都有专用的Web，批处理和数据库服务器。我们称他们为Dev，QA和Prod。 Dev是我们的测试环境。质量保证是供最终用户测试的。刺激是刺激。通常，我们的部署自动化会将每个应用程序推送到每个环境一次。它目前无法处理将同一个应用程序推送到单个环境中的多个位置。

请注意，我们开始遇到需要进行并行开发的情况：在一个分支中正在处理一个功能;另一个分支;和另一个修补程序。显然，做主人的一切都是不可接受的。

以下是我要去的地方：

• 在Git中开始分支模型。
• 将部署自动化移出Team City，进入自定义，强大的部署工具。
• 实施TDD。
• 将TeamCity用于其预期目的，持续集成。

这些都是高级目标，我对如何开始这样做有着粗略的想法（特别是在部署自动化方面）。但是，我有一些相当大的突出问题令我（喔哈哈）总体规划感到沮丧。以下是我喜欢SO社区的投入项目：

1. 当您执行CI并启动自动化测试时，您执行此操作的分支是什么？我认为，从理论上讲，你并不想要＆＃34;破坏＆＃34;代码在你的＆＃34;开发＆＃34; （显然）＆＃34;掌握＆＃34;分支机构。你是否反对＆＃34;开发＆＃34;还是所有分支？
2. 您是否在移动代码之前或之后合并到主？换句话说，你是开发还是掌握推动产品？
3. 有时我们需要测试（至少在QA中，可能在Dev中）并行更改，如错误修复和功能。你真的设置了多个测试网站（例如myappqa1.blah.com和myappqa2.blah.com等）？这些多个环境如何影响您的部署自动化？
4. 出于好奇，您是否每晚都会进行构建 - 如果是这样，是针对哪个分支？你在任何地方部署这个夜间构建吗？
5. 如何打包您的应用（即商店发布）？现在，我们使用TeamCity和PowerShell对VS中定义的配置运行msbuild。它会将所有环境构建放入一个zip文件中。它存储为TeamCity构建的工件。以下是我所谈论的内容的视觉效果：然后，另一个脚本将从zip文件中选择正确的环境并进行部署。我们应该以某种方式将发布包存储在Team City或Git中（使用＆＃34;发布＆＃34;功能）吗？
6. 相关的，您的部署自动化：您是部署以前打包/构建的应用程序，还是一次性构建和部署所有应用程序？

非常感谢您的反馈！

由于 汤姆

Answer 1

作为BuildMaster的开发人员（一个适合TeamCity结束后可能正在寻找的工具），我可以尝试回答大部分内容。

  

当您执行CI并开始自动化测试时，您会做什么分支   对此？我认为，从理论上讲，你并不想要＆＃34;破坏＆＃34;   代码在你的＆＃34;开发＆＃34; （显然）＆＃34;掌握＆＃34;分支机构。你踢了吗   CI反对＆＃34;发展＆＃34;还是所有分支？

我们遵循＆＃34;按规则分组＆＃34;和＃34;异常分支＆＃34;模型，其中开发是针对＆＃34;发布＆＃34;分支，或者它是对trunk / master完成的。功能分支也可以存在于本地开发中，但它们本身并不构建并发布到集成中以及之外（即它们与＆＃34;发布＆＃34;分支合并，无论它是否在主干/主服务器上或分开）。

您可以在Source Control Done Right中了解有关此流程的更多信息。

  

在将代码移动到prod之前或之后，您是否合并到master中？   换句话说，你是开发还是掌握推动产品？

强烈建议您不要为各个环境保留单独的分支。我知道这最近成为所有分布式源代码控制系统的趋势，但根据我们的经验，如果没有特殊的纪律，它会导致很多问题。主要问题是：丢失/遗忘合并，从一个环境到下一个环境的不兼容合并，未经测试的代码意外地合并到新环境中，等等。

所以要回答这个问题，分支代码（对于＆＃34;逐个分支＆＃34;）或者主干/主代码（对于＆＃34;分支异常＆＃34;）是什么在将其发布到之前的测试环境后，它将投入生产。

  

有时我们需要测试（至少在QA中，可能在Dev中）并行测试   更改，如错误修复和功能。你真的设置了多个   测试网站（例如myappqa1.blah.com和myappqa2.blah.com等）？   这些多个环境如何影响您的部署   自动化？

这种类型的测试本质上是一种预集成测试，因为测试人员在没有将其与其他开发集成的情况下测试功能。完全集成的代码是需要测试的。您可以拥有任意数量的预集成环境，就像您可以拥有任意数量的本地开发环境一样。

  

出于好奇，你做夜间建筑 - 如果是的话，反对   什么分支？你在任何地方部署这个夜间构建吗？

是的，但是对于我们的团队来说，它们本质上是无用的，因为一旦你自动构建了这个版本。发布过程，在必要时创建新版本是微不足道的。对于大型团队或面向公众的下载，它当然可以提供帮助。构建适当地部署到＆＃34;集成＆＃34;环境。使用的分支由为其创建的版本确定。

  

如何打包应用程序（即商店发布）？ ... 我们应该吗   将发布包存储在Team City或Git中（使用＆＃34;发布＆＃34;   以某种方式？

每个环境的单独构建是一种反模式。部署的每个环境的部署单元应该相同，当然除外：

• 应用程序配置 - 例如.NET，web.config / App.config个文件
• 基础架构部署 - 例如设置IIS /网站（这与应用程序部署正交，通常由Ops团队处理，因此需要DevOps，但这是一个完全不同的主题）
• 数据库更改 - 这些更改本身就是特殊的，因为一旦您DROP列，就无法再次删除它。您可以在Database Changes Done Right
中详细了解这些内容

  

相关的，您的部署自动化：您以前是否部署过   打包/构建应用程序，还是一次性构建和部署？

常见的方法是分离构建和部署。对于简单的网站（即宣传册网站），没有必要进行这种区分和“连续制作”＃34;够好了。

当其他零件和零件需要聚集在一起时，这当然会变得模糊。例如，发布我们的BuildMaster软件需要安装程序供公众使用。在以后的环境中，根本不使用安装程序，通过预打包的构建工件（安装程序也使用）完成对早期环境的部署。这是从一开始就保持单个部署单元（即工件集）的地方，可以很容易地部署到有或没有安装程序的任何环境。

TL，DR - 很难总结如此广泛的主题......但我建议您查看由同事撰写的新Incremental Continuous Delivery paper如果您正在寻找在没有大量预先投入的情况下开始使用。