【.com快译】本文主要介绍了三个主题：自动化持续集成/持续部署（CI/CD）配置、使用Git代码存储库进行常见的CI/CD工件以及参数化的詹金斯管道。术语介绍让我们先定义几个术语。CI/CD是一种允许团队快速自动测试、打包和部署应用程序的实践。它通常是通过使用名为Jenkins的服务器来实现的，该服务器充当CI/CD编排器。Jenkins侦听特定输入（通常是代码签入后的Git挂钩）并被触发以启动管道。管道由开发和/或运营团队编写的代码组成，这些代码指示Jenkins在CI/CD过程中做什么。此管道通常类似于“构建我的代码，然后测试代码，如果这些测试通过，则将我的应用程序部署到下一个最佳环境（通常是开发、测试或生产）”。企业通常有更复杂的管道，结合工件存储库和代码分析器等工具，但这只是一个粗略的例子。现在我们已经了解了关键术语，让我们深入研究一些最佳实践。1.自动化是关键要在PaaS上运行CI/CD，需要在集群上配置合适的基础设施。在此示例中，我将使用OpenShift。实现“Hello,World”很容易。只需运行ocnew-appjenkins-，您就有了一个正在运行的Jenkins服务器，可以随时上路了。但是，在企业中使用要复杂得多。除了Jenkins服务器之外，管理员通常还需要部署代码分析工具（例如SonarQube）和工件存储库（例如Nexus）。然后，他们想要创建管道来执行CI/CD，并创建Jenkins从节点来卸载主节点。这些实体中的大多数都由需要创建的OpenShift资源支持，以便部署所需的CI/CD基础设施。最终，可能需要复制部署CI/CD组件所需的手动步骤，而您可能不是执行这些步骤的人。为确保快速、无差错且与以前完全一样地产生结果，自动化应该包含在基础设施的创建方式中。这可以是Ansible剧本、Bash脚本或您希望自动部署CI/CD基础设施的任何其他方式。我使用Ansible和OpenShift-Applier角色来自动化我的实施。您可能会发现这些工具很有价值，或者您可能会觉得其他工具更适合您和您的企业。无论如何，您会发现自动化大大减少了重新创建CI/CD组件所需的工作量。配置Jenkins主节点除了一般的“自动化”之外，我想挑出Jenkins主节点，谈谈管理员可以使用OpenShift自动配置Jenkins的几种方式。来自RedHatContainerCatalog的Jenkins镜像安装了OpenShift-Sync插件(https://github.com/openshift/jenkins-sync-plugin)。要创建Jenkins管道，请像这样创建OpenShiftBuildConfig：apiVersion:v1kind:BuildConfig...spec:source:git:ref:masteruri:...strategy:jenkinsPipelineStrategy:jenkinsfilePath:Jenkinsfiletype:JenkinsPipelineOpenShift-Sync该插件会注意到已创建具有策略jenkinsPipelineStrategy的BuildConfig并将其转换为Jenkins管道，从Git源中指定的Jenkinsfile中获取。也可以使用内联Jenkinsfile而不是从Git存储库中获取文件。有关详细信息，请参阅文档。要创建Jenkins从节点，请创建以下列定义开头的OpenShiftImageStream：apiVersion:v1kind:ImageStreammetadata:annotations:slave-label:jenkins-slavelabels:role:jenkins-slave...请注意此ImageStream中定义的元数据。OpenShift-Sync插件会将任何标记为role:jenkins-slave的ImageStream转换为Jenkinsslave。Jenkins从节点将使用slave-label注释中的值命名。ImageStreams非常适合简单的Jenkins从属节点配置，但一些团队发现有必要配置基本细节，如资源限制、就绪和活跃度探测以及实例上限。这是ConfigMaps可以派上用场的地方：apiVersion:v1kind:ConfigMapmetadata:labels:role:jenkins-slave...data:template1:|-请注意，转换ConfigMap仍然需要role:jenkins-slave标签进入Jenkins从节点。Kubernetespod模块包含一长段XML，可根据您的业务喜好配置每个细节。请参阅查看此XML的文档以及有关将ImageStreams和ConfigMaps转换为Jenkins从节点的更多信息。从上面的三个例子可以看出，没有一个操作需要管理员手动更改Jenkins控制台。通过使用OpenShift资源，可以轻松地自动化配置Jenkins。2.共享即关怀第二个最佳实践是维护一个通用CI/CD工件的Git存储库。主要思想是防止团队重新发明轮子。想象一下，您的团队需要在OpenShift环境中执行蓝/绿部署，作为管道CD阶段的一部分。负责编写管道的团队成员可能不是OpenShift专家，他们也没有能力从头开始编写此类功能。幸运的是，有人已经编写了一个将此功能合并到通用CI/CD存储库中的功能，因此您的团队可以使用它而不是花时间编写一个。更进一步，您的组织可能决定维护整个管道。您可能会发现团队正在编写功能相似的管道。对于这些团队来说，使用来自公共存储库的参数化管道比从头开始编写每个管道会更有效。3.少即是多如上所述，第三种最佳实践是参数化CI/CD管道。参数化可防止流水线泛滥，并使您的CI/CD系统更易于维护。假设我有多个区域来部署应用程序。如果没有参数化，每个区域将需要不同的管道。如果要为OpenShift构建配置参数化地编写管道，请将env部分添加到配置中：...spec:...strategy:jenkinsPipelineStrategy:env:-name:REGIONvalue:US-WestjenkinsfilePath:Jenkinsfiletype:JenkinsPipeline具有此配置，我可以将参数REGION传递给管道，以将应用程序部署到指定区域。一些企业可能决定将CI/CD管道拆分为单独的CI和CD管道，这通常是由于部署前的一些审批流程。假设我有四个图像和三个不同的环境要部署。如果没有参数化，我将需要12个CD管道来支持所有部署方案。这很快就会失控。为了使CD管道的维护更容易，企业会发现将图像和环境参数化是更明智的做法，以便一个管道执行多个管道的工作。结论企业级的CI/CD通常比许多企业预期的要复杂。幸运的是，有了Jenkins，有很多方法可以无缝地提供自动化。维护一个包含常见CI/CD工件的Git存储库也可以简化工作，因为团队可以从维护的依赖项中提取，而不是自己从头开始编写它们。***，参数化CI/CD管道将减少需要维护的管道数量。原标题：持续集成和部署的3个最佳实践，作者：AustinDewey
