Jenkins CI 工作流程在源代码控制中具有单独的构建和自动化测试

Question

我正在尝试使用 Jenkins 和我们的源代码控制系统（目前是 svn，但很快 git）来改进我们的持续集成过程。

也许我在想这个过于复杂，或者我还没有看到正确的提示。

我设想的流程包含三个步骤和相关角色：

1. 一个或多个开发人员会完成他们的工作，并最终将实际软件（“主软件”）的代码更改以及单元测试提交到源代码控制（git 或其他）。 Jenkins 将构建软件、运行单元测试以及可能的其他一些步骤（例如静态代码分析）。如果这些都没有失败，那么开发人员的工作就完成了。作为构建的一部分，构建号作为版本号的一部分被纳入主软件本身。
2. 一名或多名测试工程师随后将负责构建并执行测试。其中一些可能是手动的，其中大多数需要自动化/脚本测试。 这些最终也应提交到源代码管理中并通过构建服务器执行。但是，这不会触发主软件的新构建（因为没有任何变化）。如果这些都没有失败，测试工程师就完成了。请注意，我们的自动化测试目前需要几个小时才能完成。
3. 作为最后一步，项目经理 授权发布软件，该软件执行所需的任何交付/部署步骤。此外，主要软件、单元测试和自动化测试脚本、jenkins 构建脚本以及理想情况下所有构建工件（“二进制文件”）的源代码都在源代码控制系统中存档（标记）。

理想情况下，开发人员还可以手动触发自动测试的执行，以“预览”他们的构建结果。

我一直无法弄清楚如何使用 Jenkins 和 Git - 或任何其他源代码控制系统来做到这一点。

Jenkin 的管道似乎假设所有步骤都自动按顺序执行。它似乎还假设从一开始就将代码提交到源代码管理中（如果提交“仅仅是”自动化测试脚本，我认为这是不正确的）。触发不必要的主软件构建确实会损害我们的流程，因为它基本上会使手动测试和文档无效，因为它会导致软件中包含新的构建号。

如果我的方法如此不常见，请指导我如何正确执行此操作。否则，我将不胜感激如何完成这项工作（从概念上）。

Answer 1

我会尽量回复一些观点。这确实是概念上的方法，因为有很多细节和不同的方法，这只是一个。

1. 你需要 git :)

2. 您需要设置一个 git 分支策略，允许多个开发人员同时工作，推送代码并再次验证静态代码分析。我建议你从Git Flow 开始，它被广泛使用并且可以适应你所拥有的任何现实——你不需要在纯粹的状态下使用它，所以考虑一下如何适应它。从根本上说，它将允许测试每个功能。然后，每个开发人员都可以将其合并到开发分支中 - 从此时起，您的功能已得到验证，您可以开始部署和测试。

3. 查看multibranch 管道。这将允许您测试您可能拥有的几个功能分支，并为其他分支（开发、发布和主控）提供不同的流程，具体取决于您的部署需求。因此，当您在开发分支上进行合并时，您可以触发测试或仅使用它来运行静态代码分析。

4. 为了克服您在第二点中提到的问题，有一些方法可以读取管道上的更改集，如果仅在测试脚本上进行更改，则不应构建 SW - 检查here 如何读取更改，here 是如何读取更改以及防止管道根据推送到 git 的更改构建所有阶段的示例。

5. 如果您仍在进行手动测试，则管道可以暂停，这意味着您可以暂停管道以请求批准以继续。在批准之前，测试人员应该做他们必须做的任何事情，只要他们准备好继续，只需批准构建以继续下一步。

6. 关于部署授权，它的完成方式与我在最后一点提到的相同，但在这种情况下，您可以指定允许哪些用户/角色批准该步骤。

7. 无论您需要在构建中保留什么，Jenkins 都有一个 archive artifacts 实用程序。请注意，理想情况下，您会查看适当的人工制品存储库，例如 Nexus。

8. 要手动触发一组测试...除了 CI/CD 管道之外，您还可以在 Jenkins 上手动触发作业，该作业只会执行自动化测试。您甚至可以触发与一个管道阶段相同的作业 - how to trigger another jobs

最后让我说分支策略是起点。 考虑您的大局，您需要拥有哪些 SDLC 流程，并在您的多分支管道上设置这些流程。不同的 git 分支将促进您在同一个 Jenkinsfile 中所需的任何流程 - 您的管道定义。这实际上取决于您必须部署到多少个环境以及您需要什么样的步骤。