敏捷Agile方法
什么是持续交付?
"持续交付"作为一组词语，其包含了开发和交付两个含义，显然产品的开发和交付并不稀奇， 传统开发人员在其本地的机器完成代码开发后，希望将其代码推送到服务器端的源码控制系统。
有人认为，持续交付引入意味着一旦把源代码推送到服务器，就要向其他系统发送通知，启动当天的构建过程，构建代码，运行测试,然后部署到运维服务器上。
这是所有有持续交付吗? 当然不是。
上面定义只是关注代码被推到源代码存储库的过程。 持续交付不仅包括这个过程，而且要确保交付的是质量比较高的源码。
这意味着当你将代码推送到源码服务器，这些代码应该是高质量的。不应该有代码编译和单元测试失败的情景，应该都运行得很好。
因此，持续交付是一个连续交付功能并且确保高质量交付的过程。
如何提高交付质量？
虽然日日进行单元测试可能不是很重要，但是你的代码覆盖率90%部分可能需要单元测试，测试不可能做到100%代码覆盖率，假如我们有一个IF语句，为了达到100%覆盖率，我们需要深入IF的嵌套条件进行测试，这个数量是相当大的。
虽然测试代码的各个部分是一个好的开始，但是从长远角度看，编写端到端的功能测试更具有意义。
以一个ASP .NET网站为例,，运行 HttpClient 测试网站和验证响应数据是远远超过一些单元测试的价值，在大多数情况下验收测试、集成测试比简单的单元测试更值得。
记住命名您的测试是至关重要，命名遵循一个模式，命名测试可以如下: Given_That_Username_Is_Empty_Login_Attempt_Fails
部署到不同的环境中
当将我们改变的代码推送到服务器源码控制端后，希望开发人员已经在本地运行了所有单元测试以确保没有明显的错误。 单元测试可以快速运行，而不是等到(功能/集成)测试，那需要很长时间才能运行。
我们持续交付过程贯穿以下步骤:
- 运行单元测试
- 运行验收测试
- 部署到测试
- 运行测试的验收测试
- 部署到生产环境
不同的环境会有不同的测试数据,类似于不同状态一样的部署。 你越接近生产,你应该越接近真实数据测试。
推荐工具
有很多的工具可以帮助我们达到很好的持续交付，如:
- TeamCity 是一个伟大的用于持续交付/集成的工具。 它将监测源代码存储库的变化，帮助您构建和部署您的产品
- Octopus部署 会让你自动部署，例如一旦TeamCity表示正常后，可以将产品部署到在负载均衡器后的10台服务器上，
- NCrunch 对于Visual Studio是一个工具，在您的解决方案有一个变化就持续地运行所有测试。 它还为您提供指标代码覆盖率，代码哪些部分是否有迹象未经测试。 这个工具提供了一种好的方式来启动测试和获得更好的代码测试覆盖率。
- Azure托管解决方案也是一个平台。
