持续交付和持续部署在线视频

嗨，大家好

今天我们一起来讨论持续交付和持续部署

首先我们来看一个持续部署的Hello World

这个例子很简单，用Java写的一个小程序

发布到云端，用户可以直接访问

这相当于软件发布了第一个版本

假设现在需求发生了变化

程序员在自己的电脑上修改了代码

然后把代码提交到版本控制库

经过后台的持续集成和持续部署系统的自动化处
理

如果没有构建错误发生

第二个版本就可以直接发布给用户使用了

通过这个小程序我们可以看出

持续部署极大地缩短了从开发到部署的过程

减轻了手工部署的工作量，提高了开发到部署的
可靠性

那么这个Hello world是如何跑起来的呢？

我们这里来简单地介绍一下

需要说明的是，这个例子中所使用的工具

都可以由其他类似的工具代替

首先，开发者可以使用任意的编辑器来修改代码

然后把代码提交到版本控制库的服务器上去，也就
是Git

经过Git和Jenkins的配合，自动完成程序部署和
发布

全程不需要运维人员的参与

具体做法是在Git服务器当中设置一个Push钩子

每次更新代码的时候

Git都会给一个指定的远程Http地址

发送一个post请求

在Jenkins中配置Git源并设置token

供Git在远程调用的时候使用

Jenkins在接收到Git传递过来的消息之后

再触发一个远程构建命令到目标服务器

目标服务器会按照预先定义的任务列表

执行一系列的工作，比如利用maven 构建

一个新的hello项目包，然后重建Maven容器

构建一个新的Image并Push到Docker的私有库当中

最后，重新把Docker容器运行起来

这就完成了整个的持续部署流程

在这个例子当中，我们也看到了持续集成的影子

其实，持续交付和持续部署正是为了解决

持续集成到最后发布之间的最后一公里

我们知道，持续集成的目的并不是为了

得到可交付的软件版本

而是为了尽早的发现程序集成之后的错误

客户并不关心软件开发过程

他更想看到的是软件能够在生产环境当中跑起来

但是，从代码集成到最后的产品发布之间

还有很多工作要做

在许多软件项目当中，软件发布是一个需要

很多手工操作的过程

首先由运维团队负责安装好所需要的操作系统环
境

然后把软件所依赖的第三方软件安装好

下一步是手工将软件复制到软件生产环境中的主
机上

然后通过Web服务器，应用服务器或者

第三方的系统管理控制台来复制和创建配置信息

再把相关的数据复制到生产环境当中

最后启动应用程序

如果其中一个步骤没有顺利完成

可能导致各种各样的，意想不到的错误

在说到持续部署的时候

我们经常听到另外一个词就是持续交付

那么持续交付和持续部署有什么不同呢？

它们可以理解为都是对持续集成的延续

持续交付是在持续集成的基础上

将集成后的代码部署到更贴近真实生产环境的

“类生产环境”当中去

比如，我们在完成单元测试以后

可以把代码部署到数据库环境当中进行更多的测试

如果代码没有问题，可以继续手动部署到生产环
境中

而持续部署则是在持续交付的基础上

把部署到生产环境的过程自动化

大多数的公司如果没有制度的制约

或者其它条件的影响，都可以以持续部署为目标

在很多业务场景中

一种业务需要等待另外的功能出现之后才能上线

这样持续部署就没有办法完成了

所以，持续部署是不是适合某个公司

这是基于公司的业务需求而不是基于技术的限制

虽然持续部署并不适合所有的公司

但持续交付绝对是每个公司都应该追求的目标

只有当开发团队能够持续的交付代码的时候

他们才能有信心在短短的几分钟的时间内

把刚刚修改好的结果提交给客户

为客户提供真正的有价值的服务

持续部署的痛苦源于部署时的各个方面

比如需要部署到哪些环境，是测试环境还是实施
环境？

还有各种依赖包的版本，环境的配置管理等等等
等

都需要考虑

一般情况下，从安装软件到启动环境

第一步是选择要部署的软件包的版本

然后根据生产环境的要求生成新的部署实例

同时，要对目标机环境进行清理和配置

以满足软件产品的要求，比如硬盘，内存

以及第三方的依赖等等

把软件包下载到目标机之后

就可以开始进行环境配置，消除运行故障

确保程序可以正常运行

最后把用户的访问请求从旧版切换到新版

完成新版软件的部署

为了记录部署过程，为以后的软件维护提供支持

往往需要生成一份部署报告

来记录软件的相关配置参数

从手工部署到自动部署，再到持续部署

