前言
作为一个软件从业者,我们的工作就是用最快的速度将用户的点子转换成软件交付。
从两个实际问题入手
一个复杂项目新特性的部署需要多久?
在你的公司里,仅涉及一行代码的改动需要花多长时间才能部署上线?你是处理方式是否可重复和可靠?
从“决定某种修改“到“修改部署上线”这段时间被称为周期时间,是项目的一个重要的度量指标。
交付的问题
人力资源是昂贵而有价值的,应该集中人力资源来生产用户所需要的的新功能,尽可能快速交付这些新功能,而不是做枯燥且易出错的工作。
问题
- 手工部署软件
- 开发完成才向类生产环境部署
- 手工配置生产环境
解决方案
- 自动化部署(回滚)
- 频繁修改与反馈
- 预发布环境
软件部署的步骤
- 配置运行环境
- 发布正确版本
- 配置应用程序
目前的软件部署逐渐像容器化,配置运行环境与发布软件版本通过镜像可以打包处理。
另外,应用程序的配置也开始向服务化发展,例如Apollo就是一个比较好的配置服务中间件。
版本控制
- 每次提交代码都可能产生一个可发布的版本
- 把所有的东西纳入版本控制
- 提前并频繁地做让你感到痛苦的事
- 越早发现的缺陷,修复的成本越低
- 频繁提交代码到主干
- 使用意义明显的提交注释
持续集成
通常项目在发布时才能运行,会导致风险都集中在发布这个阶段,清晰的版本控制可以在开发的每个阶段对现有功能进行测试。常用工具 JetBrains TeamCity。
好的方法应该与时俱进-端到端的设计思想与微服务架构
在现有开发环境下,大部分的项目使用的是微服务的架构,一个完整的功能在实现之前往往已经进行了结构的拆分,因此在开发者拿到实际的需求时,功能模块已经小到可以独立测试验证的规模。另外,端到端的设计思想不仅保证了各个模块之间独立性,也使测试工作变得更为简单。
目前在应对阶段性的迭代需求,通常使用的方法是确保主分支的正确性,每次构建都基于上一次成功的构建,这样即使在多人协作的环境下也能保证各个阶段的风险互相独立。