地盘游戏：五个王国之间的统一

序幕 (Prologue)

In the beginning, there were many houses. Though they began life at the same time, they were in different parts of the land, and thus had different ideas about what was best. As these great houses often do, they grew apart, and tensions heightened. When the king decreed “there must be consistent banners across the houses,” they all decided what that meant on their own, and were satisfied that the banners were consistent and true. They were not.

一开始有很多房子。 尽管他们是同时开始生活的，但他们在土地的不同地方，因此对最好的事物有不同的想法。 就像这些大房子经常做的那样，它们彼此分开，紧张局势加剧。 当国王颁布法令“房屋中必须有统一的标语”时，他们都自己决定了这是什么意思，并对标语是一致和真实的感到满意。 它们不是。

Though they had all risen their castles from the same Angular stones, and had used the same engine to power their forges, they had developed differences over time.

尽管他们所有人都使用相同的Angular石头升起了城堡，并使用了相同的引擎来驱动锻件，但随着时间的推移，他们逐渐形成了差异。

And so, a handful of brave knights were tasked with the impossible: uniting the houses. This is not their story; it is the story of how the great houses became greater together.

因此，少数勇敢的骑士被赋予了不可能的任务：团结房屋。 这不是他们的故事。 这是伟大的房子如何一起变得更大的故事。

第一项任务：团结四个 (The First Quest: Unite The Four)

Gather round the campfire for a rousing tale! Allow us to regale you with a story of victory. A story in which the wicked wizard Bad User Experience and his underling The Tech Debt Collector were vanquished by uniting different sites under a common goal. Are you interested in web development? Do you use our Developer Dashboard? Do you like stories about deleting way more lines of code than writing them? Then join us on this adventure!

围着篝火围着一个令人难忘的故事！ 让我们以胜利的故事重温你。 一个故事，其中邪恶的向导Bad User Experience和他的下属Tech Debt Collector通过在一个共同目标下团结不同的站点而被击败。 您对网站开发感兴趣吗？ 您是否使用我们的开发人员仪表板？ 您是否喜欢有关删除比编写更多行的代码的故事？ 然后加入我们的冒险之旅！

So when this whole thing started, the Cloud Services team was responsible for owning and maintaining four separate nginx sites in one location and a node.js-based one in a second location. Though hosted in multiple regions, the teams managing them were separated between Seattle and Austin. They covered core things like managing your project settings, users and access levels between the two, and four services: Unity Multiplayer, Performance Reporting, Collaborate and Cloud Build. The other services — Ads and Analytics– were hosted on their own platforms in other locations, so we’ll just focus on those first five pieces.

因此，当这一切开始时，Cloud Services团队负责在一个位置拥有和维护四个单独的nginx站点，并在第二个位置拥有和维护基于node.js的站点。 尽管托管在多个区域，但管理它们的团队却分别在西雅图和奥斯丁之间。 它们涵盖了核心内容，例如管理您的项目设置，两者之间的用户和访问级别以及四种服务：Unity Multiplayer，Performance Reporting，Collaborate和Cloud Build。 其他服务(广告和Analytics(分析))托管在其他位置的平台上，因此我们仅关注前五个部分。

It was hard to keep things organized across five separate repos. As a result, the user experience was similar… but not consistent. Buttons looked slightly different and were in different spots for different products. Fonts were the same family but sizes varied greatly from place to place. There was no consistent information architecture: no agreement on what level of headers and body content were appropriate. This was bad for us, obviously, but it’s also really bad for our users.

很难通过五个单独的存储库来组织事情。 结果，用户体验是相似的……但是不一致。 按钮的外观略有不同，不同产品的位置不同。 字体是同一个家族，但是字体的大小因地而异。 没有一致的信息体系结构：在标题和正文内容的适当级别上没有达成一致。 显然，这对我们不利，但对我们的用户也确实不利。

Multiple things had been tried: a trove of shared components that each could draw from; a singular definitive styleset that all sites used by importing a large compiled stylesheet as well as one set of visual assets. But no matter how diligent the teams were, inevitably someone would be forced to copy code from one repo to another. Sometimes, they’d need to tweak two components such as a site header so that they looked the same, even though their markup and styles were drastically different. The goal was to combine all five of them into a single codebase. The design team for Cloud Build had been pushing for a very long time to get all the sites — including ones not mentioned here — into a consistent visual language and was relieved to hear there were finally others wanting to do the same.

