随想之六-持续部署
一 《持续交付》
书籍推荐
1 手工部署软件 模式
-
有一份非常详尽的文档,该文档描述了执行步骤及每个步骤中易出错的地方。
-
以手工测试来确认该应用程序是否运行正确。
-
在发布当天开发团队频繁地接到电话,客户要求解释部署为何会出错。
-
在发布时,常常会修正一些在发布过程中发现的问题。
-
如果是集群环境部署,常常发现在集群中各环境的配置都不相同,比如应用服务器的连接池设置不同或文件系统有不同的目录结构等。
-
发布过程需要较长的时间(超过几分钟)。
-
发布结果不可预测,常常不得不回滚或遇到不可预见的问题。
-
发布之后凌晨两点还睡眼惺忪地坐在显示器前,绞尽脑汁想着怎么让刚刚部署的应用程序能够正常工作。
相反,随着时间的推移,部署应该走向完全自动化,即对于那些负责将应用程序部署到开发环境、测试环境或生产环境的人来说,应该只需要做两件事:
(1)挑选版本及需要部署的环境,(2)按一下“部署”按钮
二 什么是持续交付和持续部署？
维基百科定义：
续交付（Continuous delivery，缩写为 CD），是一种软件工程方法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的编译、测试与发布变得更快更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
持续交付所描述的软件开发，是从原始需求识别到 最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺 畅流动，能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了 更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少 浪费。
理想场景：
有一天，业务人员急冲冲的跑过来，对你说生产上出现了一个严重 BUG，必须要尽快修复。你听完问题描述后，胸有成竹坐定并迅速定位问题，随后改动了一行代码并提交，系统开始自动编译、各个环境自动化测试、发布上线。几分钟后，生产环境上该 BUG 已经被修复掉。
概念澄清：
活动图描述：
持续交付归纳出四个关键要素：持续集成、自动化测试、自动化部署、流水线。
