置过程中最容易被忽视的步骤，

[tmonower958]

在 Aircall，我们最近从 Bitbucket 迁移到了 Gitlab。与此同时，我们还决定放弃 Circle CI，转而运行由我们的 SRE 团队管理的自托管 Gitlab CI 运行器。此举导致 Gitlab CI 的 6 条管道和 19 个作业被迁移。

在这篇文章中，我将分享一些我认为在使用 Gitlab CI 自动化 CI 时应该牢记的建议。我不会重点介绍如何运行 Gitlab CI，因为已经有很多不错的文章或教程展示了如何做到这一点。让我们开始吧！

? 规划 CI 的工作内容
有时这是 CI 设但对我来说却是最重要的一步。精心规划的设置将为您节省时间和挫折感。此外，请记住，您不需要始终坚持您的计划，在习惯 CI 和发现功能时会发生变化。

制定计划时，第一件事是尝试在一张纸上列出 比利时电报数据库 您将在 CI 中实施的管道和作业，以及它们将如何触发。它将为您提供需要完成哪些工作的清晰概述，这样您就不会朝一个方向前进，然后因为忘记考虑重要的事情而半途而废。此外，如果您从现有 CI 迁移，请不要跳过此步骤，这样您就可以改进管道！

完成初稿后，看看是否可以将一些工作重新组合在一起。在我看来，最好有一个带有可变参数的工作，而不是 3 个带有硬编码的变体的工作。

完成所有这些后，您应该对需要实施的内容有一个清晰的概述！

? 模板化你的规则
迁移过程中，开始产生大量干扰的事情之一是作业规则列表。由于我们的许多作业被重复用于不同的管道，因此规则开始累积并污染我们的文件。例如，我们有一个运行 sonarqube 的作业，并在 5 个管道中使用。

现在想象一下你所有 yaml 文件中的所有作业都如上所示。一定有办法让它看起来更好？

借助 !reference 标签，我们可以从其他作业中选择关键字配置，并将其添加到我们的作业中。我们所做的是创建定义规则的模板，然后借助!reference，我们可以在我们的作业中使用这些模板。以前的作业现在如下所示。

如果我们检查一下 里面的develop-schedule是什么样子的，它就如下所示简单。

使用此方法，可以减少规则引入的样板，并且如果您正确命名模板，您可以更轻松地查看管道的所有不同触发器。