前职务：https://blogs.sap.com/2019/08/07/02-naive-sherpa-project-conciletime/

下一岗位：https://blogs.sap.com/2019/09/09/04-naive-sherpa-gathering-data/

在我的上一篇文章中，我描述了简明时间网站我跳过了项目顶层的一些文件，因为它们与项目本身的构建有关。我们将很快对此进行讨论，但首先让我们谈谈为什么我们希望自动完成一些事情。

当开始一个新项目时，有一种巨大的诱惑，即潜入并开始编码。你在每过一个小时都在花钱，你想展示一些进展。通常在一开始，只有一两个开发人员坐在一个房间里，或者只是一个聊天室。写一些代码，编译/部署它，看到结果的快速转身是令人陶醉的，我理解其中的诱惑。问题是，当事情变得越来越复杂，当你的团队越来越壮大，国内大数据公司排名，你开始将任务分配给其他开发人员时，构建和测试的过程开始出现问题。现在突然有人在某个地方做了一个更改，整个过程就中断了。更糟糕的是，你做了一个更改，它会影响到应用程序的其他部分，而不是你当前正在处理的部分，你不会注意到它（因为你只是在测试你正在处理的内容）。这就是持续集成/持续部署（CI/CD）对你成功的关键所在。

即使你还在处理最初的部分作为一个单独的开发人员，我鼓励您解决设置一个功能性CI/CD系统的问题，并开始使用它。至少它可以使您避免意外删除的分号。通过将项目的构建委托给CI/CD系统，您可以在创建时将自己的精力放在手头的问题上同时建立对您的项目代码的信任。

CI/CD系统有多种类型，因此我将仅提及SAP用作其产品基础的系统。

SAP CI和CD产品概述

如果您使用的是现有CI/CD系统或需要使用SAP未涵盖的一组工具，我建议您阅读《CI最佳实践指南》。这是一份内容广泛的文档，一旦您需要开始认真的测试和生产计划，它也会让您思考需要什么。

由于我正在努力遵循SAP的最佳实践，商城建站系统，我选择使用我自己的基于Jenkins的CI/CD系统，并采用Piper库。Piper库为您的构建过程提供了一个良好的控制和一致性的平衡。使用基于SAP云的CI/CD服务是一个不断发展的选择，但目前它主要集中在两个以SAP为中心的开发用例上，所以我将不讨论它这里。

Jenkinsfile：这是构建过程开始的地方，它定义了部署项目所需的阶段。在按顺序设置准备、构建和部署阶段时，大多数配置细节都留给配置文件处理。

JenkinsfileXSA：我希望能够创建一个不同的Jenkins作业，从同一组源代码构建我的应用程序的prem版本，大数据是什么，因此，我创建了这个Jenkinsfile的备用版本。唯一的区别是，它指向不同的配置文件集。

.pipeline:是一个包含配置文件的文件夹，Piper库会为其配置选取这些配置文件。

.pipeline/extensions:是一个覆盖步骤行为的文件夹，并且不起作用然而，管道/配置yml：是配置Cloud Foundry部署的主文件。

.pipeline/配置xsa.yml：是用于配置内部部署的XSA版本文件，包含在JenkinsfileXSA文件中。

管道_配置yml：是上面提到的基于SAP云的CI/CD服务的配置的位置没有被当前的Jenkins进程使用，所以它实际上被忽略了webhook.txt文件：这个文件有一些关于使用上面提到的基于SAP云的CI/CD服务的提示。

Jenkins完成了构建我的项目的所有繁琐任务，并且没有忘记任何事情（或者失败）。我编辑我的项目和Jenkins之间的粘合剂是代码版本控制工具（您现在使用的是代码版本控制工具吗？）。我使用Gitgithub.com网站。每次我提交到git存储库中的主分支时，都会触发一个新的生成，它通过松弛消息通知我，但你使用电子邮件通知或其他机制。让我们看看詹金斯。

按照上面链接中的说明设置詹金斯与派珀图书馆合作。

我们在这里看到，我在詹金斯内设置了两个工作。第一个最近正在建立的成功（sunny）是正在部署到Cloud Foundry的一个。第二个是用于构建内部部署XSA，由于我关闭了服务器，它出现了故障（风暴），我甚至暂时禁用了该作业，以便在我返回之前它不会继续尝试构建。

在我的github帐户中，我需要配置webhook触发器。登录Github并选择设置。

下一步选择webhook。

选择添加webhook。

填写详细信息，注意URL的路径和应用程序/json的类型。

您现在应该看到一个新的webhook条目。

跳回Jenkins并创建一个新管道作业。

别忘了点击"确定"。现在这样配置它。

选择您将使用SCM和Git，并使用您的repo url和主分支。

指定项目中包含此文件的文件。并保存。