在这篇文章中，我们将继续我们的CI/CD之旅。我们已经探讨了主要概念（第1部分 - 包括什么是CI/CD）和示例应用程序背后的思想，以及涉及HANA时管道的设计原则（第2部分）。现在我们将向您展示其中一个微服务管道的管道外观。

上图显示了我们将实现的CI/CD流。当应用程序开发人员提交代码时，它将被cloudbuild中的触发器获取。然后它将构建、测试和部署我们的应用程序。让我们首先关注单个环境管道，因为将其扩展到多个环境非常简单。

演示应用程序回顾

在深入管道之前，让我们快速回顾一下应用程序的外观：

正如Lucia Subatin在第2部分中解释的，应用程序有四个主要组件：

上图显示了这些组件相互作用。更多详情，请参阅本系列第2部分。

我从哪里开始？现在你可能在想：太棒了！我们从哪里开始？如何选择第一个成为CI/CD'ed的微服务？（是的，我刚刚发明了一个词…诗意的许可证FTW！！！）

当第一次为现有应用程序启动CI/CD管道时，了解如何开始剖析beast可能是一个挑战。在服务中寻找以下特性：

相当独立，这意味着它不必在同一个应用程序中调用很多其他服务（作为其他服务的依赖关系是可以的）对单元、功能和集成测试具有良好测试覆盖率的服务（是的 - 它们都很重要）总体复杂度相对较低

再看一下上图，您认为哪种服务最适合成为第一个？猜猜看！

我们从后端服务开始，购物返利，因为它是非常孤立和经过良好测试的。在自动化部署时，始终尝试改进您的测试，以确保应用程序的可靠性 - 您未来的自我将感谢您。

构建容器

后端依赖于Google Translate API SDK for Golang；这意味着在构建之前，我们始终需要安装该SDK。我们还希望运行go test和go vet作为测试过程的一部分。

云构建中的管道步骤在容器中运行；这意味着我们可以通过使用所有需要的工具创建自定义容器来简化构建。让我们继续为后端创建一个构建容器，并将其存储在容器注册表中，以便以后在管道中使用？最终，您会希望每天运行10个甚至100个构建，因此这几秒钟会被放大；这会促使您尽可能快地进行构建。生成容器允许我们跳过生成依赖项的下载和安装步骤 - 节省时间。

下面是我们的后端生成容器Dockerfile的外观：

额外提示：您可以通过实现Kaniko缓存进一步减少生成时间。

管道配置

现在我们有了环境，让我们检查一下管道是什么样子：

对于主分支，我们将：

云构建管道是通过一个名为云构建.yaml如下（要点）：

当然，为了实现其他技术的管道，细节将发生变化；但是，总体流程将保持不变。例如，当使用NodeJS测试DAL层时，阿里大数据应用平台，命令将是npm test而不是go test；等等。

这里的一些重要注意事项是：

还记得Lucia在第2部分中解释的这个图像吗？

看看云构建.yaml仔细观察，您将看到指向后端微服务的每个步骤上都有一个dir:translate，大数据包括哪些内容，全球云购，因此，只有在该文件夹中进行更改时，才会运行该命令。有很多方法可以做到这一点，所以选择最适合您的发布和开发需要的版本。另外，请注意云构建.yaml文件位于其相关微服务的文件夹中。

创建触发器

在云构建中创建触发器非常简单，易淘客，一旦创建了YAML文件：

请注意，我们将glob模式配置为只匹配在本例中应用于微服务文件夹中的更改我们的后端是translate/**。如果我们在repo中的其他文件夹中提交，这可以防止触发触发。

还可以查看regex如何匹配名为master的分支；对于非master分支，可以选中"Invert regex"复选框；最后，云构建配置文件还特别针对我们的微服务管道定义和translate/云构建.yaml

到目前为止，你几乎可以想象你将如何为其他微服务创建管道！

要在正确的文件夹中运行管道提交到存储库，您还可以选择手动运行。构建日志可以通过进入控制台查看构建执行，如下所示：

部署HANA工件的管道基本相同，但不同……但基本相同。

如第2部分所示，这个管道依赖于一个HDI容器和一个带有正确工具的特殊构建容器，以允许我们连接并部署到实例。实际的云构建.yaml文件相当简单：

注意它有一个步骤（目前）。它主要依赖于准备好的构建环境和工具，如hanacli和通过环境的HDI连接上下文。所有这些都是通过创建一个特定的构建容器来完成的（很像我们的后端构建容器）。

这就是构建容器Dockerfile的样子（gist）：

作为一个旁注，这个Dockerfile没有优化，在使用之前您可能需要对它进行一些调整。