主干开发 主干发布
对我们的主线源存储库(也称为主干)进行更改从来都不是一件容易的事，但是问题随着试图合并他们的工作的人数而增加。 在过去的两年中，我们取得了长足的发展，有关新功能，改进，错误修复，重构以及自动测试的工作始终如火如荼。 在任何给定时间，我们都会针对中继线打开数百个“拉取请求”。 (Getting changes to our mainline source repository (aka trunk) has never been easy, but the problems scale with the amount of people trying to merge their work. We have grown quite dramatically over the last couple of years, and the work on new features, improvements, bug fixes, refactorings and, of course, automated tests is always in full swing. At any given time, we have hundreds of open Pull Requests against trunk.)
As you might already know from our previous blog post on our QA process, we tend to work in separate branches, where all changes are subjected to an early in-branch testing. So what happens next? How do those changes actually get merged to trunk or other release branches?
您可能已经从我们先前 关于质量检查流程的博客文章中 知道 ，我们倾向于在单独的分支机构工作，所有更改都将在分支机构中进行早期测试。 那么接下来会发生什么呢？ 这些更改实际上如何合并到中继或其他发行分支中？
The first thing to do is open a new Pull Request (PR) in Ono (our source code management system, based on Kallithea), add a detailed description that contains the purpose, testing status, technical risk and any other relevant comments. Every PR needs to be reviewed by a peer who has domain-specific knowledge for each area it touches. They give feedback on the changes. Ono has a system that automatically suggests who should be invited to review certain parts of the code.
首先要做的是在Ono(我们的基于Kallithea的源代码管理系统)中打开一个新的Pull Request(PR)，添加一个包含目的，测试状态，技术风险和任何其他相关注释的详细描述。 每个PR需要由对每个接触领域都具有特定领域知识的同行进行审查。 他们提供有关更改的反馈。 Ono的系统会自动建议应邀请谁查看代码的某些部分。
The code reviews are a critical part of our development process. The reviewers focus mainly on following questions:
代码审查是我们开发过程的关键部分。 审阅者主要关注以下问题：
-
Does the code achieve the intended purpose?
代码是否达到预期目的？
-
Does the code have good test coverage?
代码是否具有良好的测试覆盖率？
-
Does the code needs manual testing and has it been performed?
代码是否需要手动测试并且已经执行？
-
Is the code well-written and does it follow the Boy Scout Rule (“Always leave the campground cleaner than you found it.”)?
该代码编写是否正确，是否遵循《童子军规则》(“始终离开营地，要比发现的要干净。”)？
-
Does the code follow the coding standard?
编码是否遵循编码标准？
The number of people involved in reviewing the PR may vary, depending on the amount of changes and areas being touched. It can get to as many as 10-15 people for bigger features. Based on this feedback, we edit the code until everybody agrees on the right approach. So we often add only team peers at first to gather the initial feedback and fix all found issues before involving a wider range of people. Also, we like to split PRs into smaller chunks with isolated changes, since those require fewer people to review them and the reviewers can look at the code more thoroughly.
参与PR审查的人员数量可能会有所不同，具体取决于更改的数量和涉及的领域。 更大的功能可以容纳多达10-15个人。 基于此反馈，我们将编辑代码，直到每个人都同意正确的方法为止。 因此，我们通常最初只添加团队同事，以收集初始反馈并解决所有发现的问题，然后再让更多人参与。 另外，我们希望将PR分成几个较小的块，并进行单独的更改，因为这些PR所需的人员较少，因此审阅者可以更彻底地查看代码。
When the final PR is ready and went through the last round of reviews, we run another round of tests. Usually, we run the set of build targets and automated tests suites that are most commonly/easily broken. We have special targets set up on our build automation server Katana to make this a one-click process for developers.
当最终的PR准备就绪并经过最后一轮审核时，我们将进行另一轮测试。 通常，我们运行最常见/最容易破坏的一组构建目标和自动化测试套件。 我们在构建自动化服务器 Katana 上设置了特殊的目标 ，使开发人员可以一键式完成该过程。
For the final PRs, we also have to obtain an approval from one of the Release Managers.They assess the release risk and make sure all the right parties have discussed and seen the changes.
对于最终的PR，我们还必须获得一名发布经理的批准，他们评估发布风险并确保所有合适的参与者都已讨论并看到了更改。
Once all the green dots have been collected and the tests have returned green, we can take the PR to the next step and add it to the Trunk Merge Queue. Voila! The PR is now waiting to be merged.
收集完所有绿色点并且测试恢复为绿色后，我们可以将PR转到下一步，并将其添加到Trunk Merge Queue。 瞧！ PR现在正在等待合并。
It might seem that this is it, but it’s not the time to relax yet. Before being actually merged to trunk, the changes need to pass Trunk Queue Verification! We introduced this process to improve the stability of trunk. So what does that mean exactly?
似乎就是这样，但现在还不是放松的时候。 在实际合并到中继之前，所做的更改需要通过中继队列验证！ 我们引入了此过程以提高主干的稳定性。 那到底是什么意思呢？
Each batch of PRs is automatically merged on top of trunk in a test branch. Then it’s pushed to a draft repository. Then more builds are launched and we are run all tests. An automated system polls our build system, analyses build results and sends status messages to an internal Slack channel.
每批PR都会自动合并到测试分支的主干顶部。 然后将其推送到草稿存储库。 然后，将启动更多构建，并运行所有测试。 自动化系统会轮询我们的构建系统，分析构建结果并将状态消息发送到内部的Slack通道。
If a build or test fails, it will first be launched again, both on the same machine and on another one to see if it is a stable failure or an instability. A failure will also initiate a bisection: a build will be launched half the way to the last known working revision. Repeatedly starting builds in the middle of the untested range, the system finds the PR that introduced the failure and pings the owner in a Slack channel.
如果构建或测试失败，它将首先在同一台机器上和另一台机器上再次启动，以查看它是稳定的失败还是不稳定。 失败也将引发两部分：构建将在上一次已知的工作修订的一半之前启动。 系统反复在未测试范围的中间开始构建，系统找到引入故障的PR并在Slack通道中对所有者进行ping操作。
The offending PR is taken out of the batch. Then, the good part of the batch is automatically merged on top of the trunk and pushed. Owners are notified about this happy event by a ping in a Slack channel and the PR is closed.
有问题的PR从批次中删除。 然后，批次的大部分自动合并到行李箱顶部并推入。 通过Slack频道中的ping通知所有者有关此快乐事件的信息，并且PR被关闭。
Why do we go through this whole process? We aim to improve the quality and stability of Unity! Following these steps helps prevent bugs and test failures from reaching trunk.
我们为什么要经历整个过程？ 我们旨在提高Unity的质量和稳定性！ 遵循这些步骤有助于防止错误和测试失败进入主干。
您如何在团队中测试代码？ 让我们在评论中知道！ (How do you test code in your team? Let us know in the comments!)
If you’re passionate about code quality and would love to contribute to making, testing or maintaining Unity, join us!
如果您对代码质量充满热情，并且愿意为制作，测试或维护Unity做出贡献，请 加入我们 ！
翻译自: https://blogs.unity3d.com/2016/10/17/a-look-inside-the-path-to-trunk/
主干开发 主干发布