unity 工程版本管理

版本管理"/>

unity 工程版本管理

unity 工程版本管理

I didn’t expect to be writing up this blog post. I initially wrote up an email congratulating the company on our release and highlighting changes during the 5.4 release cycle. However, Aras thought my email worthy enough to tweet and reveal a little behind the curtain. So, that became impetus for this series.

我没想到会写这篇博客文章。 我最初写了一封电子邮件，祝贺公司发布并重点介绍了5.4发布周期中的更改。 但是，阿拉斯认为 我的电子邮件 值得发推并在幕后透露一些信息。 因此，这成为本系列的动力。

With the release of 5.4, there’s been a lot going on inside Unity at how we build things. There’s constant change going on for us, as we’ve been growing on all fronts. What used to be around 100 developers and QA folk when I started has grown to over 400. We did a lot of that growth during the 5.1 – 5.3 cycle, and keeping pace with the changes added strain.

随着 5.4发行版的发布， Unity内部进行了很多构建工作。 随着我们在各个方面的不断发展，我们正在不断发生变化。 当我刚开始时，大约有100名开发人员和质量检查人员，现在已经增长到400多名。在5.1 – 5.3周期中，我们做了很多这样的增长，并且跟上了变化带来的压力。

We recognized during the previous year that while underlying code and systems were starting to improve, our usability, stability and perception were taking a pretty big hit. While we were always incrementally trying to improve, we took a couple more steps this round that I’d like to enumerate and talk about more in depth in this series.

在上一年，我们认识到，虽然底层代码和系统开始有所改进，但我们的可用性，稳定性和感知力却受到了很大的冲击。 尽管我们一直在不断尝试改进，但是本轮我们又采取了一些步骤，在此系列中，我想列举一些更多的话题。

Nothing here is necessarily ground-breaking in ideas, but these posts are hopefully illustrative of how scale and scope start requiring these changes. Simply put, this is a peek into our constant self-reflective improvement process and are the improvements Unity is implementing now.

这里没有什么是开创性的想法，但是希望这些帖子可以说明规模和范围是如何开始要求这些更改的。 简而言之，这是对我们不断进行自我反思的改进过程的窥视，也是Unity现在正在实施的改进。

Let’s start with some of the basic things and we’ll dive into bigger topics later.

让我们从一些基本的东西开始，稍后我们将讨论更大的主题。

A modest hardware upgrade to the build farm and faster build master server (katana) than previous rounds (with more to come!)

对构建服务器场进行适度的硬件升级，并 比以前 的版本更快地构建主服务器( katana )(还有更多功能！)

An odd issue to share is that our rather complex build farm (which has gotten the TeamCity to katana upgrade, and got far bigger and more complex) is currently limited to our Copenhagen office server room facilities. We are limited by physical space, cooling and power! There are technical architectural reasonings for the inability to move any time sooner, but we’re close to hitting our milestones in a project to shift out to an external data center. More on that another time.

一个奇怪的问题是，我们相当 复杂的构建服务器场 (已经使 TeamCity升级为katana ，并且变得更大，越来越复杂)目前仅限于我们的哥本哈根办公室服务器机房设施。 我们受到物理空间，冷却和功率的限制！ 出于技术上的架构原因，无法尽快进行迁移，但是我们即将移交给外部数据中心的项目达到了里程碑。 再来一次。

With our heavy automation, numerous platform support, and distributed development, the build farm is a critical piece of infrastructure to support our development speed and quality. It is become nigh impossible for a single developer to do a full build and test locally due to the sheer number of platforms (maintaining, configuring, and simply the space). [ Aside: Every dev comes into Unity, including myself, thinking that “a build farm shouldn’t be that hard, at studio xxx or company yyy, we did it just fine.” Once they learn what’s going on here….it is that hard. ]

