.net - Jenkins + SVN + .NET 项目 + 代码审查。最好的方法是这样做吗？

Question

将 .NET 项目与 Jenkins 和 SVN 集成的最佳方式是什么(我不知道现在是否有机会切换到 git)并能够在构建之后和生产之前审查代码。

我想要这样的东西:

1. 开发人员 checkout 存储库。
2. 开发人员实现了一些东西。
3. 开发人员将更改提交到存储库 A (SVN)
4. Jenkins 监控存储库 A (SVN)
5. Jenkins 开始构建。
6. Jenkins 开始单元测试。
7. 一切正常。
8. Jenkins 将更改提交到存储库 B。(审查存储库)
9. QA 人员审查代码。
10. QA 人员将更改提交到存储库 C(生产)

6a。并非一切都好。6b. Jenkins 向开发人员发送通知，告知他的提交破坏了构建，我们返回到第 2 步。

我知道如何执行步骤 1-6。或多或少。我知道我可以使用 MSBuild 构建所有内容，所以这应该不难，但我不知道如何配置步骤 6-9，

GIT:

我认为使用 git 会容易得多。我看到在构建后操作中有 Git Publisher，我可以将更改推送到分支 - “review-branch” 或类似的东西，并向审阅者发送通知。他们将 pull 存储库，一切都会很棒。嗯，也许 Jenkins 应该向该分支创建 pull 请求，而不是推送到审查分支。但正如我所说，这将是 git 的场景。我把它写在这里，因为对我来说 git 是更好的选择，但也许不可能。我只想知道如果我们谈论 git，我是否没有遗漏一些东西。

SVN:

这里我不知道该怎么做。 Jenkins 是否有内置的东西来处理“推送”到第二个 SVN 存储库？如何将代码提交到存储库 B？

评论:什么是最好的方法？- (GIT) Jenkins 创建 pull 请求——如果可能的话-(GIT)Jenkins 推送到第二个审查分支并通过电子邮件发送通知或在某些问题跟踪器(Redmine/Jira)上创建一些票证- (SVN) Jenkins promise 审查存储库并发送电子邮件或创建票证。- 或者最好将所有内容与 ReviewBoard/Gerrit 或类似的东西集成。现在我从来没有使用过这样的软件，我读到 Gerrit 有点麻烦。

Answer 1

有件事你需要记住:

In a version control system, everything is reversible

这意味着您可以对提交的代码进行代码审查，并在新的提交中修复任何问题。事实上，这对 Subversion 来说非常有用，因为 Subversion 为您提供了一个包含所有代码更改的漂亮修订号。每个人都以这种方式在同一页面上。 (“我们正在审查修订版 23,340”)。大多数代码审查都在寻找诸如忘记检查空指针等问题。如果代码真的很糟糕，Subversion 可以很容易地完全撤销更改。

如果构建有问题，Jenkins 会立即告诉您，我们的政策是开发人员有 10 分钟的时间来解决问题，或者撤销他们的更改。 (90% 的时间，他们会取消更改)。我们有自己的系统设置，因此开发人员和 Jenkins 使用相同的构建机制。这允许开发人员在提交更改之前测试构建并运行单元测试。

这就是为什么大多数版本控制系统没有搁置，并且您看不到三套存储库和大多数地方。这不是你的公寓。你妈妈不会来看你的代码历史。它不一定要整洁。让它反射(reflect)正在发生的事情。

简化。删除最后三个步骤。进行代码审查并修复同一存储库中的代码。这意味着必须维护的存储库减少 66%。硬件减少 66%。而且，

---

您真正需要的只是一种跟踪代码审查的方法。你可以使用类似 Crucible 的东西，但您也可以使用 Jenkins。有两种使用 Jenkins 跟踪更改的方法:

• 为各个构建添加描述:操作简单，不需要额外的插件。描述很灵活。您可以进入一个项目，查看所有构建的列表并查看描述。简单易行。
• Promoted Build Plugins:有两种:一种是标准的，一种是简单的。

Promoted Builds Simple Plugin是……嗯……简单。您在 Jenkins 配置页面中指定所有不同的提升级别，这就是所有构建将使用的内容。每个单独的构建只允许一个提升级别，并且都是手动完成的。

标准Promoted Build Plugin需要更多的工作，但它也更强大。它允许每个 Jenkins 作业都有自己的构建提升方案。促销可以是手动的也可以是自动的。当构建得到提升时，它可以产生其他操作，例如发送电子邮件、部署到服务器等。另外，您可以显示多个提升。想象一下以下促销级别:

• 构建已通过单元测试:构建完成并通过单元测试后自动升级。可以向负责代码审查的 QA 人员发送电子邮件:
• 代码审查已完成。没有重大问题:构建总体上是好的。可能存在一些小问题，但此构建可用于部署到其他环境以进行进一步测试。
• 代码审查已完成:发现主要问题:此构建存在重大问题，不应被视为已准备好部署到另一个环境以进行进一步测试。
• 开发人员修复了在此版本中发现的问题:构建仍然很糟糕，但至少您知道开发人员声称可以处理此版本中的问题。