引言
我在自动化部署，特别是公有云的自动化部署上工作多年，因此本文主要就这方面进行展开。
注意：这里提到的云主要指基础设施服务层，即IaaS，且泛指包括公有云、私有云或者混合云在内的所有IaaS层形态。
基本背景
由于工作关系，我在上一家公司(Autodesk)时从2008年底开始使用某国外公有云。当时参与项目中很重要的一部分工作就是帮助用户在我们的平台上(注：我们的平台运行在该云上)完成自动化部署。
由于整个部署非常重，涉及到平台自身部署、基础软件部署和用户传统软件部署。每次部署需要数个小时的时间，非常影响整个团队的工作效率。所以，我们花费了比较多的时间在构建自己的云自动化部署系统。
进入现在公司后，个人也推进了所在项目的部分自动化部署流程。尽管这个项目并不直接运行在云上，但在原来项目中总结出的办法还是有一定通用性。其中的部分经验也得以落实，最终效果也不错(整个系统的部署时间有了数量级的缩短)。
经历上面两个完全不同的项目，个人意识到，系统自身的可部署性，是能否落实自动化部署的关键所在(当然，这个结论的前提是团队已经认同自动化部署是团队效率和质量的基础性制度保证)。
而系统的可部署性是从架构设计到最终运维整个流程都需要考虑的因素。所以需要整个工程团队(开发、测试和运维)在系统可部署性上要达成一致，制定相关准则，整个自动化部署才能顺利推进。
所以，这里我从系统的“可部署实践准则”角度来分析如何保证自动化部署的成功实施：
尽管这里提到的很多准则不仅仅是针对云上系统，但是由于个人经验主要在云上系统的部署，同时个人相信未来绝大部分IT系统也都会运行在云上，所以会以云上系统的自动化部署为主来分享我的具体做法。
持续交付
在讨论自动化部署时，一定会涉及到持续交付。从逻辑的角度上看，自动化部署是持续交付的一个阶段。但是，自动化部署流程和系统仍然是可以独立于整个持续交付流程而独立运行。下图描述常见的持续交付流程以及自动化部署在其中的位置。
如上图所示，整个自动化部署流程会涉及到IT系统生命周期中的所有环境(开发、测试，预发和生产)。在这其中，由于生产系统的敏感性以及发布流程上的一些要求(如发布窗口期)，需要人工审批并触发部署流程。其他环境更推荐持续部署来加快迭代周期，尽早发现问题。
可部署实践准则
系统的可部署性一定是一个产品技术团队共同的职责：
- 云上IT系统应该遵循的准则有部分是流程上的，可能需要运维人员做标准化;
- 有些部分则是系统开发设计时的，需要开发人员考虑;
- 当然，测试工作也要考虑可部署性。
Rule 0 用版本管理系统(VCS)管理要发布的所有东西
这条规则比较容易理解，绝大部分团队也应该都在实际项目中很好得落实了这点。
需要注意的是，VCS系统不仅仅是用来管理你的代码，所有要发布的东西(包括代码、文档、视频等等)都可以(也应该)由统一的VCS来管理。至于VCS系统的选择，主流的软件(SVN、Git或者Perforce等)都能够很好支持整个持续交付和自动化部署流程。
Rule 1 统一管理构建出来的Artifacts
这条规则是很多团队容易忽视，但对自动化部署落实又非常重要的基础性准则。
什么是Artifacts?
Artifacts是指构建系统产生的任何需要部署的输出，如代码包、文档、静态资源等。
参考上面的持续集成流程图，可以看出Artifacts是所有自动部署流程的输入，它的管理质量直接会影响到部署流程的顺利程度和效率。关于Artifacts管理，现实工程中经常出现的几种情况如下：
团队完全无Artifacts管理。需要部署时直接从构建系统拷贝出来，通过邮件或者其他文件分享工具在团队内部传输。这种情况会导致整个部署流程完全失控，并且无法跟踪部署记录。
团队仅关注生产环境下的Artifacts管理。对于开发、测试或者预发环境的Artifacts管理没有任何规划和标准。这种情况会无法保证整个生命周期的部署一致性，极大影响团队的迭代效率。
对于Artifacts的管理完全等同于对于文件的管理，没有对Artifacts的metadata信息进行任何有效管理。由于缺乏Artifacts的metadata信息，导致部署流程和系统不容易获取当前Artifacts的元数据并以此采取相关操作。会让部署流程实现困难，部署质量无法保证。
在实际工程中，团队越早在Artifacts管理上达成统一标准，团队在推进自动化部署落地的难度就越小。个人认为，一个好的Artifacts管理方式需要有下面几个原则：
- 统一管理所有需要部署的Artifacts，包括开发、测试、预发和生产环境。只有这样，才能够为未来自动化部署流程和系统提供统一的输入。
- 统一的Artifacts元数据格式，包括当前Artifacts的构建信息、版本信息、可部署的环境等。
- 提供对接构建系统和部署系统的API接口。只有API接口才能够保证未来自动化的落地。
目前，市面上已经有很多Artifacts管理工具(如开源的Nexus)，可以帮助大家快速搭建整个Artifacts管理系统。如果你的系统是在云上部署，云供应商提供的对象存储服务也是不错的选择。
Rule 2 让部署系统管理你的云上基础设施
之所以把这一点放在前面，是因为它太重要了，而且也是和传统IT环境下自动化部署流程非常不同的地方。
在云上，一个非常重要的变化就是：所有的基础设施都可编程。
今天，所有的云供应商都必须提供基础设施的编程接口(如虚机启停API，存储接口，网络配置接口)。而有些更成熟的云供应商已经提供如CloudFormation服务，让你的IT系统基础设施能够完全可精确描述。
正因为如此，云上自动化部署系统可以完全管理起来自己的基础设施，并且通过API或者如CloudFormation服务快速、精确构建一致的IT运行基础设施。
当系统的自动化部署流程完全包括基础设施管理后，有如下几个明显好处：
- 任何时刻都可以获取环境完全一致的IT基础设施来运行系统(包括资源申请，环境搭建和软件部署)。这样，可以做到真正从零开始快速部署系统，而无需依赖任何其他部门(如IT部门)。
- IT基础设施的任何变化都能够被部署系统自动感知并采取相应的行动，保证IT系统的稳定性。
- IT系统可以根据系统当前情况随时向部署系统要求调整IT基础设施(如弹性伸缩)。
这里需要提到的一点就是，以Docker为代表的容器技术让运行时标准化和可编程化变得极其容易和轻量级。
但是，整个IT系统基础设施不仅仅包括系统的运行时环境，还包括网络规划、存储管理、计算资源管理等等。
而这些基础设施的程序化目前还只能通过云上IaaS层API或者类似CloudFormation来完成。所以，从这个角度看，Docker和IaaS并不是相互冲突，而是非常好的搭档，一同把整个IT系统的运维、管理成本大幅降低。
Rule 3 使用相同的部署流程管理你的开发、测试、预发和生产环境
这是一条在传统IT和云上都应该遵循的原则。在现实中，很多团队都喜欢把部署系统这个事情拖到上线前的***一刻才开始。而且，即使有自动化部署流程，也是和生产环境硬耦合，只能用于生产系统的部署。
这种做法虽然短时间来得快，但是在长期IT系统部署管理中会带来不少麻烦，个人觉得至少会包括如下两点：
- 这种部署方式导致不同环境的不一致性成为一个必然发生的事情，而这个问题最终会给你的生产环境带来致命故障。
- 这种部署方式导致开发、测试和上线过程极为低效。其实，在不同环境中，生产环境的部署频率是***的，而开发、测试部署几乎是工程团队每天都要做的事情。通过完全自动化的部署流程来管理所有环境将极大提高日常开发、测试效率。
所以，对于一个新项目，***在项目启动之初就能够把整个IT系统的自动化部署流程搭建成功，而且包括所有的环境。
而对于已经运行的项目，也要积极推动部署流程和部署环境的解耦。具体来说，常见的解决思路包括下面几个点：
- 使用不同的代码分支对应不同的环境，方便进行代码管理;
- 抽象、提出所有和环境相关的配置，并以配置服务的方式提供访问;
- 所有部署阶段都需要接受环境参数输入(可以是环境变量，也可以是参数)，并按照不同环境做相应部署操作;
- 给不同环境设置不同的部署频率和时间窗口;
- 给不同环境设置不同的部署操作和访问权限，以控制部署风险。
***，可能很多团队根本不可能有完整开发、测试和生产环境(或者这几个环境的差异性太大)，让同一套部署流程很难适配不同的环境。但是，因为云的出现，让我们获取不同环境的IT基础设施变得容易很多。
正因为如此，落实这条准则的难度在大幅下降(其实，开发测试已经成为很多企业用户开始尝试云的***站)，而这条规则带来的开发效率提升会让团队收益匪浅。
#p#
Rule 4 使用相同的部署流程管理全球各地的同一个IT系统
这是一条看起来对很多团队没什么用的准则。但是，云的出现让全球化部署变得非常容易，很多非常小的团队都可以做全球部署和运营。在云上，全球部署就是在云服务供应商的全球不同Region部署你的IT系统。
当然，即使在国内，为提供更好的系统访问速度，云供应商也会提供多个Region。由于云供应商不同的Region提供的服务都已经标准化，访问接口也都统一，这让使用相同部署流程管理全国(乃至全球)各地服务容易很多。为此，你的部署系统需要注意几点：
- 抽象、提出任何和部署Region相关的配置，并以配置服务的方式提供访问(配置服务有可能是集中化服务);
- 所有部署阶段都需要接受Region相关信息输入(可以是环境变量，也可以是参数);
- 需要提供不同Region的部署协调机制(例如，不同Region可能会在不同时区，这是处理和时间相关的部署任务需要特别小心的地方)。
- 一旦能够统一不同Region的部署流程，将会使得业务扩展时的IT部署变得容易很多，这也是整个系统可扩展性的重要体现。
现在，IT系统扩展性很多时候被局限在同一套系统在同一个地方能否快速伸缩，而忽略了IT系统在不同地点的快速复制能力。而这种快速复制能力不仅仅是业务全球化的需求，有时候也是解决系统自身容量扩展性的重要途径。
Rule 5 部署流程要优先满足热升级、热切换需求
在传统IT工程中，由于热升级和热切换实现起来可能比较困难，而系统升级、切换的频率也不一定高，很多时候这种功能性需求就会被当成“二等公民”看待。但这条准则恰恰相反，着重在强调“优先满足”。究其原因，个人认为有如下几点：
- “一直在线”已经成为新的刚需。
- 随着IT系统从后台支撑逐步转向前台直接服务客户。那种定期停机升级系统的方式已经不再可以接受。
- 尤其是互联网和移动互联网的普及，用户对于在线服务的默认期待已经是“任何时候，任何地点都可以访问”。在这种情况下，无论是架构设计还是部署流程都需要考虑“一直在线”这个目标。
- 热升级、热切换是持续交付的基础，是最终支撑业务快速发展的关键所在。实际工程中，产品团队的所有工作最终都得到生产环境接受检验。
- 只有整个部署流程完全支持热升级、热切换，产品的任何改进或需求确认才能够快速推到生产环境进行验证。如果部署流程无法支持热升级、热切换，那持续部署就必然造成频繁中断服务，进而影响业务。
正因为上面的原因，在整个架构和部署流程的设计过程中就需要优先考虑热升级、热切换，并坚持走下去。否则搭建的整个持续交付或者自动化部署流程都会事倍功半，最终走向失败。
在云上，由于基础设施资源的获取非常容易，在升级过程中让不同版本完全独立运行并逐步切换流量已经是一个成本不高的实践方式。所以，云上系统的热升级及热切换实现难度也有一定程度上的降低。
Rule 6 自动化、自动化还是自动化
就如“自动化部署”的名字所表述，自动化是其核心诉求，也是能够最终成功实践的技术保障。关于自动化的好处，相信不用展开说大家也都明白。但在现实过程中，大家面临的问题常常是如何实现平滑的实现自动化。个人推荐下面几个实践经验：
- 不要在自动化技术和工具上犹豫太久。
- 选择什么样的自动化部署工具对于还没有自动化流程的团队来说不是***要务。重要的是团队有决心、花时间去开始行动。
- 如果在选择技术和工具上真有什么建议的话，那就选团队最熟悉的技术和工具，这样对于快速出结果最为有利。而让团队尽快看到自动化部署的优势，从而坚定在这条路上走下去比选择什么样的工具要重要得多。
- 尽早建立“one-click”部署流程。这样可以让团队在“one-click”上有更早的约束，而不是在推进过程中不断妥协，***完全无法自动化。
- 在有“one-click”部署流程的前提下分步推进各个组件达到自动化部署的要求。
- 在分步骤推进过程中，一个好的策略是区分模块中的“常量”和“变量”。
这里的“常量”指系统部署中不经常变化的部分(如基础操作系统，基础软件等等)。对于这些部分，开始可以使用“预制模式”(如系统镜像)加入部署系统。而部署过程中经常变的“变量”部分，则需要在部署系统中重点考虑。当然，“常量”和“变量”的划分也不是绝对的。一般来说，部署系统都是从自动化最频繁变化的“变量”部分开始，逐步覆盖较少变化的“常量”部分。因为这样可以尽早***化自动化流程带来的价值。
Rule 7 让模块有自启动、自发现和自部署能力
在实施自动化部署的过程中，估计最容易让团队沮丧的就是不同模块之间的部署依赖关系。很多传统部署软件也试图通过各种方式(如可视化依赖关系)来降低维护部署依赖的难度，但很多时候最终效果并不好。
究其原因，个人觉得在业务场景的频繁变化中，让模块之间的紧耦合依赖关系很难长期保持稳定，部署系统也就很难高效维护这种多变的部署依赖关系。随着微服务概念的流行，更多人开始相信每个微服务模块都应该是独立部署、运维并提供服务。
这点体现在部署上，就是让每个模块有自启动、自发现和自部署的能力。具体来说，其包括下面几个方面：
- 每个模块在部署到系统中，都能够在无外接主动触发的前提下自我启动;
- 每个模块在启动后，都能够在无需外接主动告知的前提下发现自己承担的角色是什么;
- 每个模块在发现自我角色后，都能够在无需外接主动推送的前提下完成对自我角色的部署、配置、依赖检查并启动对外服务。
基于上面几点要求，个人在实践过程中采取的常见方法包括：
- 优先选择“运行时部署”，而不是“预定义模式”(最常见的预定义模式就是镜像交付);
- 每个模块需要自我描述如何完成自己的部署流程(如某大云的CodeDeploy服务，其中的appspec.yaml文件其实就是其对应模块自我部署的描述文件);
- 让每个模块独立进行部署，不要求必须有前置或者后置的模块部署。而模块之间的依赖则优先使用动态发现的模式进行。
#p#
Rule 8 让部署变成服务
当团队完成了整个自动化部署流程，记得在往前一步，把你的部署工具变成一个对内的部署服务，让团队每个人(包括非技术人员或者新来的同事)也能够快速完成部署。
为让部署成为服务，你可能需要实现一个Portal，或者再添加一个邮件通知服务。当然，你也可以把整个部署服务做得更好，甚至服务于其他团队。无论如何，这都会给团队带来很大的好处，因为它降低了整个系统的使用门槛，让更多的人从中获益。
Rule 9 用户全面监控保障自动化部署
这是***一条准则，但是可能也是很多开始尝试自动化部署的团队最担心的问题：如果自动化部署出问题了咋办?
人工部署时候还可以一步步观察结果，由人来把关部署流程，避免不良后果快速扩大。其实，在回答这个问题之前，如果大家仔细回顾人肉部署带来的各种故障，一定会发现人为失误引起的故障比例会大得惊人。
而自动化部署的一个目标恰恰就是为了减少人为失误导致的故障。当然，为了避免自动化部署的负面影响，你需要注意下面几个方面：
- 请为你的服务提供全面的监控。这不仅仅是日常运维的需要，也是自动化部署的需要。而且，这里的监控需要包括很多应用级别的监控，而不仅仅是类似CPU、Memory这些基础性监控。这样，可以方便团队及时发现自动部署引起的系统服务问题。
- 在部署流程中提供快速回滚(Rollback)方案。可靠的回滚方案会让你推进自动化部署的时候有更多的信心。
- 对每个模块每个部署阶段做更多的pre-check和post-check。想想如果你人肉做部署的时候是怎样check每一个部署阶段是否成功，如何判断是否问题，然后尽量把这些判断逻辑都自动化起来。
***，如果你是团队内希望推动自动化部署的同学，下面两点经验或许在你推进过程中能帮助到你：
- 痛点原则。在推进自动化部署过程中，一个常见的问题就是时间问题。团队总是会被不同的业务需求推着往前走，而自动化部署这种非功能性需求经常无法得到资源保障。这时候，你需要不断问自己的一个问题是“如果我现在只能在自动化部署方面做一见事情，那我需要做什么”。记得找到痛点***的唯一一件事情作为突破口，尽快让团队感受到自动化部署带来的优势，才能够得到团队更多的支持。
- 不回头原则。在推进自动化部署过程中，团结经常会因为自动化部署带来的问题或者自动化部署流程不完善而放弃尝试。这时候，作为主动推进的人，一定要及时跟进发现系统问题，而不是让团队轻易走回头路。
当然，你肯定会说搞定老板才是最核心的保障。如果你能够有一个完全支持你的老板，那你是幸运的。
更多时候，老板会是一种半信半疑的态度对待自动化部署。这时候，找到突破点，快速见效并能坚持下去可能就是你能说服老板的***策略。
http://blog.xuguilin.me/2014/01/22/autodeploy-on-aws.html
作者介绍
徐桂林
阿里云日志服务技术专家，硕士毕业，曾任职AutoDesk等公司，擅长云计算，DevOps等。
如何一起愉快地发展
“高效运维”公众号(如下二维码)值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上精彩分享及群友原创。“高效运维”也是互联网专栏《高效运维***实践》及运维2.0官方公众号。
提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请;或申请加入技术交流群(技术讨论为主，没主群那么多规矩，更热闹)。
重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。
| 本文转自“高效运维”微信订阅号，特此感谢。 |
