持续交付流程成熟度.docx

持续交付流程成熟度 企业持续交付成熟度模型说明 不同的行业和企业，对于持续交付的理解和应用场景是不尽相同的。只能寻求到他们的共同点和主要特征。为了便于描述，我们选择了 4 个通用环节，来记录和分类企业的持续交付过程，它们分别是构建、部署、测试、报告。在每一个环节中，又根据该环节所常见的一些实践，以及企业对这些实践的应用程度，形成了 5 个成熟度等级。这 5 个等级分别是基础级、起步级、中间级、高级、领先级。同时，在每个环节中，还根据实际经验，标示出了行业普遍能力以及应该达到的目标能力。有了这样的成熟度模型，企业就可以方便的衡量出自己现在处于什么位置，离行业普遍能力有什么偏差，目标能力应该是什么，从而快速找到采取什么行动去弥补差距，实现目标。如图 3。 图 3 .持续交付成熟度模型图 企业持续交付成熟度模型详述 构建环节 大部分新项目开始时，都是由开发人员在自己的机器上执行构建，而且没有一个标准的流程。一个开发人员在自己的 IDE 上进行构建而其他人可能用写好的脚本来做这件事。最糟糕的企业会容忍这样的方式做构建、测试甚至就将这样的构建发布到生产环境，如果这样，企业就连基础级也没有达到。 图 3 .持续交付成熟度模型分解图--构建环节 从空白水平到基础级：首先，需要做的是在专用环境下（如专用构建服务器）进行构建，而不要使用开发人员的机器去执行。不使用开发人员的机器去构建，可以很好的避免由于个人机器环境、个人工作空间等问题导致的构建结果不确定问题。其次，需要标准化目前的构建脚本（或流程），让其更为统一和固定。比如，如何从源代码控制系统中取到构建源，在实际中有多种实现，可以取构建分支上最新的版本，也可以取打过标签或基线的版本，也可以从某一个目录中找到。这些方法必须统一，并且形成标准规范。 从基础级到起步级（行业普遍能力级别）：有了专用的构建服务器和规范的构建脚本之后，需要考虑的是自动化。首先，构建服务器必须随时待命，等待开发人员进行自助式构建，开发人员需要指定的仅仅是代码存放的位置，而其他诸如机器（构建代理）、源代码获取规则、构建规范等都应该由构建服务器统一分配和安排。其次，这种自动化构建需要支持每日定时执行，允许一些团队或个人按照自己的需要一天一次或多次自动执行。最后，所有构建前后涉及的工件都应该被存储。包括构建源代码、构建标签、构建各种配置文件及属性、构建脚本（步骤）、构建结果、构建日志等。 从起步级到中间级（目标级别）：在这个级别，自动化已成为基础，需要让构建变得更有价值。首先，实现持续构建，并且每个开发人员和团队都可以使用该实践。也就是说，只要他们一提交代码，就可以自动触发构建过程；甚至当互相依赖的代码模块发生变化时，也能自动触发构建过程。其次，需要更为清晰的管理软件模块之间的依赖关系。不像之前使用约定俗成的方式，现在需要利用专门的工具去真正存储这种依赖关系并能在构建时跟踪和快速定位。这样，不仅能管理软件模块之间的依赖，还可以管理构建和构建之间的依赖关系，并把这些关系都存储在一起。最后，所有存储的构建（在网络存储设备上或者就在构建服务器中）都应该有机制保证定期被有效的清理或被正确版本化，便于将来快速利用。 从中间级到高级：更为规范的企业和团队希望采用更加可控的构建流程，能够把质量因素放进去。首先，此时的构建是可以跟踪的。团队可以针对任何一次构建（无论成功或者失败），跟踪到本次构建用到的源代码变更、计划的变更甚至需求的变更，同时，也能够方便的查看本次构建相关的所有依赖关系。其次，更加严格的管理。构建流程的修改、对构建服务器的访问、构建服务器的配置变更都需要审核和批准行为。另外，针对大型分布式的构建也需要提供支持，使用分布构建服务器去并发执行大量构建。高级阶段由于过于严格，所以建议应用在有遵规需求的企业或者针对于生产系统进行的构建部署上，其他企业/团队或更早期的阶段能做到中间级就已经足够。 从高级到领先级：有一些更为严苛的企业，他们要求能够在需要时针对早期的发布（构建成功后交付的结果）执行完美的重新构建。这就需要使用各种技术来确保重构时具有和当时一模一样的环境来保证成功。可以采用管理版本化的脚本，该脚本包括从准备操作系统到执行构建这样一个完整过程，也可以使用基于快照的虚拟机并对快照进行版本化管理来实现。目前大部分企业没有达到这种级别，因为要实现这样完美的效果需要承担很多额外的负担，如资产管理、人员投入、技术支持等，这对大部分企业来说投资回报率很低。 部署环节 部署就是将软件安装到一个环境中，对其进行配置或测试以保证能够被最终用户正确使用。如一个 Web 应用的部署，就是将其安装在 Web Server 上并更新数据库或者 Web Server 上的静态属性文件；而对于一个游戏应用而言，测试环境的部署是将其正确安装在测试机器上并执行