已经尝试了多种方法：每个可以借鉴的共享组件库； 单一的确定性样式集，该样式集是通过导入大型已编译样式表以及一组可视资产来使用的所有网站。 但是，无论团队多么勤奋，都不可避免地会有人将代码从一个存储库复制到另一个存储库。 有时，他们需要调整两个组件(例如网站标题)，以使它们看起来相同，即使它们的标记和样式完全不同。 目标是将所有五个代码合并为一个代码库。 Cloud Build的设计团队一直在努力将所有站点(包括此处未提及的站点)转换为一致的可视语言，并为得知最终还有其他人希望这样做而感到欣慰。

Unfortunately, the timing didn’t work out as well as expected. The Seattle group had just finished a major support push of  Collaborate and had some time to really focus on their web experience. At the same time, the Cloud Build team had promised a lot of great new features on one of their products and didn’t have the cycles to try and convert their more complex node site into the Seattle nginx sites. It was decided that the four sites already owned by Seattle would be combined.

不幸的是，时间安排不及预期。 西雅图小组刚刚完成了Collaborate的主要支持工作，并花了一些时间真正专注于他们的Web体验。 同时，Cloud Build团队已经承诺在其产品中提供许多出色的新功能，并且没有周期来尝试将其更复杂的节点站点转换为Seattle nginx站点。 决定将西雅图已经拥有的四个地点合并。

Each of these four sites was already an Angular 1.x site, so the hard part was just finding a way to make sure that all of the pages lined up somewhat well, and that duplicate styles were simplified. Combining sites that have existed for a range of one to three years ended up being more complex than originally anticipated, especially in a large single-page app. For example, the latest version of Collaborate included brand new features that other sites were missing.

这四个站点中的每个站点都已经是Angular 1.x站点，因此困难的部分只是找到一种方法来确保所有页面都排列得很好，并且简化了重复的样式。 组合网站已经存在了1-3年，最终比最初预期的要复杂，尤其是在大型单页面应用程序中。 例如，最新版本的Collaborate包含其他站点缺少的全新功能。

One of the biggest challenges was combining the different ways views are resolved. Some of the views were put together something like this:

最大的挑战之一是结合解决视图的不同方式。 一些视图被组合成这样的东西：

See the Pen UBE1 – multiple parts by Nathan St. Pierre (@natedsaint) on CodePen.

参见Pen UBE1 – Nathan St. Pierre( @natedsaint )在CodePen上的多个部分 。

While some of them were more like this:

尽管其中一些更像这样：

See the Pen UBE2 – Single Part by Nathan St. Pierre (@natedsaint) on CodePen.

请参阅CodePen上的Nathan St. Pierre( @natedsaint ) 撰写的Pen UBE2-Single Part 。

This was complicated by the fact our sites were on different minor versions of Angular. And in order to combine with Cloud Build in the future, we’d need to convert from the default path router to the new and shiny UI-Router.  This allowed us to have separate components for parts of the page without a million controllers. It also gave us the concept of states and state transitions so we could manage things like authorization much more easily. Of course, upgrading to UI-Router meant putting all our codebase on a single version of angular, and ALSO upgrading everything so it worked with the latest version of UI-Router. This was also taking into consideration the fact that we’d have to tweak our CORS headers so that the previous four sites were all served from one site but still hit the same internal subdomains for all our AJAX routes.

由于我们的网站位于Angular的其他次要版本上，这使情况变得复杂。 为了将来与Cloud Build结合使用，我们需要从默认路径路由器转换为新的闪亮UI-Router 。 这使我们可以为页面的各个部分提供独立的组件，而无需一百万个控制器。 它还为我们提供了状态和状态转换的概念，因此我们可以更轻松地管理授权之类的事情。 当然，升级到UI-Router意味着将我们所有的代码库都放在一个单独的angular版本上，并且还升级了所有内容，使其可以与最新版本的UI-Router一起使用。 这还考虑到以下事实：我们必须调整CORS标头，以使之前的四个站点都可以从一个站点进行服务，但是对于我们所有的AJAX路由仍会使用相同的内部子域。

As is true in most forms of code, but especially web dev, we started solving one problem and ended up solving 12.

正如大多数代码形式(尤其是Web开发人员)一样，我们开始解决一个问题并最终解决了12个问题。

