【云干货分享】发布自动化技术Release Automation详解

amy26

云智慧 Patrick

导语：应用功能从一段段程序代码，到生产环境中可用的服务，要经历开发、测试和部署上线等一系列过程，随着云计算和移动互联网时代的到来，敏捷开发、DevOps成为流行，应用开发和迭代周期越来越短，然而行百里者半九十，应用发布环节正在成为IT开发的瓶颈，影响着应用上线的效率。
这次分享由云智慧企业大客户资深技术顾问肖澍（Patrick）带来，肖澍多年来一直从事企业IT解决方案和产品售前、架构咨询与服务交付等工作， 2004年涉足IT监控，中间件，数据库和行业应用软件领域，积累了丰富的行业服务经验。他在分享中将为您详解DevOps时代如何通过发布自动化技术Release Automation解决敏捷交付的发布难题，以下为分享内容：
应用功能从一段段程序代码，到生产环境中可用的服务，需要经历多个阶段：

1，敏捷开发，每日构建，多团队构建成果的装配集成测试；
2，集成测试，性能测试，验收测试，生产环节，需要供应一致的环境配置，包括OS、Web Server、中间件、数据库等；
3，程序验证后的部署上线。
频繁的应用发布需求对企业IT运维团队的手动/脚本发布方式带来更大挑战，在不同环境中分别进行修改，并保持这些更新在生产环境中同步，需要耗费大量时间，而且每次更新都得从零开始。此外，跟踪应用变化和管理分布式数据中心中的应用差异也非常繁琐，时间成本大幅攀升。
因此企业需要一种新技术和管理手段，来解决敏捷交付的发布难题。

因为手动流程容易发生错误，而且成本高，花费时间也多。减少或消除手动、半自动化脚本，代之以所有应用系统相关方和环境中协调配合的进程，实现应用变化的标准化、优化和加速。这就催生了一种自动化发布的技术手段，这种企业级持续交付解决方案，通过对应用进行编排，在开发与生产环境中推广，用于创建、测试并自动化执行复杂应用的发布任务。
开发机构包括多样化的工作团队，分别负责代码、数据和内容，涉及整个应用开发生命周期中的所有阶段，每个团队都有自己不同的需求。通过引入自动化平台，建立端到端的操作自动化，能够有效减少人工干预环节工作量，降低人为操作失误。
1、建立应用模型
自动化的基础，是首先建立一个应用模型。

遵从以应用为中心的理念，快速对应用系统进行拆分，将复杂的应用系统环境和发布任务切分成各种可重用的技术组件，以快速组合并管理这些组件。利用功能强大的可视化应用建模能力，运维团队可针对发布部署到故障维护和审计在内的所有应用服务任务进行自动化。支持应用服务工作流，可实现多层应用、多实例、分布式环境下的复杂应用发布自动化。
发布自动化系统使用以应用为中心的发布模型管理应用发布，应用发布模型包括涉及应用部件，应用架构，自动化过程和环境组件，并提供与自动化发布过程相关的应用架构，包括技术组件，架构，服务器类型和环境等信息。任何复杂的应用，最终都可以被拆解成不同的架构组件。
这样，就完成了发布自动化的第一步。
2、开箱即用的动作库
第二步，发布自动化平台内置提供了大量开箱即用的动作库 (非预先创建的脚本)，用于与各种不同的服务器，操作系统，应用服务器进行交互， 提供开箱即用的标准化操作。
比如，要执行linux os的文件复制命令，只需调用一个文件动作，这个动作自身，可以生成linux 命令。
所有应用发布相关的部署任务都基于抽象后的基础设施工作流构建，以便独立于最后执行的目标服务器 ，并允许针对不同的服务器组执行相同的工作流程执行。在此过程中，应用发布执行的每个环境设置和管理特定的配置信息，例如从哪个版本库中检出最后构建的版本 (生产和测试可能是不同的)，都以高度灵活的配置驱动方式完成。
3、工作流可视化