凭借我们的 高度 自动化 ，众多平台支持和分布式开发，构建服务器场是支持我们的开发速度和质量的关键基础架构。 由于平台数量众多(维护，配置以及简单的空间)，单个开发人员几乎不可能在本地进行完整的构建和测试。 [撇开：包括我自己在内的每个开发人员都进入了Unity，他们认为“在xxx工作室或yyy的公司建造农场应该不难，我们做得很好。” 一旦他们了解了这里发生的事情……就很难了。 ]

So, near the beginning of 5.4, we wrapped up upgrading the last of our rack servers to recent hardware, and pushed a new revision of our katana build master server yielding noticeable improvements in build times.

因此，在5.4开始时，我们结束了将最后一台机架服务器升级到最新硬件的工作，并推动了对katana构建主服务器的新修订，从而显着缩短了构建时间。

Build count aggregate graph from 1/1/2016 to 7/29/2016. Yellow line is “average wall time” per build, and blue is “average actual build time”. The difference is sub-build dependencies that a build might be waiting on.

从2016年1月1日到2016年7月29日的构建计数汇总图。 黄线是每次构建的“平均墙壁时间”，蓝线是“平均实际构建时间”。 区别在于构建可能正在等待的子构建依赖项。

There’s a noticeable crevasse in that graph, which I can point out a longer maintenance window where some heavy debugging by our engineering tool operations team rooted out a bug in the CEPH cluster that since also helped streamline and improve overall farm performance by not causing nearly as many failures.

该图中有一个明显的缝隙，我可以指出一个更长的维护时段，在此期间，我们的工程工具运营团队进行了一些繁重的调试，从而消除了 CEPH群集中的 一个 错误 ，此 错误 也由于不会造成几乎相同的损失，从而有助于简化和提高总体场的性能。许多失败。

Every CPU cycle counts, as much as for you as it does for us. We are continuously investing in making the build farm more scalable and faster to serve not just ourselves, but ultimately all of you.

每个CPU周期都与您一样重要，对我们而言也是如此。 我们一直在不断投资，以使构建服务器场更具可扩展性和更快性，从而不仅为我们自己，而且最终为所有人服务。

We minimized overlapping releases. 5.5 was iced for some time to give focus to 5.4

我们最小化了重叠发行。 将5.5冻结一段时间以将焦点放在5.4

During the 5.0 – 5.3 cycle, we had to overlap pretty hard to keep a quarterly release schedule. Putting aside the development concerns, this put a multiplier strain on the whole organization from developers, QA, and support to build infrastructure. At the release of 5.3, we were managing 5 versions (4.7, 5.0 – 5.3) and had 5.4 already in the beginnings of development, so make that 6!

在5.0 – 5.3周期中，我们不得不重叠很多，以保持季度发布时间表。 除了开发方面的顾虑外，这给开发人员，质量保证和支持基础架构的整个组织带来了倍增的压力。 在5.3发行版中，我们管理着5个版本(4.7、5.0 – 5.3)，并且在开发之初就已经拥有5.4，因此使之成为6！

This caused a lot of split focus, let alone tracking concerns of what landed where.

这导致了很多分散的关注点，更不用说跟踪对降落地点的担忧了。

During 5.4, we explicitly chose to defer 5.5 work further, only turning it back on recently and in limited scope. From the roadmap, you can see 5.5 has a number of things in it, but they’re fewer and more contained. By focusing on less quantity but more quality we intend to ramp back up the cycles, and also concern ourselves less about these overlaps.

在5.4期间，我们明确选择进一步推迟5.5的工作，只是最近才在有限的范围内将其重新启用。 从 路线图中 ，您可以看到5.5中包含许多内容，但是包含的内容越来越少。 通过关注数量较少但质量更高的产品，我们打算增加周期，并且也不再担心这些重叠。

We shifted more towards teams with inclusive QA yielding improved testing

我们将更多的精力转向具有包容性QA的团队，从而改善了测试

While this seems like a trivial topic, and often some silly management-speak about agile or otherwise, we decided to experiment further with embedded QA. The reasoning was pretty simple: more often than not, developers would go off and “implement” and only present to QA when “done.”

