持续交付流水线的敏捷利器:环境配置管理与应用部署自动化


作者介绍

陈能技,DBAplus社群原创专家,新炬网络首席DevOps专家。14年开发测试与质量架构经验,擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。

 

业界关于持续交付有如下图所示的5级能力成熟度模型:

今天我们就来聊聊持续交付流水线中的环境配置管理工作。

 DevOps、持续交付、环境配置管理

持续交付作为DevOps的核心实践,涵盖了从开发到测试到部署上线的过程,是持续集成的延伸,持续交付流水线中涉及很多环节,而每个环节基本上都跟环境配置管理相关。

 

例如开发阶段的构建环境、联调环境、测试阶段的功能测试环境、性能测试环境、安全测试环境、兼容性测试环境,发布生产前的准生产部署环境等。

整个开发环境可分为本地开发环境,测试环境,准生产环境,生产环境。当产品通过了各种测试,例如: 功能测试,性能测试,系统测试等等,需要部署到准生产环境,其特点是与生产环境参数基本一致,在用户接受测试通过之后,可根据业务需求或决策部署在生产环境了。

 传统模式下的环境配置管理问题

DevOps的目标是通过建立并不断完善持续交付的流水线,最终达到无需人工干预的持续交付过程。从代码开发到持续集成,创建测试环境,运行测试并报告结果,完成各种测试计划中任务,最后是业务决策交付或部署上线。

下图是一个典型的持续交付流水线,可以看到流水线经过了好几套环境的测试、验证,可见环境配置管理工作的重要性。

传统模式下的环境配置管理通常存在以下问题:

1、手工准备环境,对冲突无控制。

  • 软件安装麻烦、来源不一致、安装方式不一致、杂乱无章。
  • 共用一个服务器开发环境,隔离性差,互相冲突。
  • 可移植性差,例如和生产环境不一致,开发人员之间也无法共享;新人入职通常又折腾一遍开发环境,无法快速搭建。

2、基础设施环境的准备工作繁琐,跨部门流程冗长

3、手工部署软件

部署和发布过程以及发布后的验证都依赖人工进行,容易出错,并且效率有待提升。

4、环境资源无法共享

环境资源缺乏动态调配能力,造成资源浪费。

 环境配置管理与应用部署自动化

为了有效解决上述问题,提高持续交付流水线的效率,我们需要开展环境集中配置管理的工作。主要从以下几方面入手:

  • 基础设施环境配置管理

基础设施(Infrastructure)代表了你所在组织中的所有环境,以及支持其运行的所有服务,如DNS服务器、防火墙、路由器、版本控制库、存储、监控应用、邮件服务器,等等。

基础设施管理的基本原则:

(1)使用保存于版本控制库中的配置信息来指定基础设施所处的状态;

(2)基础设施应该具有自治特性,即它应该自动地将自己设定为所需状态;

 

基础设施不但应该具有自治特性,而且应该是非常容易重新搭建的。当出现硬件或其它问题时,就能迅速重建一个全新的已知状态的环境配置。所以,基础设施的准备工作也应该是一个自动化过程。自动化的准备工作与自治性的维护相结合,可保证一旦出现问题就能在可预见的时间内重建基础设施。

 

 

(3)通过监测手段,应该每时每刻都能掌握基础设施的实时状况。

应该与交付流程的其它方面一样,把创建和维护基础设施需要的所有内容都进行版本控制:

(1)操作系统的安装定义项(例如使用Debian Preseed、RedHat Kickstart和Solaris Jumpstart)。

(2)数据中心自动化工具的配置信息,例如Puppet、CfEngine等。

(3)通用基础设施配置信息,例如DNS区域文件、DHCP和SMTP服务器配置文件、防火墙配置文件等。

(4)用于管理基础设施的所有脚本。

部署流水线的基础设施变更管理工作:

(1)对于任何基础设施的变更部署到生产环境之前,应该验证所有的应用程序在这些变更之后也能正常工作,并确保在该新版本的基础设施之上,所有受到影响的应用程序的功能和非功能测试都能成功通过。

(2)将这些变更应用到测试和生产环境上。

(3)流水线应该执行部署测试,确保新的基础设施配置已成功部署。

基础设施的版本配置管理工作还包括:

管理应用程序和应用程序所依赖的基础设施之间的版本依赖。也就是说,为了能够正常工作,就要记录每个应用程序需要哪个版本的基础设施。
 应用部署与发布管理

