自动化持续部署是业界最佳实践,以此为目标,能优化IT模式。
在接触的很多的企业中,持续部署实践依然还有很多不足,基本上部署靠人,更别谈自动化了。我一直强调持续部署是IT交付的核心能力,直接关联到研发/测试和运维多个团队,可以成为一个运维的核心平台。自动化部署能力的高与低,能映射出IT能力的诸多方面的问题,比如说流程上/环境管理上/服务耦合上/平台能力上等等。
个人已经做了三个持续部署系统,每做一个持续部署系统都给整个IT团队带来的巨大收益。当带着这些经历再回过头去看《持续交付》这本书的时候,书中的很多观点让我感触很多,基本上每个点都有自己的感受。
让我们来看看《持续交付》中总结的很多错误的模式,这些错误的模式的确是现实存在的,且必须要避免的,称之为反模式,具体如下:
一、反模式1:手工部署软件
对于现在的大多数应用程序来说,无论规模大小,其部署过程都比较复杂,而且包含很多非常灵活的部分。许多组织都使用手工方式发布软件,也就是说部署应用程序所需的步骤是独立的原子性操作,由某个人或某个小组来分别执行。每个步骤里都有一些需要人为判断的事情,因此很容易发生人为错误。即便不是这样,这些步骤的执行顺序和时机的不同也会导致结果的差异性,而这种差异性很可能给我们带来不良后果。这种反模式的特征如下:
相反,随着时间的推移,部署应该走向完全自动化,即对于那些负责将应用程序部署到开发环境、测试环境或生产环境的人来说,应该只需要做两件事:(1)挑选版本及需要部署的环境,(2)按一下“部署”按钮。对于套装软件的发布来说,还应该有一个创建安装程序的自动化过程。
当然,并不是所有的人都热衷于这个想法。那么,我们先来解释一下为什么把自动化部署看做是一个必不可少的目标。
当然,手工密集型的发布工作有时也会进行得非常顺利。有没有可能是糟糕的情况刚巧都被我们撞见了呢?假如在整个软件生产过程中它还算不上一个易出错的步骤,那么为什么还总要这么严阵以待呢?为什么需要这些流程和文档呢?为什么团队在周末还要加班呢?为什么还要求大家原地待命,以防意外发生呢?
二、反模式2:开发完成之后才向类生产环境部署
在这一模式下,当软件被第一次部署到类生产环境(比如试运行环境)时,就是 大部分开发工作完成时,至少是开发团队认为“该软件开发完成了”。这种模式中,经常出现下面这些情况:
每当需要将软件部署到试运行环境时,都要组建一个团队来完成这项任务,有时候这个团队是一个全功能团队,然而在大型组织中,这种部署责任通常落在多个分立的团队肩上。
一旦将应用程序部署到了试运行环境,我们常常会发现新的缺陷。遗憾的是,我们常常没有时间修复所有问题,因为最后期限马上就到了,而且项目进行到这个阶段时,推迟发布日期是不能被人接受的。所以,大多数严重缺陷被匆忙修复,而为了安全起见,项目经理会保存一份已知缺陷列表,可是当下一次发布开始时,这些缺陷的优先级还是常常被排得很低。
有的时候,情况会比这还糟,以下这些事情会使与发布相关的问题恶化:
三、反模式3:生产环境的手工配置管理
很多组织通过专门的运维团队来管理生产环境的配置。如果需要修改一些东西, 比如修改数据库的连接配置或者增加应用服务器线程池中的线程数,就由这个团队登 录到生产服务器上进行手工修改。如果把这样一个修改记录下来,那么就相当于是变更管理数据库中的一条记录了。这种反模式的特征如下。
运维的关键实践之一就是配置管理,其责任之一就是让你能够重复地创建那些你开发的应用程序所依赖的每个基础设施。这意味着操作系统、补丁级别、操作系 统配置、应用程序所依赖的其他软件及其配置、基础设施的配置等都应该处于受控状态。你应该具有重建生产环境的能力,最好是能通过自动化的方式重建生产环境。
我们也应该有能力在部署出错时,通过同一个自动化过程将系统回滚到之前的版本。
四、问题的答案:自动化部署
实现一个完善的自动构建、部署、测试和发布系统。为了让这个系统能够良好运行下去,我们还帮助他们采用了一些必要的开发实践和技术(大系统做小/维服务/灰度能力等等)。如何使用部署流水线,将高度自动化的测试和部署以及全面的配置管理结合在一起,实现一键式软件发布。也就是说,只需要点击一下鼠标,就可以将软件部署到任何目标环境,包括开发环境、测试环境或生产环境。
——————以上观点摘自《持续交付》
见到的通行做法是三种:
1、自动化脚本来封装,用expect+ssh
2、用配置管理工具来实现
3、在Jenkins中写插件来实现
但我依然觉得,这不是我要的可视化+自动化部署系统,一般都选择自己实现。
1、YY包部署系统
缺点:
A、对配置管理支持的不是很好
B、环境管理能力很弱
C、没有以应用维度进行管理
2、UC的持续部署系统
这是利用公司另外一个系统基础上修改过来的,支持了游戏业务的特殊发布场景,做了一些优化,但还是有一些缺点。
缺点:
A、应用程序和底层Agent的耦合太重,Agent的异常会影响应用程序的工作。
B、系统架构设计很复杂,涉及组件过多,基于CF修改过来的。
C、基于CF的PAAS平台每支持一种语言就要重新开发。
D、对于包的抽象能力不够,管理能力需要在Agent层封装。当然这个能力可以更上层实现,兼容各种操作场景。
3、新持续部署系统(doing)
基于包的全新抽象,支持各种语言;开放包的管理能力给用户,适应各种场景;支持对包/配置/环境的可视化管理;支持灰度,支持快速回滚;....等等。