尽管这似乎是一个琐碎的话题，并且常常有些愚蠢的管理者谈论敏捷或其他方面，但我们还是决定对嵌入式QA进行进一步的试验。 推理非常简单：开发人员通常会退出并“实施”，并且只有在“完成”后才提交给质量检查人员。

By having QA more present and more engaged earlier in the process:

通过让质量检查人员更多地参与和更早地参与流程：

• We improved the schedule since the QA member has better overviews of what’s coming and can better overlap/interleave

  由于QA成员可以更好地了解即将发生的事情，并且可以更好地进行重叠/交错，因此我们改进了日程安排

• QA is never surprised by undiscovered work

  质量检查从未对未发现的工作感到惊讶

• Workflow issues can be caught early

  可以及早发现工作流程问题

• Bugs are caught earlier as they’re made

  错误是在制造时被较早发现的

• We can even have side-by-side usage and development, similar to sitting next to your game designer using a new tool

  我们甚至可以并行使用和开发，类似于使用新工具坐在游戏设计师旁边

• We have much higher confidence when we bring the feature branch to a release branch

  将功能分支带入发布分支时，我们有更高的信心

So far, we see the benefits outweighing any concerns thus far and more of our teams are happily embracing the shift. Again, nothing surprising about this. We’re just pointing out we’re doing more of it and that’s changed things.

到目前为止，我们看到的好处超过了迄今为止的任何担忧，并且我们的更多团队乐于接受这一转变。 同样，这也不足为奇。 我们只是指出我们正在做更多的事情，这已经改变了事情。

One of the results out of this tighter teamwork are some great testing reports reviewing features and changes during their development. Check out a couple samples:

紧密的团队合作产生的结果之一是一些出色的测试报告，这些报告回顾了其开发过程中的功能和变更。 查看几个示例：

• Image Effect Bloom (available via bitbucket) during 5.4

  5.4期间的 图像效果绽放 (可通过 bitbucket获得 )

• Particle Noise for upcoming alpha/beta

  即将发布的alpha / beta的 粒子噪声

We opened the beta to the public, getting more pre-release feedback than ever before

我们向公众开放了Beta版，获得了比以往更多的预发布反馈

Our early feedback has always been problematic. In the last year, we specifically identified the lack of beta participation. Our usage rates during 5.1 – 5.3 beta cycles didn’t even get close to 0.002% of our release usage, and it showed.

我们的早期反馈一直存在问题。 去年，我们专门确定了缺少beta参与的情况。 结果表明，在5.1 – 5.3 Beta周期内，我们的使用率甚至没有达到发行版使用率的0.002％。

So, as the story went, we opened up beta for 5.4 to the public for any license.

因此， 随着故事的发展 ，我们为任何许可证向公众开放了5.4版的Beta版。

5.2 – 5.4 of the last year of editor starts.

编辑器最后一年的5.2 – 5.4开始。

From the numbers, it’s clear that it had a staggering impact of increased usage, adoption and help us with getting more coverage for more of the pathways than ever before.

从数量上可以明显看出，它对使用，采用的增加产生了惊人的影响，并帮助我们获得了比以往任何时候都更多的途径途径。

We upped our internal QA passes and improved test coverage

我们提高了内部质量检查合格率并提高了测试覆盖率

We can’t be pushing all our expectations of test coverage onto the beta. So, our QA group stepped up as well, increasing the number of passes and experimenting with new ways of going about testing to uncover what the users might run into. We redefined and re-focused our early test approach for new features into something internally dubbed the Feature Testing Framework – another topic for a future blog post.

我们不能将我们对测试覆盖率的所有期望推到Beta上。 因此，我们的 质量检查小组也加强了工作 ，增加了通过次数，并尝试了进行测试的新方法以发现用户可能遇到的问题。 我们对新功能的早期测试方法进行了重新定义，并将其重点重新定位到内部称为“功能测试框架”的功能中，这是以后博客文章的另一个主题。

In combination with the earlier mentioned QA embedding, we’ve been catching more of our issues earlier and fixing the either before they land or more quickly with a shorter reaction time.

