我正在尝试使用Jenkins和我们的源代码管理系统(目前是svn，但很快会使用git)来改进我们的持续集成过程。
也许我在考虑这个过于复杂的问题，也许我还没有看到正确的暗示。
我设想的过程有三个步骤和相关的角色：
- 一个或多个开发人员将完成他们的工作，并最终将实际软件("主软件")的代码更改以及单元测试提交到源代码管理(git或其他)中。Jenkins应该构建软件，运行单元测试，也许还有其他一些步骤(例如静态代码分析)。如果这些都没有失败，那么开发人员的工作就完成了。作为内部版本的一部分，内部版本号作为版本号的一部分被烘焙到主软件本身中
- 一个或多个测试工程师随后将获取构建并执行测试。其中一些可能是手动的，大多数都希望是自动化/脚本化的测试这些最终也应提交到源代码管理中，并通过构建服务器执行。但是，这不会触发主软件的新构建(因为没有任何更改)。如果这些都没有失败，测试工程师就完了。请注意，我们的自动化测试目前需要几个小时才能完成
- 作为最后一步，项目经理授权发布软件，执行所需的任何交付/部署步骤。此外，主软件、单元测试和自动化测试脚本的源代码、jenkins构建脚本——以及理想情况下的所有构建工件("二进制文件")——都在源代码管理系统中存档(标记)
理想情况下，开发人员还可以手动触发自动测试的执行，以"预览"其构建的结果。
我一直无法弄清楚如何使用Jenkins和Git或任何其他源代码管理系统来做到这一点。
詹金的管道似乎假设所有步骤都是自动按顺序执行的。它似乎还假设将代码提交到源代码管理从一开始就开始(如果提交"仅仅"是自动化测试脚本，我认为这不是真的)。触发主软件的不必要构建确实会伤害我们的流程，因为它基本上会使手动测试和文档无效，因为它会在软件中生成新的构建号。
如果我的方法如此罕见，请指导我如何正确地做到这一点。否则，我会很感激如何(从概念上)完成这项工作。
我将尝试用一些要点来回答。这确实是一种概念性的方法，因为有很多细节和不同的方法，这只是一种。
-
您需要git:)
-
您需要设置一个git分支策略，允许多个开发人员同时工作，推送代码并在静态代码分析中验证它。我建议你从Git Flow开始，它被广泛使用，可以适应你所拥有的任何现实-你不需要在它的纯状态下使用它，所以考虑一下如何适应它。从根本上说，它将允许对每个功能进行测试。然后，每个开发人员都可以将其合并到开发分支上——从那时起，您就可以验证您的功能，并开始部署和测试。
-
看看多分支管道。这将允许您测试您可能拥有的几个功能分支，并根据您的部署需求为其他分支(开发、发布和主分支)提供不同的流程。所以，当您在开发分支上进行合并时，您可以触发测试，或者只使用它来运行静态代码分析。
-
为了克服您在第二点中提到的问题，有一些方法可以读取管道上的更改集，如果更改仅在测试脚本上进行，则不应构建您的SW-请在此处查看如何读取更改，并在此处查看一个如何读取更改的示例，同时防止管道根据推送到git的更改构建所有阶段。
-
如果您仍在进行手动测试，则管道是不可用的，这意味着您可以暂停管道以请求批准。在批准之前，测试人员应该做他们必须做的任何事情，无论何时他们准备好继续，只要批准构建就可以继续进行下一步。
-
关于部署授权，它的执行方式与我在最后一点提到的相同，即批准，但在这种情况下，您可以指定允许哪些用户/角色批准该步骤。
-
无论您需要从构建中保留什么，Jenkins都有一个归档工件实用程序。让我注意一下，理想情况下，你会寻找一个合适的人工制品库，比如Nexus。
-
要手动触发一组测试。。。除了CI/CD管道之外，您还可以在Jenkins上手动触发作业，该作业只执行自动测试。您甚至可以在一个管道阶段触发相同的作业-如何触发另一个作业
最后让我说分支策略是起点。从大局考虑，您需要哪些SDLC流，并在多分支管道上设置这些流。不同的git分支将促进在同一个Jenkinsfile(您的管道定义)中所需的任何流。这实际上取决于您需要部署到多少个环境以及需要采取什么样的步骤。