DevOps平台实践落地之构建管理详解

转载本文需注明出处：微信公众号EAWorld，违者必究。

企业做DevOps平台，本质上是做企业的IT生产线，最终是实现整个企业级的数字化生产线。构建作为落地DevOps平台必不可少的环节之一，是持续集成、交付和部署的基础。本文我们从DevOps的CICD总体思路出发，和大家分享一下DevOps是如何做构建管理的。

目录：

一、CI/CD总体思路

二、构建定义与任务编排

三、构建策略

四、构建执行与跟踪

五、总结

一、CI/CD总体思路

在DevOps中，做到持续构建是基本的，其中复杂的地方主要是对多种环境的构建支撑。项目中有用maven编译的、有用ant编译的，如果有移动应用，有android系统的、ios系统的，还有一些前端应用的编译，比如：nodejs，这么多不同的环境我们怎么支持？另外，构建过程中还需要考虑和代码质量分析，单元测试、介质上传等能力的结合，这样的构建过程其实也是一个工作流程。 

举个最典型的例子，比如：构建时，先要进行maven编译，编译过程中包含单元测试，然后进行代码质量分析，之后将交付物上传到二方库，最后还要看到构建详情、日志、单元测试报告、代码质量分析报告等详细情况，可以查看并下载介质。只有完成了这样一个过程才能说基本做到了持续集成。 

我们的DevOps中持续集成与持续部署的总体设计思路就是在DevOps中进行设计，然后通过Jenkins执行的方式。DevOps负责进行构建定义或部署架构的设计，生成Jenkins的pipeline job的配置文件；然后Jenkins根据这个配置文件创建并执行pipeline job；DevOps再通过Jenkins的Rest API跟踪执行进度和结果。 

之所以用Jenkins，正是因为它强大的集成能力和基于groovy脚本的可扩展工作流设计。Jenkins实现了与众多插件的集成，可以通过groovy命令调用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件，让我们的集成工作非常简便。其次，Jenkins的核心Pipeline的实现方式就是使用Groovy脚本来表述复杂的流程，既可以支持点状的持续集成也可以支持线状的持续部署，能够支持复杂的构建和发布流程。关于Pipleline的介绍大家可观看我们的短视频：Jenkins集成（http://p.primeton.com/articles/599e770e4be8e65e9c008522）。 

此外，顺便分享一下我们集成Jenkis时遇到的一些难点。

首先是执行效率问题，我们的DevOps通过API启动Jenkins时，Jenkins先排队调度再执行的机制造成启动较慢，比如会等待5，6秒，有时甚至是10几秒的情况，之后才会开始执行真正的脚本，用户体验较差。这方面我们自己通过异步和队列来解决用户体验问题。

其次是信息去重问题，Jenkins的Master-Slave的集群模式，使得我们在从多节点获取执行情况时需要进行去重处理，目前我们采用轮询加锁的方式解决。

此外是信息扩展问题，从Jenkins获取的结果都是日志形式的，Jenkins没有很好的扩展机制来支持定制，比如：过滤用户名密码、获取URL地址等等，需要DevOps自己进行过滤和处理。（如：有些需要的信息只能通过脚本先写到日志中再获取；用户名和密码明文存放，需要进行过滤和处理等等）。

另外，Jenkins的官方客户端REST API文档不太健全，需要通过调试的方式自己摸索。

二、构建定义与任务编排

首先我们了解一下DevOps的构建定义。这是DevOps中持续集成的操作流程。首先，可以在项目中创建构建定义，在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤进行编排，组装成一个完整构建流程。通过触发策略和保留规则的定义，可以在代码提交时触发构建（支持gitlab、github、svn等常用代码库版本管理工具），或者在指定时间进行日构建。在最新版本的DevOps中，我们增加了组件的构建定义，一个构建定义可以对应一个或多个组件。

在构建定义时，DevOps中的每个构建任务对应jenkins的一个pipeline stage。在执行时，将所有构建任务结合构建定义的一些基础信息，创建jenkins的pipeline job进行执行。

  

目前DevOps平台将构建任务分成了三类：第一类是构建类任务，如：从Git/SVN拉代码、使用Maven、Ant、Npm、Gradle进行编译，以及调用已有的构建定义进行构建等与构建相关的；第二类是测试类任务，如：执行Sonarqube代码分析、Jmeter测试、Selenium测试等与测试和代码分析相关；第三类是工具类任务，如：Shell脚本执行、介质提交到Nexus仓库、介质上传二方库等。  

