使用 Git和Jenkins 构建持续集成和交付平台

属于你的文章第一时间送达！

前言：

集成是指软件开发者的将个人部分向软件整体部分交付，以便尽早发现个人开发部分的问题；

部署是代码尽快向可运行的开发/测试环境交付，以便尽早测试和回归解决。

交付是指研发尽快向客户/用户交付，以便尽早发现生产环境中存在的问题。

如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。

持续，就是说每完成一个完整的部分，向下流环节交付，发现问题可以马上调整。出现问题和事故，不会放大到其他部分和影响后面的环节。

业内为了解决这些环节出现的痛点，会使用敏捷开发，加上自动化工程化来解决，本文主要介绍下业内常用的持续交付平台所用的技术。

Jenkins是一个自动化服务器，可用于以受控和可预测的方式构建，测试和部署代码。它可以说是当今最流行的持续集成工具。分阶段自动构建代码的过程 - 在每个阶段，测试并将其推广到下一阶段 - 被称为流水线。

Jenkins是开源的，拥有一个支持良好的插件库。Jenkins不仅是跨平台（Win / Mac / Linux），还可以通过Docker安装，或者实际安装在任何带有Java Runtime Environment的机器上！

请注意，还有其他持续集成工具可用，包括本文中介绍的工具以及我个人最喜欢的Travis。但是，因为Jenkins非常常见，所以我想介绍一个经常变得不必要的过度模式 - 使用Git存储库设置临时管道（dev => QA => prod）。

还要注意的是，Jenkins拥有自己的“管道”概念（以前称为“工作流程”），用于跨多个构建从站的长时间运行的复杂构建任务。本文使用向后兼容的自由式作业来尽可能简化事情。这个想法是使用Git的强大功能和简单性，而不是从Jenkins引入复杂性 - 并将其耦合到Jenkins。

检查你的Git工作流程

在团队中工作时，最大限度地实现了使用Git进行源代码管理管理的强大功能。尽管如此，我还是推荐使用Git作为您唯一贡献者的项目，因为它可以使未来的潜在协作变得更加容易 - 更不用说每个克隆的存储库实例都要保留一个完整且组织良好的项目历史。

为了举例的目的，我们将在这里进行探讨，考虑一个在单个Git存储库中工作的3-8个常规代码贡献者的典型团队。如果一个项目的开发人员超过8人，则可能需要考虑将应用程序分解为更小的，责任驱动的存储库。

当前使用的常见Git工作流程是“GitFlow”时，由主分支，开发分支和一些变动的功能分支，发布和修补程序分支组成。当我单独在一个 个人项目上开发时，我经常直接转到主分支。但是，在大量的总结中，GitFlow用于帮助代码在适当的时间“Flow”到适当的地方。你可以看到Git分支如何与持续集成和发布管理相关联。

分段代码管道的目标是什么？

几乎每个我工作过的团队都使用了一个分段管道的变体，但是，从来没有人真的问过这个问题。

那么，无论如何，目标是什么？在大多数情况下，暂存管道旨在部署自动构建，易于识别和可信任的代码版本，使非开发人员能够深入了解团队创建的内容。张这里，我并不是在讨论官方版本，只是来自特定Git提交的代码的可运行的代码实例。

这些非开发人员可能包括技术团队成员，如业务分析员（BA），项目经理（PM）或质量分析师（QA）商务经理（BD），或者他们可能包括非技术角色，例如潜在客户，高管或其他利益相关者。每个角色对于想要这种可见性都有不同的理由，但假设这些人不是开发人员，并且不在自己的机器上构建代码是安全的。毕竟，开发人员无论何时何地都可以在本地运行不同版本的代码的项目。

有一点，虽然Jenkins可以为开发人员设置使用手动触发器来运行参数化版本，但这样做并不能实现既定的目标。、

将Git分支映射到分段环境

现在我们已经了解了分段管道的总体目标，确定每个环境的目的。虽然每个团队的需求会有所不同，但我鼓励你接受KISS原则，并根据需要在你的管道中创建尽可能多的环境。这是一个典型的（通常是足够的）例子：

开发

开发环境的目的是提供对开发分支上当前内容的洞察，或者在代码的下一个“发布”中意图分支的任何分支。

QA（又名分期）

QA环境的目的是为QA测试和其他类型的批准提供更稳定和完整的代码版本。

Prod

产品环境的目的是提供当前在主分支上的生产就绪代码（或用于此目的的任何分支）。这代表了即使实际的生产环境托管在其他地方，也可以向用户提供的内容。此分支中的代码仅为QA环境中已获批准的代码，无需其他更改。

虽然开发人员可以随时从任何分支拉代码并运行，但这些环境代表该代码库/存储库的可信实例。这是一个重要的区别，因为它消除了诸如安装的依赖关系（即NPM node_modules或Maven JAR）或环境变量等环境因素。我们都听说过“它适用于我的机器”的轶事。例如，当开发人员在处理自己的代码时遇到潜在的错误时，他们会在发出警报之前使用开发环境作为完整性检查：

虽然dev和prod环境与Git分支明显相关，但您可能会对QA环境感到疑惑，这一点并不清楚。虽然我个人更喜欢持续部署，只要他们准备好就发布功能，但由于商业原因，这并不总是可行的。

质量保证环境可以批量测试和批准功能（从开发中），从而以与代码审查（请求）相同的方式保护主分支，以保护开发分支。可能还需要使用QA环境来测试修补程序 - 尽管我们当然希望这是例外情况，而不是规则。无论哪种方式，有人（可能是质量分析师）会阻止一半的代码进入主分支，这是一个非常重要的角色！

由于QA环境与分支无关，如何指定应该部署哪些代码以及应该从哪里来？

