《持续交付》观感

前言

作为一个软件从业者，我们的工作就是用最快的速度将用户的点子转换成软件交付。
从两个实际问题入手

一个复杂项目新特性的部署需要多久？

在你的公司里，仅涉及一行代码的改动需要花多长时间才能部署上线？你是处理方式是否可重复和可靠？

从“决定某种修改“到“修改部署上线”这段时间被称为周期时间，是项目的一个重要的度量指标。

交付的问题

人力资源是昂贵而有价值的，应该集中人力资源来生产用户所需要的的新功能，尽可能快速交付这些新功能，而不是做枯燥且易出错的工作。

问题

1. 手工部署软件
2. 开发完成才向类生产环境部署
3. 手工配置生产环境

解决方案

1. 自动化部署（回滚）
2. 频繁修改与反馈
3. 预发布环境

软件部署的步骤

1. 配置运行环境
2. 发布正确版本
3. 配置应用程序

目前的软件部署逐渐像容器化，配置运行环境与发布软件版本通过镜像可以打包处理。
另外，应用程序的配置也开始向服务化发展，例如Apollo就是一个比较好的配置服务中间件。

版本控制

1. 每次提交代码都可能产生一个可发布的版本
2. 把所有的东西纳入版本控制
3. 提前并频繁地做让你感到痛苦的事
4. 越早发现的缺陷，修复的成本越低
5. 频繁提交代码到主干
6. 使用意义明显的提交注释

持续集成

通常项目在发布时才能运行，会导致风险都集中在发布这个阶段，清晰的版本控制可以在开发的每个阶段对现有功能进行测试。常用工具 JetBrains TeamCity。

好的方法应该与时俱进-端到端的设计思想与微服务架构

在现有开发环境下，大部分的项目使用的是微服务的架构，一个完整的功能在实现之前往往已经进行了结构的拆分，因此在开发者拿到实际的需求时，功能模块已经小到可以独立测试验证的规模。另外，端到端的设计思想不仅保证了各个模块之间独立性，也使测试工作变得更为简单。
目前在应对阶段性的迭代需求，通常使用的方法是确保主分支的正确性，每次构建都基于上一次成功的构建，这样即使在多人协作的环境下也能保证各个阶段的风险互相独立。