关键是要搭建一个自动化的部署流水线

部署流水线是指一个应用程序从构建，部署

测试到发布整个过程的自动化实现

部署流水线大致的工作方式是这样的

应用程序的配置、源代码、环境或者数据的每一
个变化

都会创建一个新的流水线实例

流水线的首要步骤之一就是创建二进制文件和安
装包

而其余的工作都是针对这些二进制文件和安装包

所做的一系列的测试

开发人员都会更加相信这些二进制文件、配置信
息

环境和数据所构成的这种特殊的组合能够正常工
作

如果这个产品通过了所有的测试

那么它就可以发布了

部署流水线的实现对于每个组织都是不同的

这取决于组织对软件发布的价值流的定义

但是它们背后的原则其实都是一样的

部署流水线的目标有三点

一是让构建、部署、测试和发布过程对所有人可
见

这样可以促进各个成员之间的协作

二是在整个部署过程当中改善了反馈

可以更早地发现和解决问题

三是可以通过一个完全自动化的过程

在任意环境上部署和发布软件的任意版本

这种能力是软件部署所追求的

也是客户的最终价值的体现

如果一个团队能够支持持续交付的话

一般都会满足如下的原则

首先，软件的发布应该是非常容易的事情

因为在软件发布之前，我们对发布流程的每一个
环节

都已经自动的测试过几百次了

持续交付是基于一个可重复的，而且十分可靠的
过程

这种可重复性和可靠性来源于我们

已经将几乎所有的事情都自动化了

并且将构建，部署，测试和发布软件

所需要的东西都纳入到了版本控制库的管理之中

如果集成让你觉得痛苦

你就应该在每次提交代码之后马上进行集成

如果测试让你痛苦

那么一开始就应该不断地进行测试

如果软件发布让你痛苦

就应该尝试在每次代码提交并通过所有的

自动化测试之后马上进行发布

如果不能发布到生产环境当中去

那就发布到类生产环境当中

另外，越早发现缺陷，修复它们的成本就越低

应该从一开始就测试

避免留到最后没有时间完成修复

测试也不单单是测试人员的责任

所有参与软件交付整个过程的人

都应该对软件的质量负责

随着持续交付和持续部署的快速发展

公司里成百上千的工程师们都在使用持续部署系
统

那么这又面临着更多的问题

首先是部署系统的性能问题

大量的部署、回滚，大量的文件传输

可想而知会给持续部署系统带来多大的压力

而且还要考虑未来更大规模的扩展性问题

第二是目标机环境的管理问题

比如多环境部署的时候

资源复用问题和新旧机器、新旧环境的切换问题
等等

第三是部署一致性事务问题

比如在部署多台服务器的时候

如果有依赖关系的包被部署到了不同的机器上

是要求他们一次性成功呢

要么是全部失败，最后回滚

第四个问题是部署环境的版本控制问题

当目标机部署的版本越来越多的时候

各个环境的包的版本开始出现混乱

各种依赖的版本也会出现不统一的情况

第五个问题就是部署计划过多

不同的部署策略都会产生不同的部署计划

还有就是部署的监控和维护问题

任何软件和系统都会有这样的问题

当规模上去之后，持续部署系统的监控和维护就
变得非常复杂

它的复杂程度往往不亚于一个大型的互联网应用

总之，持续集成，持续部署系统的实施并不是一
件简单的事情

需要我们根据团队的规模，开发自动化程度

项目特点等等这些因素来综合考虑，逐步推进

从传统的持续集成到持续交付

再到面向大型软件的持续部署

软件的开发模式和软件人员的分工都在发生变化

原本由软件开发人员运用自动化开发工具

进行的持续集成，进一步向交付和部署扩展

而原来的手工运维工作也逐渐被分摊到开发人员
身上

运维人员的工作也从重复枯燥的手工部署和维护

转为开发自动化的部署脚本

并逐步并入到开发人员的行列之中

云计算的出现，使得计算机本身也可以自动化的
创建和回收

这种环境管理的范畴将进一步地扩充

部署和运维工作也会脱离具体的机器和机房

可以在远端进行

相应的，部署的能力和灵活性也会出现质的飞跃

这都将进一步的减轻运维人员的工作压力

把运维和研发的工作融合在一起

持续交付和持续部署是一个很大很复杂的话题

只能在逐步提高团队的开发自动化水平的基础之
上

逐步推进，扎扎实实地做好每一个细节

最后才能踏上持续部署的高速列车

才能享受软件自动化带给开发团队和客户的

那种实实在在的好处

好，下次再见