根据我的经验，许多团队忽略了GitFlow 的标签部分，这可以成为解决此问题的有用工具。质量保证环境代表候选版本，无论你是否正式调用它。换句话说，你可以通过标记代码（即1.3.2-rc.1）或通过引用提交哈希或任何分支的HEAD（它只是提交哈希的快捷方式）来指定代码。无论如何，部署到QA环境的代码都对应于一个独特的提交。

在质量保证环境中测试和批准代码的人员，只要他们认为有必要，就可以自行执行这些构建，这一点很重要。如果这是测试，并且他们使用提交散列部署到QA环境，那么他们需要一个手动的，参数化的Jenkins作业和对存储库的只读访问。另一方面，如果他们不能/不应该访问代码，开发人员应该创建标签并提供标签（或提交散列或分支名称）。就个人而言，我更喜欢前者，因为我希望尽量减少开发人员所需的手动任务数量。此外，如果所有开发者都在开会或去吃饭了呢？

在通过后，该代码的确切版本应该使用版本号（即1.3.2）进行标记并合并到主分支中。提交可以有很多标签，我们希望一切顺利，以便我们认为实际上是候选版本的代码版本已经发布。意思是说，一个承诺被标记为1.3.2-rc.1和1.3.2是完全合理的。如果可能，标记应该是自动的。

如何使分级环境更加值得信赖

你可以通过以下方式使环境更加安全：

按照代码审查流程，其中至少有一名其他团队成员必须批准拉取请求

在所有的pull请求上配置构建和单元测试实施，所以不可能合并会“失败”的代码（无论对于你的团队/应用程序而言意味着什么）

在您的Git存储库中建立分支机构保护，以便用户不会意外（或故意）将代码直接推送到团队存储库中与环境相关的分支，从而绕过审查过程

设置一个部署钩子，以便在将代码提交（或合并到）相应分支时自动触发Jenkins构建作业。这对开发分支可能有意义！

对于谁有权配置Jenkins作业要小心谨慎; 我只推荐两位开发者。由于公交因素，一个人太少，如果没有适当的沟通或达成共识，超过两人不必要地增加了工作变更的可能性。

在应用程序某处显示代码的版本，例如页脚或“关于”菜单。（或者，如果你不想让用户看到它，就把它放在复活节彩蛋中）。具体来说，获取版本的方式将取决于应用程序的语言和运行它的平台。

从提交哈希创建QA构建作业

已经充分地说了保护你的代码的所有方法后。让我们开始为单个Git存储库配置Jenkins作业。

这项工作将适用于dev => QA => prod管道的中间部分，帮助我们将代码部署到QA（也称为分段）环境。它将允许质量分析师在给定提交散列和标记名称的情况下构建和标记代码。

这个构建：

查看具体的提交（或参考）。

照常构建代码。

在Git中标记提交。

将标签推到原点回购。

（可选，但可能）将其部署到服务器。

注意。如果构建失败，我们当然不想标记和部署它。步骤2和步骤5对Jenkins的任何工作都是相当标准的，所以我们不会在这里介绍这些。

一次性安装

由于Jenkins需要将标签推送到原始库，它需要基本的Git配置。现在我们来做。转到Jenkins>管理Jenkins>配置系统> Git插件。输入用户名和电子邮件。这并不重要，只要保持一致即可！

创建一个新的工作

使用你选择的名称创建一个新的自由式项目（例如，“QA-staging”）

在常规下，选中“此项目已参数化”。添加两个参数，如下所示。为了方便，COMMIT_HASH的“默认值”被设置为“refs / heads / master”，因为我们只是想确保作业有一个有效的提交来处理。将来，您可能希望将其设置为“refs / heads / develop”，或完全清除该字段。在源代码管理下，选择'Git'。添加存储库的URL和凭据。（Jenkins将尝试对此URL进行身份验证作为测试，因此如果身份验证失败，它应该会立即为您提供错误。）通过在Branch Specifier字段中键入$ ，使用作业开始时提供的提交哈希。 。在Post-build Actions下，添加一个类型为“Git Publisher”的动作。选择“添加标签” 并设置如下所示的选项。我们检查两个框，因为我们希望Jenkins在标记过程中执行任何操作（根据需要创建或更新标记）。$ 是作业开始时的第二个参数。

运行作业时，系统会提示您输入提交哈希和标记名称。在这里，你可以看到我已经启动了两个构建：第一个构建检出并标记了master上的最新提交。

第二个构建签出了一个较旧的提交，构建它，并用“test”标记它。同样，你可能会构建和标记更高版本的代码，而不是更早的版本，但是这证明了这个工作正在按照它的要求进行！

第一个版本，主分支的HEAD成功了。然后将其标记为“0.0.1”并推送至原始回购。第二个版本，即较旧的提交，也被标记了！

结论

Git和Jenkins都非常强大，在移动端可以配合gradle出包，但对平台拥有巨大的管理权限是非常重要的。因为，在构建管道中证明不必要的复杂化是很常见的。虽然Jenkins有很多巧妙的技巧，但我更喜欢利用Git的功能，因为随着时间的推移，发布管理和错误跟踪变得更加容易。

我们可以通过注意构建的代码版本并适当地标记它们来做到这一点。这样可以将与版本相关的信息保留在代码中，而不是依赖Jenkins构建号码或其他标记。保护Git分支可以降低人为错误的风险，并尽可能多地自动执行任务，从而降低我们不得不等待编译等待的耗时频率。

最后，在一个团队工作时，流程规范是必须做的，但如果繁琐且不灵活，或者也可能成为一种拖累。

我的方法是：如果你想让人们做正确的事情，那么做起来容易。聆听团队意见，随时自查痛点，并继续使用Git和Jenkins改进流程，让编程更轻松。

最后邀你参加下网络协议的学习！