结合之前提到的质量检查嵌入，我们已经尽早发现了更多问题，并在它们着陆之前或更短的时间内以更快的React时间对其进行了修复。

Along with that, our test coverage has yet further expanded. Our current code coverage reports for automated tests show that our Editor and Runtime sources have ~70% function coverage now, with about 50% condition/decision coverage. We’re constantly adding further tests, which over time should reduce the introduction of future regressions.

除此之外，我们的测试范围进一步扩大。 我们当前针对自动化测试的代码覆盖率报告显示，我们的Editor和Runtime源代码现在的功能覆盖率约为70％，条件/决策覆盖率约为50％。 我们一直在不断增加进一步的测试，随着时间的流逝，应该会减少对未来回归的介绍。

We’re holding ourselves to higher standards

我们坚持更高的标准

Unity’s grown a lot, and with that our users have also grown their expectations of us. We’d like to meet those expectations, so we’re buckling down and working on being more consistent and generally higher quality. We took some inspiration from Atlassian’s values about “Don’t #@!% the customer”, as well as take that to heart internally even amongst ourselves, “Don’t !@#$ on trunk.”

Unity取得了长足发展，与此同时，我们的用户也增加了对我们的期望。 我们希望满足这些期望，因此我们正在努力，力求更一致，质量更高。 我们从 Atlassian 关于“不要＃@！％顾客” 的价值观中汲取 了一些灵感 ，并且甚至在内心 深处也深信 “不要在顾客 身上 ！@＃$”。

These may be crass phrasing, but everyone gets the idea quickly. Arguments can be settled pretty quickly by asking ourselves the question of on which side of the fence does a change fall?

这些可能是无礼的措辞，但每个人都很快就明白了。 通过问自己一个问题，变化落在栅栏的哪一边，就可以很快解决争论。

Along with the shift in thought, we are also holding ourselves to higher review processes, attempting to quantify risks and better discipline. We’re also now valuing consistency, reliability and quality. We ask ourselves the question of how maintainable the code is, or what would the next developer say when they come across a given change.

随着思想的转变，我们也将自己置于更高的审查流程中，试图量化风险并加强纪律。 我们现在也在评估一致性，可靠性和质量。 我们问自己一个问题，即代码的可维护性，或者下一个开发人员在遇到给定的更改时会怎么说。

We’re also currently digging pretty deep and re-factoring. The heavy leaning towards quality via bug fixes is also being proportionally matched with investments in fixing the underlying code base. The aim is to make it more modular and maintainable, which will make it easier to test. Of course, all this is ultimately for your benefit.

我们目前还在深入研究和重构。 通过错误修复对质量的高度重视也正与修复基础代码库的投资成比例。 目的是使其更具模块化和可维护性，从而使其更易于测试。 当然，所有这些最终都是为了您的利益。

Future topics

未来的话题

That’s enough for now, but do stay tuned to as I will continue this blog series with the following topics:

到目前为止，这已经足够了，但是请继续关注，因为我将继续本博客系列，主题如下：

– Changing our bug prioritization system to reflect “user pain”

–更改我们的错误优先级系统以反映“用户痛苦”

– Keeping our release branch and trunk more stable and test “green” than any previous release

–使我们的发行分支和主干比以前的发行版更稳定并测试“绿色”

– More performance test coverage to watch the most dangerous of user complaints of regressions

–更多的性能测试覆盖范围，可以观察用户最危险的回归投诉

– “Project Upgrade” focus to make sure users upgraded as cleanly as possible from previous version

–以“项目升级”为重点，以确保用户尽可能从先前版本进行干净升级

– A crashes tracking tool letting us get some preliminary telemetry of our release

–崩溃跟踪工具，使我们能够初步了解发布的信息

– Getting more information into the testers hands earlier

–更早地将更多信息掌握在测试人员手中

If you’re intrigued thus far, I hope you enjoy the series. Until next time (or release).

如果您至今对此感兴趣，希望您喜欢这个系列。 直到下一次(或发布)。

翻译自: /

unity 工程版本管理