良好的环境配置管理能为应用部署和发布创造高效的环境,而应用部署与发布工作本身也应该做集中化的配置管理工作。例如,制定完善的发布计划:

1、第一次部署应用程序时所需的步骤;

2、作为部署过程的一部分,如何对应用程序以及他所使用的服务进行冒烟测试;

3、如果部署出现问题,需要哪些步骤来撤销部署;

4、对应用程序的状态进行备份和恢复的步骤是什么;

5、在不破坏应用程序状态的前提下,升级应用程序所需要的步骤是什么;

6、日志文件放在哪里,以及他包含什么样的信息描述;

7、如何对应用程序进行监控;

8、作为发布的一部分,对必要的数据进行迁移的步骤有哪些;

9、前一次部署中存在问题的记录以及他们的解决方案是什么。

对发布过程进行建模并让构建晋级:

1、为了达到发布质量,一个构建版本要通过哪些测试阶段(例如集成测试、QA验收测试、用户验收测试、试运行以及生产环境)

2、每个阶段需要设置什么样的晋级门槛或需要什么样的签字许可。

3、对于每个晋级门槛来说,谁有权批准让某个构建通过该阶段。

最后,还需要建立高效的自动化部署机制:

每个需要部署应用程序的人都能用这种自动化部署机制,而不需要了解部署本身相关的任何技术知识,一旦部署完成后,自动运行一个冒烟测试来验证部署成功与否,这样,做应用部署操作的人(包括分析人员、测试人员或运维人员)就可以确认该系统运行正常,即使不能正常运行,也很容易找到原因。

1、选择需要部署的应用程序版本之后自动执行后续的部署步骤。

2、环境及相关基础设施的准备应该以完全自动化的方式进行。

3、部署应用程序的二进制包应该从制品库中拿到,而不是每次部署时重新构建出来。

4、对应用程序进行配置。应用程序的配置信息应该以某种统一的方式来管理,并在部署和运行时使用。

5、准备或迁移该应用程序所管理的数据。

6、对部署进行冒烟测试。

7、执行测试(可能是手工的,也可能是自动化的)

8、如果应用程序的这个构建版本通过了这些测试,允许其晋级到下一个环境中。

9、如果应用程序的这个构建版本没能通过这些测试,记录一下是什么原因。

 小结

本文简述了传统环境配置管理存在的问题,以及在持续交付流水线工作模式下的环境配置管理的具体做法。

随着Puppet、Ansible、SaltStack,持续集成、持续交付、DevOps,Docker、开发测试云平台等技术和方法的日渐成熟和被企业所接受,相信越往后边,持续交付流水线的环境配置管理、应用部署管理工作将越自动化、敏捷化!

时间: 2024-09-20 14:56:38

持续交付流水线的敏捷利器:环境配置管理与应用部署自动化的相关文章

谈谈企业的持续交付流水线设计

本文讲的是谈谈企业的持续交付流水线设计,有一天,业务人员急冲冲的跑过来,对你说生产上出现了一个严重BUG,必须要尽快修复.你听完问题描述后,胸有成竹坐定并迅速定位问题,随后改动了一行代码并提交,系统开始自动编译.各个环境自动化测试.发布上线.几分钟后,生产环境上该BUG已经被修复掉. 上面所提到的场景,这是不是很美妙?但是想必不少读者要忍不住要吐槽了,这太不实际了:新功能上线测试不要时间么?新增了功能肯定要做回归测试,这都需要一定的时间.况且怎么可以随便部署上线?还得通过预发演练.走发布审批流程

持续交付与传统敏捷的矛盾

我在采用持续交付的组织中和开发团队工作一起工作,发现很多开发者认为的正确的敏捷团队的工作方式,在这里跑得不是很顺畅.我认为传统敏捷与持续交付的矛盾的根本在于,二者是采用不同的方式把软件变得"可以发布"(ready to release)的. 软件交付的演进 使软件变得可以发布的过程一直在不停进化,下面是一个简要的介绍: 瀑布模型 瀑布模型认为,当一个软件所有的功能都发开完毕的时候(也就是功能完整的时候),才可以发布. 敏捷: 敏捷引入的思想是,在整个开发过程中,软件都应该"可

阿里技术专家:持续交付与微服务背后的实践逻辑