(Source, https://xkcd.com/1722/)

(来源， https://xkcd.com/1722/ )

In the end, the way we solved this was with a healthy dose of fire. In this initial combination, we were able to remove about 1200 lines of redundant code, and orphaned another 2000 lines of abandoned routes and code paths that were no longer used. While we were at it, we made sure to improve our unit test coverage, and ended up going from around 34% coverage of legacy code to around 65% coverage of the new code. Security now was able to give us a pretty thorough review since everything was consolidated in one place, and we buttoned up a fair amount of glitches and holes that could have been exploited. While doing this, we also updated our bootstrap themes to match the new directives from the Unity brand: new logo, new colors, the whole nine yards.

最后，我们解决此问题的方法是使用健康剂量的火。 在此初始组合中，我们能够删除大约1200行冗余代码，并孤立了另外2000行废弃的路由和不再使用的代码路径。 在此过程中，我们确保提高了单元测试的覆盖率，最终将旧代码的覆盖率从34％扩大到新代码的约65％。 由于所有内容都集中在一个地方，因此安全现在可以对我们进行彻底的审查，并且我们解决了许多可以被利用的故障和漏洞。 在此过程中，我们还更新了引导程序主题，以与Unity品牌的新指令相匹配：新徽标，新颜色，整个九码。

We felt like we’d accomplished something great. But for better or worse, we weren’t done yet.

我们觉得自己已经取得了很大的成就。 但无论好坏，我们都还没有完成。

插曲 (Interlude)

What were once four great houses was now one magnificent house. Knights from all over the kingdom came to inspect the mighty new castle. It was more sturdy than any of the four had been, and its doors were open to all knights of the realm. Still, they took clear note of the new parapets and murderholes above, cautioning all to mind their manners in this new home of the great unified house. Yet all assembled could not help but gaze to the South, where lied the House of Clouds. It was a proud castle built in the rolling hills and prairie, but it looked lonely there. They served all who came diligently and with great fervor, but they were frustrated the new great castle had been reinforced while they were busy serving the citizens of the realm. Were they ready to join the unified house? Only time would tell…

曾经是四座伟大的房屋，现在变成了一座宏伟的房屋。 来自王国各地的骑士来检查这座巨大的新城堡。 它比这四个中的任何一个都更坚固，并且它的门向该领域的所有骑士敞开。 尽管如此，他们仍然清楚地注意到上面的新栏杆和谋杀坑洞，告诫所有人在这座统一大房子的新家中要谨记自己的举止。 然而，所有集会的人不禁凝视着南方，在那里撒谎了白宫。 那是一座骄傲的城堡，建在起伏的丘陵和大草原上，但那里看上去很寂寞。 他们为所有勤奋而热情的来访者服务，但他们为忙于为该领域的公民服务而对这座新的城堡进行了加固感到沮丧。 他们准备加入统一房屋了吗？ 只有时间能证明……

第二个任务：确保联盟 (The Second Quest: Securing An Alliance)

So after we got everything from our location combined, we came to Cloud Build to ask how we could help them combine our sites. At this point, anyone working on any of the four services mentioned above (including the new Collaborate website) needed to test their local changes by installing a local version of nginx, which then needed a set of config files not only to map the source of static files but also create local proxies to hit all the service endpoints in such a way the CORS endpoints could be resolved. Conversely, Cloud Build ran a node site which hosted files through express, so they just had to fire up their node process and everything would be configured. Of course, combining these two approaches would prove to be a complex burden of epic proportions, and a series of meetings indicated no one was quite sure the best way to approach it. So, of course, we had to try something.

因此，在将所有位置信息组合在一起之后，我们来到了Cloud Build，询问我们如何帮助他们组合站点。 此时，从事上述四项服务中的任何一项(包括新的Collaborate网站)的任何人都需要通过安装本地版本的nginx来测试其本地更改，然后，该版本需要一组配置文件，不仅要映射源文件。静态文件，而且还创建本地代理来以可以解决CORS端点的方式命中所有服务端点。 相反，Cloud Build运行了一个节点站点，该站点通过express托管文件，因此他们只需要启动其节点进程即可进行所有配置。 当然，将这两种方法结合起来将证明是史诗般的工作量的繁重负担，而且一系列会议表明，没有人完全确定采用这种方法的最佳方法。 因此，当然，我们必须尝试一些东西。

It took us about three days, but by the end, we had created something. Some called it a Frankenstein. Since we used living sites and not a pile of corpses, I preferred Chimera. We tried to stay away from the centipede analogy.

我们花了大约三天的时间，但是到最后，我们创造了一些东西。 有人称它为科学怪人。 由于我们使用的是生活场所而不是一堆尸体，因此我更喜欢Chimera。 我们试图远离the类比。

But in the end, we were serving all of the routes of the individual sites through one single-page app, and had reduced somewhere around 3000 more lines of redundant code. In the process, we became much more familiar with how the Cloud Build code worked, and how they integrated their builds and support forms with the website for a pretty beautiful and seamless experience. This gave us the ability to provide a Collaborate support form that gave users direct access to our support team through the website. At the same time, Cloud Build was able to consolidate some of their older logic with the shared views, and rather than having five different ways to look at your project, we settled on just one component with access to each of the different services.

但是最后，我们通过一个单页应用程序为各个站点提供了所有路由，并减少了大约3000行冗余代码。 在此过程中，我们更加熟悉了Cloud Build代码的工作方式，以及他们如何将其构建和支持表格与网站集成在一起，从而获得了非常美丽和无缝的体验。 这使我们能够提供协作支持表格，使用户可以通过网站直接访问我们的支持团队。 同时，Cloud Build能够通过共享视图整合其一些较旧的逻辑，而不是采用五种不同的方式来查看您的项目，我们仅选择了一个可以访问每个不同服务的组件。

追求未来：永无止境的追求 (Quest To The Future: The Neverending Quest)

Now that we have combined our powers, we have continued to iterate on a variety of new technologies. We’ve updated to the latest version of AngularJS (1.6), and we’ve converted large portions of old confusing nested controllers into simple and reusable components. We’ve also increased our test coverage, and have begun a series of steps to make our quality higher than ever. On top of that, we’ve created a common library that combines a common design language with thoroughly tested and documented components. Any team at Unity (who is using Angular) can potentially make use of these components, reducing duplicate effort and inconsistency across the entire company.

既然我们已经合并了自己的能力，那么我们将继续迭代各种新技术。 我们已经更新到了最新版本的AngularJS(1.6)，并且已经将大部分旧的令人困惑的嵌套控制器转换为简单且可重用的组件。 我们还增加了测试范围，并开始了一系列步骤以使我们的质量比以往更高。 最重要的是，我们创建了一个通用库，该库将通用设计语言与经过全面测试和记录的组件相结合。 Unity的任何团队(正在使用Angular的人员)都可以利用这些组件，从而减少整个公司的重复工作和不一致。

What does that mean for you?

这对您意味着什么？

Well, primarily it means that finding and fixing bugs has gotten significantly easier. What took days to debug now only takes hours. That doesn’t mean we won’t have problems, or end up somehow stumbling into confusing and not useful user interfaces on the dashboard. Our customers being people who make software for a living is a wonderful double-edged sword: they know exactly how hard it is to make everything perfect, but they know exactly how to find broken things and expect them to be fixed. This is great motivation for us, and we love hearing feedback from you on what works and doesn’t work on developer.cloud.unity3d.com.

好吧，首先，这意味着查找和修复错误已变得非常容易。 现在花了几天时间进行调试，只需要几个小时。 这并不意味着我们不会有问题，也不会以某种方式最终陷入仪表板上混乱且无用的用户界面。 我们的客户是为软件谋生的人，这是一把美妙的双刃剑：他们确切地知道使所有事情变得完美是多么困难，但是他们确切地知道如何找到损坏的东西并希望将其修复。 这对我们来说是很大的动力，我们很乐意收到您关于在developer.cloud.unity3d.com上有效和无效的反馈。

Now that we’ve equipped ourselves with the tools to succeed, we can’t wait to show you a better experience every time you use the site — including an all-new layout designed to make use of our latest Unity branding and usability guidelines.

现在，我们已经为成功配备了成功的工具，我们迫不及待地希望在您每次使用网站时为您提供更好的体验-包括旨在利用我们最新的Unity品牌和可用性准则设计的全新布局。

We hope you love using our products and services, and we really do care. And we know that you care too! So let us know via twitter, or in the comments below: what do you like? What don’t you like? Let’s make Unity better. After all, democratizing development means (if you’re doing it right) that everyone gets a say.

我们希望您喜欢使用我们的产品和服务，我们也确实在乎。 而且我们知道您也很在乎！ 因此，请通过twitter或以下评论让我们知道：您喜欢什么？ 你不喜欢什么 让我们使Unity更好。 毕竟，使发展民主化意味着(如果您做得对的话)每个人都有发言权。

翻译自: https://blogs.unity3d.com/2017/08/30/game-of-sites-unity-between-five-kingdoms/