虽然,读者朋友可能觉得自己已经理解这些概念了,但是,还是希望读者读完。笔者从权威的书上将这些概念的定义摘抄下来,最后给出笔者对于“持续”的理解。
构建(Build):
一次构建不止是一次编译(或者动态语言中的某种称谓)。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程。摘自《持续集成》
其实构建过程中还可以包括测试、部署。这点可能和很多人的理解有出入。这里就会有疑问了,既然构建中包括了部署,那么持续构建与持续部署又有什么关系?笔者是这样理解的,因为软件系统是需要部署了,才能测试的,所以,为了在构建过程加入测试,就必须引入部署。
部署(Deployment):
部署是一种技术领域的操作,也就是说从某处获取软件包,并按照预先设计的方案将其安装在计算节点上,并确保系统可以正常启动,但它并不定意味着“必须包含业务功能的发布或交付”。摘自《持续交付2.0》
交付(Delivery,也被称为发布):
是一个业务决策活动,通常也被称为“发布”,也就是说,如果将新的构建的特性交到客户(用户)手中,用户就可以看到并使用它们。摘自《持续交付2.0》
我们可以将代码部署上生产环境,但是我们可以通过某种技术手段,让用户看不到,也不能使用它。这就是只部署,但不交付。部署与交付的差异在于部署是技术端操作、交付是业务端决策。
这里,读者可能又有疑问了:未完成的功能,可以部署上生产环境吗?笔者的回答:是的。前提是你能控制该功能是否对用户可见。这称为功能开关。