《持续集成实践指南》第1章 DevOps实践简介

Posted 2021-12-28 BruceOxl

1.1 Devops概念

DevOps（英文Development和Operations的组合）是开发和运维一体一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作，从而实现持续、快速、可靠地交付高质量的软件产品。

1.2 Devops实践

DevOps实践有三大核心部分：持续集成、持续交付和持续部署。下面一一说明。

1.2.1持续集成

持续集成，(ContinuousIntegration ，简称CI)，是软件开发周期的一种实践，把代码仓库（如Gitlab）、构建工具（如Jenkins）和测试工具（如SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。通常每个开发成员的每次提交都会通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。简单来说持续集成就是一个监控版本控制系统中代码变化的工具，当发生变化是可以自动编译和测试以及执行后续自定义动作。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。

尽然CI的核心是持续构建，但在CI中还有一个重要的工具--版本控制，目前大多数开发选择的工具都是Git，Git的使用流程如下：

关于Git的使用笔者在后文会详细讲解。

1.2.2持续交付

持续交付(Continuous Delivery，简称CD)，是在持续集成的环境基础上进行了扩展，在CI环节完成了软件构建和测试工作并形成了新的版本，那么接下来就要进行交付，而这里的交付并不是交付到生产环境，而是类生产环境，其目的是让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状态。

上图来源：https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

1.2.3持续部署

持续部署(Continuous Deployment，简称CD)，它是在持续交付的基础上打通最后一公里的工作，就是把手动部署到生产环境的方式升级为自动部署。

持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别在于持续部署是采用自动化的方式，而持续交付是使用手动的方式，可以参考下图。

上图来源：https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

持续集成、持续交付和持续部署其目的是减少代码改动到投入生产的所需时间，提早发现风险、减少QA的测试时长、减少运维的人工干预。整体上是一个提效的过程。当然它也不是万能的。

1.3 Devops工具体系

既然DevOps是一套工具体系，那么DevOps就会涉及到很多开发工具，下图是DevOps的工具链。

虽然DevOps工具链很庞大，但笔者主要以持续集成为核心讲解相关工具的使用，在后文笔者将会具体讲基于Git+Jenkins+Gitlab+Gerrit持续集成环境的开发与使用。

除了在本地搭建持续集成环境外，还可使用云DevOps，比如华为DevOps、阿里DevOps等。

1.4 Devops实例

1.当产品经理接收到需求之后将其录入项目软件(如Redmine)中，指定好开发人员。

2.开发人员接收到任务之后，在本地进行开发，开发完成后，将写好的代码弄成一个评审单上传到代码托管服务器(如Gerrit)中，并通知相关的评审人员进行评审。

3.在开发人员提交上去的那个刻则会触发持续集成工具(如Jenkins)提前创建的任务，任务触发后，持续集成工具先拉取代码库最新提交的代码，然后进行编译构建，扫描代码是否符合规范。代码符合之后，然后进行测试（在构建的时候会先进行单元测试），然后把构建好的包，在测试环境上进行部署，然后拉取自动测试脚本进行测试，测试没有问题之后。持续集成工具会对本次的评审单进行打分。通过了就打2分，不过打-2分。这样就避免了浪费大家的时间，在打分通过了的情况下，评审人员才会去评审。

4. 评审人员到代码托管服务器上进行评审通知后，会去评审，如果评审不合格，直接拒绝，开发人员重新进行开发提交。在提交然后再重复上一步骤。如果评审通过，进行代码合入，然后再次触发构建任务，构建到测试版本之后，然后发布到制品库中，然后通知测试人员可以进行测试了。

5.测试人员收到测试任务之后，从制品库中拉取测试包进行部署测试，然后再用自动化脚本进行测试，对于个别场景可以进行手工测试，如果有bug，测试人员则会通知开发人员，这个时候流程又从第一步开始，直到这个bug测试通过了。

6.如果测试人员测试通过了，然后又可以出发一次构建任务。将最新的代码构建成release版本发到制品库中或者是进行自动部署。而且现在有灰度发布，可以一点一点切流程到新的版本上，看一下运行情况，如果不行直接回退。