DevOps通过原子任务+任务编排的方式来支持复杂的构建场景。那么，我们为什么要做编排呢？从构建任务的分类上大家可以看到，项目中使用的编程语言五花八门，对应的编译工具也各有不同，代码分析和测试工具也是五花八门，面对不同语言、不同类型的工具在构建过程中可能出现各种情况的组合，如何能够灵活地支撑这种任务的组合呢？最灵活的方式就是能够让开发人员自己根据需要进行编排。

DevOps首先将构建任务原子化，抽取成各种类别的原子任务，然后通过编排的方式将这些原子任务进行串接，就形成了灵活的任务组合，通过这种灵活的编排就可以支持各种类型应用的持续集成。之前看到的三大类构建任务就是目前我们DevOps已经抽取的原子任务，我们还在不断扩展原子任务，以支持更多的构建使用场景。 

下面是DevOps对几类常见应用的持续集成的支撑。

对于springboot类的应用，首先是拉取代码，可以从Git库拉取，也可以从svn拉取，接着是构建，可以使用maven构建，也可以使用ant，gradle构建，然后用SonarQube进行代码分析，最后执行一些脚本并提交介质。

对于移动类的应用，目前我们支持安卓应用的构建，首先是拉取代码，可以从Git库拉取，也可以从svn拉取，接着使用gradle构建，然后进行测试，最后是提交介质。对于ios应用的编译涉及到证书管理，我们正在扩展相关的构建任务。

对于前端应用，步骤类似，可以选择npm进行编译。

总之，通过不断扩展原子构建任务，并通过编排的方式定义构建流程，我们就能够支持更多的构建使用场景。 

顺便提一句，按照我们DevOps的扩展机制扩展构建任务是不需要进行前端代码开发的，可以自动生成配置界面，是不是很酷？

三、构建策略

• 超时策略

我们在DevOps中进行构建定义时，可以配置超时时间。这个超时时间是指在Jenkins中执行这个构建流程的时候，最长允许执行多长时间，如果超过这个时间，这个构建流程就会被Jenkins强行终止。

为什么要定这个超时策略，定好的构建流程为什么要强制终止呢？

这里面主要有两个原因：

• 一是在微服务架构下，构建任务非常频繁，我们认为每一次构建都应该高效完成，不能超过一定的时间，如果超过这个时间，排除外部因素，可能就是这个微服务的设计或者实现有问题，或者测试用例写的有问题，不停调用外部资源，导致执行得很慢。

  
  

• 二是碰到一些外部因素，比如网络不太稳定的情况，导致某一个构建环节时间过长，比如从github拉代码或者将构建产物上传到Nexus仓库，网路传输很慢，这样会因为这个编译任务被挂起，而导致所有后续的编译任务都在排队，整个jenkins Job无法正常执行，同时还占用了系统资源。配置超时后，可以及时释放占用的资源，提升整体构建效率。目前我们DevOps中默认的是10分钟，如果超过这个时间构建就会自动终止，并自动提一个Bug。开发或管理人员可以跟踪日志定位构建超时的具体原因，优化内部实现或调整外部环境。 

• 保留策略

保留策略可以定义我们需要保留几次构建记录，成功的保留几次，失败的保留几次。设置了保留策略之后，DevOps会保留最近几次的构建记录，而将之前的构建记录，主要包括Jenkins上的日志和临时空间清理掉。设置这个保留策略，主要是为了节省存储空间，因为每次构建都会生成一些构建日志和临时空间里的文件，通过保留策略可以优化Jenkins的磁盘空间使用效率。我们可以在构建历史中看到保留下来的那些构建记录。

• 触发策略

触发策略是指这个构建流程在什么时间会被执行。DevOps支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。

第一种代码提交时触发构建，支持通过gitlab或github管理的代码库。DevOps平台提供了触发构建的RestAPI，只需要在github或gitlab的webhook中配置payloadUrl，调用DevOps提供的RestAPI即可。可以根据需要扩展RestAPI实现，配置在其它时机触发，比如打Tag的时候，添加注释的时候等等。第二种是定时构建，就是每天到指定的时间就开始执行构建任务。DevOps提供了定时器，可以按照给定的时间定时触发执行日构建，这也是最常用的一种方式。第三种是手动构建，可以根据需要随时手动执行构建。总之，触发策略的目的就是让我们能够在需要的时间进行构建。 

