持续集成与持续部署实践_持续集成和部署的3个最佳实践

持续集成与持续部署实践

本文涵盖了三个关键主题：自动化CI / CD配置，将Git存储库用于常见的CI / CD工件以及对Jenkins管道进行参数设置。

术语

首先是第一件事；让我们定义一些术语。 CI / CD是一种实践，允许团队快速而自动地测试，打包和部署其应用程序。这通常可以通过利用名为Jenkins的服务器来实现，该服务器用作CI / CD编排器。 Jenkins侦听特定的输入（通常是在代码签入后的Git钩子），并在被触发时启动管道。

管道由开发和/或运营团队编写的代码组成，该代码指示Jenkins在CI / CD流程中采取哪些措施。该管道通常类似于“构建我的代码，然后测试我的代码，如果这些测试通过，则将我的应用程序部署到下一个更高的环境（通常是开发，测试或生产环境）”。组织通常具有更复杂的管道，并结合了诸如工件库和代码分析器之类的工具，但这提供了一个高级示例。

现在我们了解了关键术语，让我们深入了解一些最佳实践。

1.自动化是关键

要在PaaS上运行CI / CD，您需要在群集上配置正确的基础架构。在此示例中，我将使用OpenShift 。

实现这一点的“ Hello，World”实现非常简单。只需运行oc new-app jenkins- <persistent / ephemeral>和voilà ，您就可以运行一个正在运行的Jenkins服务器。但是，企业中的使用要复杂得多。除Jenkins服务器外，管理员通常还需要部署代码分析工具（如SonarQube）和工件库（如Nexus）。然后，他们将不得不创建流水线来执行CI / CD和Jenkins从站，以减少主站上的负载。这些实体中的大多数都由OpenShift资源支持，这些资源需要创建以部署所需的CI / CD基础结构。

最终，可能需要复制部署CI / CD组件所需的手动步骤，并且您可能不是执行这些步骤的人。为了确保快速，无错误且完全像以前那样产生结果，应在创建基础结构的方式中采用自动化方法。这可以是Ansible剧本，Bash脚本或您希望自动执行CI / CD基础结构部署的任何其他方式。我使用Ansible和OpenShift-Applier角色来自动化我的实现。您可能会发现这些工具很有价值，或者可能找到其他对您和您的组织更有效的工具。无论哪种方式，您都会发现自动化大大减少了重新创建CI / CD组件所需的工作量。

配置詹金斯大师

除了一般的“自动化”之外，我想选出Jenkins管理员，并讨论管理员可以利用OpenShift自动化Jenkins配置的几种方法。 Red Hat容器目录中的Jenkins映像与安装的OpenShift-Sync插件打包在一起。在视频中，我们讨论了如何使用此插件来创建Jenkins管道和奴隶。

要创建Jenkins管道，请创建类似于以下内容的OpenShift BuildConfig：

apiVersion: v1

        kind: BuildConfig

        ...

        spec:  

        source:      

        git:  

        ref: master      

        uri: <repository-uri>  

        ...  

        strategy:    

        jenkinsPipelineStrategy:    

        jenkinsfilePath: Jenkinsfile      

        type: JenkinsPipeline

OpenShift-Sync插件会注意到已经创建了带有策略jenkinsPipelineStrategy的BuildConfig，并将其从Git源指定的Jenkins文件中提取出来，转换为Jenkins管道。也可以使用内联Jenkinsfile，而不是从Git存储库中提取。有关更多信息，请参见文档。

要创建Jenkins从属，请创建以以下定义开头的OpenShift ImageStream：

apiVersion: v1

        kind: ImageStream

        metadata:

        annotations:

        slave-label: jenkins-slave

        labels:

        role: jenkins-slave

        …

注意此ImageStream中定义的元数据。 OpenShift-Sync插件会将带有标签角色：jenkins-slave的任何ImageStream转换为Jenkins从属。 Jenkins奴隶将以奴隶标签注释中的值命名。

ImageStreams对于简单的Jenkins从属配置来说工作得很好，但是一些团队会发现有必要配置实质性细节，例如资源限制，就绪性和活动性探针以及实例上限。这是ConfigMap发挥作用的地方：

apiVersion: v1

        kind: ConfigMap

        metadata:

        labels:

        role: jenkins-slave

        ...

        data:

        template1: |-

        <Kubernetes pod template>

注意，仍然需要角色：jenkins-slave标签才能将ConfigMap转换为Jenkins从属。 Kubernetes pod模板由冗长的XML组成，它将根据您的组织喜好配置每个细节。要查看此XML，以及有关将ImageStream和ConfigMap转换为Jenkins从属的更多信息，请参见文档。

请注意上面显示的三个示例，这些操作都不需要管理员对Jenkins控制台进行手动更改。通过使用OpenShift资源，可以以易于自动化的方式配置Jenkins。

`2.分享是关怀`

第二个最佳实践是维护一个通用CI / CD工件的Git存储库。主要思想是防止团队重新发明轮子。想象一下，作为管道CD阶段的一部分，您的团队需要在OpenShift环境中执行蓝/绿部署。负责编写管道的团队成员可能不是OpenShift专家，也没有带宽从头开始编写此功能。幸运的是，已经有人在公共CI / CD存储库中编写了将该功能合并到一起的功能，因此您的团队可以使用该功能，而不必花费时间来编写该功能。

为了更进一步，您的组织可以决定维护整个管道。您可能会发现团队正在编写具有类似功能的管道。对于那些团队来说，使用公共存储库中的参数化管道要比从头开始编写自己的管道更为有效。

`3.少即是多`

正如我在上一节中所暗示的那样，第三个也是最后一个最佳实践是参数化CI / CD管道。参数化将防止管道过多，从而使您的CI / CD系统更易于维护。想象一下，我有多个可以部署应用程序的区域。如果不进行参数化，则每个区域都需要一个单独的管道。

要对写为OpenShift构建配置的管道进行参数化，请将env节添加到配置中：

...

        spec:

        ...

        strategy:

        jenkinsPipelineStrategy:

        env:

        - name: REGION

        value: US-West          

        jenkinsfilePath: Jenkinsfile      

        type: JenkinsPipeline

使用此配置，我可以将REGION参数传递给管道，以将我的应用程序部署到指定区域。

该视频提供了更实质的情况，其中必须进行参数化。通常，某些组织决定将其CI / CD管道拆分为单独的CI和CD管道，因为在部署之前会发生某种批准过程。想象一下，我要部署四个映像和三个不同的环境。如果不进行参数设置，我将需要12条CD管道以允许所有部署可能性。这可以很快解决。为了简化CD管道的维护，组织会发现更好地参数化映像和环境，以允许一个管道执行许多工作。

`摘要`

企业级别的CI / CD往往比许多组织预期的要复杂。幸运的是，有了Jenkins，有很多方法可以无缝地自动进行设置。维护通用CI / CD工件的Git存储库也将减轻工作量，因为团队可以摆脱维护的依赖关系，而不必从头开始编写自己的依赖关系。最后，对CI / CD管道进行参数化将减少必须维护的管道数量。

如果您发现了其他无法避免的做法，请在评论中分享。

翻译自: https://opensource.com/article/18/11/best-practices-cicd

持续集成与持续部署实践