通过可视化的工作流，来调度发布操作中涉及的各种动作，是自动化的核心关键。
部署工作流程和动作可以通过图形化界面进行配置，动作之间和应用各层之间的依赖关系完全以图形化拖拽方式完成。不需脚本编程就可以实现完整的部署流程逻辑：如 for, for each, if then else, while loops等流程控制。
此外，应用发布过程支持从外部数据源(部署清单，部署配置文件)获取过程执行所需的任务实体，并提供完整的部署回退。利用应用发布过程，还可以重用部署的单个步骤，如文件处理、分发、注册表设置、RPM、目录操作、开通、启停服务、安装、部署等。
应用发布过程可与目标环境解耦，无需特别针对目标执行环境进行技术设计，可自动按照配置进行映射。
一套完整的发布过程制定后，可以自动适配不同的目标环境，即可支持linux, 又能在unix上执行。
每一个发布过程，都可以自动确保在部署过程中各层之间的依赖关系，例如开始执行Web服务器上的一组动作，然后执行数据库层上的动作，之后回到Web服务器上执行另外一组动作。所有发布过程东都具有可视化配置和监控过程执行的能力。
发布自动化支持与多种外部系统对接，例如自动从Jenkins中提取构建包，与变更管理系统集成，与Nexus工件库或其他版本控制系统集成，也可保存与发布任务有关的实体文件，如程序包、配置文件、补丁或发布介质等。
最后，自动化发布系统，提供报告和仪表盘，为整体任务发布提供了高度可视化环境，使IT运维团队能更直观全面的准确掌握任务执行情况。 IT管理人员能更直观的了解哪个用户，什么时间，在哪个环境中，做了具体什么操作。
这些功能，在敏捷开发的频繁变更时，可以极大提高部署效率。

问：DevOps是不是更适合发布自动化？
答：持续交付，又是DevOps的重要实践之一，CI = 持续集成，是DevOps的另外一个重要实践
问：持续交付，持续集成，区别在哪里？
答：CI在于自动化的代码构建，随时保证生成可部署的程序包；CD在于自动化的把这些程序真正发布到生产环境中，现在有些开发人员，借助Jenkins、Puppt、Chef这类工具在做自动化发布。Jenkins里面有一些基于脚本的功能可以辅助部署。
DevOps有个Automation Everything的思路，就是把所有能自动化的事情都automate，包括持续构建，持续验证（测试），持续集成……
问：持续交付可以帮助到运维工作吧？
答：是的，大家可以想象一下，你自己是CIO，管理1000人，分为几十、上百个开发团队，每个团队都问运维要开发，测试，验收环境。这些环境规模有大小的区别，但配置要尽量一致。
首先，供应环境的工作量就非常大；然后，每个项目假如每天都有迭代，就需要运维辅助完成上线部署操作。手工或者脚本方式，对运维人员的技术要求很高，涉及网络、OS、VM、WEB SERVER、MIDDLEWARE、DB一大堆环节，很容易出错。
自动化工具增加了准确性，降低了操作，配置错误导致的故障风险，还提升了效率。
问：持续集成已经包含了构建、测试和发布，为什么还要用发布自动化？
答：现在的CI工具确实都带了一些发布的功能，但CI工具的发布定位比较窄，目标环境比较单一，而且大多数是基于手工脚本，所以这里面就有商业工具的市场了。
问：我认为的CI，不仅仅是一些工具，更是一套研发管理的方法集。
答：当然，DevOps、CI、CD，这些其实都不是指具体的技术和工具，首先是理念和方法，工具只是辅助的手段，是固化理念和流程落地。大家听说过thought works这家公司么？创始人是敏捷宣言的起草者，这家公司的主要业务就是卖面向敏捷，精艺和DevOps指导咨询服务的，他们在国内的业务就是从教企业怎么做敏捷开发起步的。
以上是Patrix对于发布自动化技术Release Automation分享的全部内容，更多技术干货请关注云智慧微信公众帐号。