• 通知策略

当需要将构建结果通知项目组成员时可以配置通知策略，在发布流水线中也可以配置通知策略。DevOps目前支持发送邮件通知，还可以根据需要扩展短信通知、微信通知等多种通知形式。只需要选择通知发送的项目组成员即可，设定完毕后DevOps平台将会发送构建成功或失败的邮件给选定的成员，以便相关人员及时了解构建结果。 

四、构建执行与跟踪

首先介绍一下构建执行。构建执行与触发策略配置相关，可以在代码提交时触发执行，也可以定时触发每日构建，这两个是DevOps自动执行，还可以根据需要手动执行。

无论是自动触发执行构建还是手动执行构建，DevOps的构建执行流程都是一样的。首先是DevOps根据构建定义生成Jenkins pipeline job配置文件，并调用Jenkins API传递配置参数启动Jenkins pipeline job，然后，Jenkins根据配置参数创建Jenkins pipeline job，执行pipeline job，通过Groovy脚本驱动相关的插件执行任务，最后，DevOps调用Jenkins Rest API查询执行进度和结果，这就是构建执行的大致流程。在执行过程中，开发人员还可以实时跟踪构建的执行进度，DevOps能够显示每一步的执行状态，是成功了还是失败了，以及每一步执行的时长。 

构建执行结束后，我们可以在DevOps中跟踪构建执行的情况、查看构建日志、查看质量报告，下载构建介质，跟踪构建历史。 

首先，我们可以跟踪构建执行的总体情况，构建是成功了还是失败了，构建执行了多长时间，产生了几个构建产物。点击每一个任务的链接我们还可以查看这个任务的执行日志，了解任务执行的详情。

如果任务执行失败了，我们可以通过日志定位失败的原因。 

此外，在控制台信息里DevOps提供了整个构建过程的日志浏览，包括相关的上下文信息，我们也可以通过控制台信息来定位构建过程中的问题。 

其次，我们可以查看代码质量情况。

有单元测试的，可以看到单元测试通过了多少，失败了多少，耗时多少。并且可以查看测试明细，了解是哪一个单元测试失败了，耗时比较长。对于Java项目DevOps在Maven构建时集成了Junit进行单元测试，我们在构建定义时如果选择了执行Junit测试，在单元测试报告中就可以看到Junit的测试报告；对于前端项目可以根据需要在前端代码编译时选择单元测试插件，在DevOps中使用npm构建时配置单元测试报告存放路径，这样就可以在DevOps中查看前端项目的单元测试结果了。

如果在构建定义时添加了SonarQube代码质量检测任务，我们还可以看到SonarQube的代码质量分析结果。有多少缺陷，多少漏洞，多少坏味道。点击链接可以进入SonarQube查看更详细的质量报告。

对于前端项目如果在项目中配置使用了代码质量扫描插件eslint，在DevOps中使用npm构建时配置eslint报告存放路径，就可以在DevOps中查看前端项目的Eslint报告，了解代码质量情况。  

另外，DevOps还提供了构建介质下载链接，可以查看构建后的介质列表并下载介质。 

如果我们想了解近期的构建情况，可以通过构建历史查看DevOps保留的构建记录。在构建历史中，我们能够看到近期执行构建的情况，每次执行了多长时间，是成功了还是失败了或者是被超时取消了，能看到的构建记录数与保留策略的设置相关。点击具体的构建我们就可以了解这次构建的详细情况。 

五、总结

总结一下，在DevOps中进行构建，平台帮您屏蔽了不同操作系统、不同构建工具、不同应用等等复杂的环境，您可以很方便地编排自己的构建流程，定义构建策略，并对构建结果进行跟踪。构建的目的是帮助我们随时获取可运行的产品，是向自动化运维迈进的第一步。

关于作者：李卜，普元DevOps布道师，曾任普元多个产品的项目经理，并作为资深咨询顾问参与工行、德邦物流、上海规土等多个项目开发和过程管控。拥有超过15年的开发团队管理和软件架构设计经验，致力于高效研发过程的落地和不断改进推广。

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享，长按二维码关注