本章阐述持续集成系统的发展历程、持续集成系统的原理，以及持续集成系统的实现过程，目的是让大家全面了解持续集成系统，更加深入的学习持续集成系统的原理，为后续章节的学习做好准备。我会分享一些个人的经验。
1.1 传统的应用发布模式
![新Jenkins实践-第1章 开篇-为什么要做CI/CD？]()
如果你没有亲身体验过传统的应用发布，你可能不会觉得CI/CD有什么吸引人的地方。一般一个开发团队中都会存在多个角色：开发、测试、运维。 当时我们的应用发布模式可以能是这样的：
- 开发同学进行项目代码开发，本地运行测试成功后将代码上传到版本控制系统。
- 开发同学通知运维同学项目可以发布了，然后运维同学下载代码进行打包和构建，生成应用制品。
- 运维同学使用部署脚本将生成的制品部署到测试环境，并提示测试同学可以进行产品的测试。
- 测试同学开始进行手动、自动化测试，测试完成后提醒运维同学可以进行预生产环境部署。
- 运维同学开始进行预生产环境部署，然后测试同学进行测试，测试完成后，开始部署生产环境。
当然我描述的可能只是其中的一部分，手动操作很多、出现的问题很多。上面看似很流畅的过程，其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致：开发人员本地测试成功后提交代码，运维同学下载代码进行编译却出现了错误。
1.2 2020了，什么是CI/CD？
![新Jenkins实践-第1章 开篇-为什么要做CI/CD？]()
持续集成CI：是需要对开发人员每次的代码提交进行构建测试验证。确定每次提交的代码都是可以正常编译测试通过的。在没有持续集成服务器的时候，我们可以写一个程序来监听版本控制系统的状态，当出现了push动作则触发相应的脚本运行编译构建等步骤。 现在有了专业的持续集成服务器后，我们借助持续集成服务器来实现版本控制系统中代码提交触发构建测试等验证步骤。
持续交付CD：是基于持续集成的基础上，将集成后的代码自动化的发布到各个环境中测试（DEV TEST UAT STAG），确定可以发布生产版本。 这里我们可以借用制品库实现制品的管理，根据环境类型创建对应的制品库。一次构建，到处运行。
- 开发环境发布：我们可以将开发环境产出的制品部署进行测试，没有问题后上传到测试环境的制品库中。
- 测试环境发布：此时通知测试人员可以进行测试环境发布测试，获取测试环境制品库中的制品，发布到测试环境验证。 验证通过将制品上传到预生产环境制品库。
- 预生产环境发布：获取预生产环境制品，进行部署测试。 测试成功后可以将制品上传到生产库中。
- 手动部署生产环境。
持续部署CD：是基于持续交付的基础上，将在各个环境经过测试的应用自动化部署到生产环境。其实各个环境的发布过程都是一样的。应用发布到生产环境后，我们需要对应用进行健康检查、添加应用的监控项、 应用日志管理。
1.3 Jenkins持续集成
![新Jenkins实践-第1章 开篇-为什么要做CI/CD？]()
对于持续集成工具现在也有很多，目前应用最多的是Jenkins。Jenkins前身是Hudson，使用java语言开发的自动化发布工具。Jenkins是跨平台的可以在Win、Linux、MacOS部署。Jenkins是应用最广的开源免费的持续集成服务器，企业中普遍使用Jenkins来作为项目集成发布工具。 Jenkins官方提供的插件使Jenkins更为强大。Jenkins是一个自动化服务器，目前发展超过15年，比较成熟的CI工具（也可以CD）能够实现自动化集成发布。建立好流水线后，期间无需专业运维人员介入，开发人员随时发布部署。
什么是Agent ?
Jenkins采用分布式架构，分为server节点和agent节点。 server节点也是可以运行构建任务的，但我们一般使其主要来做任务的调度。（毕竟server节点挂了就都...）agent节点专门用于任务的执行。 随着现在容器的盛行，我们可以将server节点和agent节点在容器或者基于Kubernetes中部署。 关于agent节点借助容器可以实现动态的资源分配等等好处。agent节点可以分为静态节点和动态节点。 静态节点是固定的一台vm虚机或者容器。 动态节点是随着任务的构建来自动创建agent节点。
什么是Pipeline？
Jenkins的核心是Pipeline（流水线项目），实现了Pipeline As Code。即我们将构建部署测试等步骤全部以代码的形式写到Jenkinsfile中。Jenkins在运行Pipeline任务的时候会按照Jenkinsfile中定义的代码顺序执行。写Jenkinsfile是一项很重的工作，如果稍不注意很容易造成Jenkins的流水线任务失败。 Jenkinsfile类似于Dockerfile，具有一套特定的语法。（后续我们会详细讲解jenkinsfile编写）
什么是Stage？
在Jenkins pipeline中，一条流水线是由多个阶段组成的，每个阶段一个stage。例如：构建、测试、部署等等。
1.4 谈谈我的Jenkins实践经验
我是在18年左右接触的Jenkins，算下来已经2年了。我们的DevOps工具链只有Gitlab 和Jenkins，属于建设阶段。 流水线是手动复制创建的。还好有写好的Jenkinsfile模板，通常改改每个项目的git地址，就可以了。
我的实践过程
优化流水线
开始改造Jenkins了， 将之前写的Jenkinsfile全部阅读一遍，想办法整合一下。 最后将各种类型的Jenkinsfile合并成了一个Jenkinsfile。一个Jenkinsfile的确方便了许多，但是这个文件怎么这么长？ 1000+行 看起来都累。学到了Jenkins共享库的概念。开始学习groovy语法将通用的语句封装函数。由于我具有python语言基础所以学习groovy就比较容易了。 我当时看的是<groovy编程>这本书。 使用共享库的方式将一个复杂的Jenkinsfile优化成了一个简洁的Jenkinsfile。
脚本式语法到声明式语法
当时我设置了一个小功能，根据参数决定运行的阶段。 于是我在共享库中将每个stage封装了一下。然后，通过case语句根据pipeline的值，来决定运行哪些stage方法。 看似很不错的功能用了一段时间也很有效。 看到了一篇官方文章推荐的是流水线使用声明式语法，声明式语法中具有when语句可以轻松的实现这些功能。........于是开始将脚本式语法替换为声明式语法，之前写的这些都没用了.....
DevOps项目改造
自从2019年04月，主要从事于工具链更新维护和DevOps标准评估项目改进事务。项目AAA自6月份开始，流水线更新了4个大版本。 起初的1.0版本配置完成后并不符合当前项目团队的开发模式；2.0版本根据项目团队的要求出发配置完成后经过专家评估一些细节不符合认证要求；按照认证要求3.0版本流水线配置完成后发现了很多细节上的问题（过程太长，人工操作较多等）；最后4.0版本以jira出发实现端到端的自动化，减少人工操作，打造既符合实际业务也符合认证标准的流水线。
在不断的学习DevOps理论和文化的过程中，将持续交付流水线改造的更加灵活。持续集成平台优化:
a) 完成Jenkins共享库开发，实现多流水线支持，构建更加灵活。
b) 完成Jenkins容器构建资源池，加快构建和编译速度。
c) 完成Jenkins CICD分离集成，与DevOps平台适配。
d) 完成流水线结合制品库完成制品的上传和下载，减少发布时间。
e) 完成基于Jira的端到端流水线实践。
f) 完成基于容器的自动化测试流水线实践。
g) 探索SQL审核工具，完成基础SQL扫描，提高SQL质量。
h) 研究SonarQube平台接口，集成Jenkins使代码扫描更加灵活。
i) 研究Gitlab平台接口，集成Jenkins实现代码自动化。
![新Jenkins实践-第1章 开篇-为什么要做CI/CD？]()
1.5 Jenkins的学习建议
我们在学习一门技术的时候总是想知道学完了可以做什么？我们来谈谈Jenkins可以做什么呢？ 其实我想告诉你，踏踏实实去学习，只要熟练的掌握Jenkinsfile的编写，Jenkins什么事情都是可以做。限制Jenkins功能的不是Jenkins本身。 你可以将Jenkins想象成一个可以配置的web前端页面，而后面的Jenkinsfile就是我们要写的后端代码。
对于今年2月份上线的《Jenkins实践教程》还算满意，目前已经积攒了约1000+学员。积攒了100多个学习Jenkins经常遇到的问题。谈谈我们学习Jenkins之前要具备哪些基础知识呢？
基础要求：
- 熟练Linux系统运维（常用的命令等等）
- 熟悉Shell脚本编程（Jenkins pipeline会调用很多shell语句）
扩展知识： 可以让你的流水线更加强大与灵活。
- 掌握一门编程语言例如Python（Jenkins会用到groovy语法）
- 掌握docker、kubernetes基础知识
是不是看上去很多呢？ 其实这些都是我们前往技术型DevOps工程师所必备的知识点了。 如果你是开发人员你需要补充运维相关的知识，如果你是运维人员需要补开发知识。Jenkins是开发、运维同学到DevOps的转折点。
今天，我们分享了关于Jenkins刚刚开始学习时的一些学习建议与方法，后面我们将开始进一步深入了解Jenkins的功能与特性。