讲师介绍 崔力强 阿里巴巴技术专家   <微服务设计>中文译者之一:曾在ThoughtWorks任职软件交付和敏捷顾问: 对持续集成.自动化测试有丰富经验:目前专注于持续交付SaaS产品的开发,提供精益需求管理.软件设计.敏捷转型相关咨询服务.    前言 大家好,我是崔力强.目前在阿里巴巴任职.负责一款持续交付领域的SaaS产品的开发.非常高兴能够和大家分享持续交付和微服务的话题. 本次分享的重点是持续交付.也会提到一些微服务的概念,以及持续交付和微服务之间的关系.今天会涉及的一些实践可能大

DevOps和持续交付

小编说:DevOps 领域在近年来变得流行而普遍.由开发(developers)和运维(operations)组成的"共同协作",归根结底,就是为了提高产品质量. 本文选自<DevOps实践>,透过本文您将了解如何在大规模敏捷背景和不同的敏捷开发周期中使用DevOps. DevOps简介 在定义上,DevOps是一个涵盖着几条线的领域.它既非常实用又贴近实践.但与此同时,你需要了解的不仅有技术背景,还有非技术的文化方面. DevOps由开发(developments)和运维

微服务、容器与持续交付

本文件的是微服务.容器与持续交付[编者的话]就像木炭.火硝和硫磺遇到了一起.当微服务.容器和持续交付遇到了一起,这注定会掀起一场变革. 微服务 如果非要给微服务找一个理由,单一职责就足够了.我们把因相同原因而变化的东西聚合到一起,而把因不同原因而变化的东西分离开.我们称之为单一职责原则SRP. 尤其是大型和长期运营的项目群,随着时间的推移,需求一定是不断增加和变更的.但我们不希望掉进"焦油坑".我们希望我们的项目群是符合"开闭原则"的.在某个时期我们寄希望于一个统一

DevOps整合开发和操作以实现多平台的高质量和持续交付

因此,对于企业来说,最重要的是要进行充分考虑,不仅包括移动功能的开发.还有如何部署,以及如何随着时间的推移对其实施变更时确保功能的持续性.本文包括 DevOps(开发 & 操作)如何帮助处理向不同设备部署不同版本应用程序的问题. 移动应用程序:新思维过程和行为 在移动空间中,有大量潜在的部署平台.在某种程度上,这类似于许多年前存在多个竞争性标准时的传统桌面开发情况.移动方面的不同之处是不仅存在多个竞争性操作系统(比如 Android.iOS.BlackBerry 和 Windows),还存在多个

阿里巴巴1682亿背后的“企业级”高效持续交付

导读:在2017北京云栖大会上,阿里巴巴高级技术专家陈鑫(花名神秀),给大家带来了<1682亿背后的企业级高效持续交付>.神秀从技术负责人关心的研发流程混乱.质量无法保障.环境管理低效.资源浪费等方面,结合阿里巴巴的DevOps实践,深度解析了企业级持续交付如何做,企业如何高效协作,控制成本的精彩分享. 一.技术管理者的烦恼 开发工程师的日常 我们看下开发工程师每天都是如何工作的.老三样总是逃不掉,写代码.测试.发布到线上.具体来看首先要拉分支,每个团队一般都有自己的研发规范,团队成员都需要遵

让IT跟上业务思考的速度--从持续集成到持续交付

通过 7 个持续交付最佳实践,给读者一个思路,无论是建设持续交付能力,还是在进行持续交付平台的选型,都能够在业界经验的基础上走向更为正确的道路.同时,本文还引入了持续交付成熟度模型,目的是想帮助企业,把一个想象中全面而复杂的交付流程进行切分,按照环节和成熟度等级展现,将实现持续交付能力之路变得更为清晰.更可操作.有助于企业建立良好的期望和愿景,并开展切实可行的行动. 市场和业务瞬息万变,企业的 IT 部门必须面对产品上线周期不断变短的事实,也就是说,需要建立产品交付反馈圈,并让这个闭环圈的反馈速

浅谈基于Ansible持续部署自动化

本文讲的是 :  浅谈基于Ansible持续部署自动化  , [IT168技术]随着各种计算机虚拟技术的不断发展,云计算的工业化水平也日渐成熟.在新的形势下,IT运维面临着来自各个方面的挑战,维护的机器数量从数十个几百个到成千上万个,应用的结构变得越来越复杂,更新的速度也越来越快.各种自动化配置管理工具也在这种生态环境中应运而生,如puppet,saltstack,ansible.本文将用ansible来具体讨论其在不同场景下的使用方法,从而使运维和开发人员更加轻松的应对各种配置管理及应用部署需