如果一个issue没能在社区中找到回答或修复，而它的优先级又足够高时，值班的人就会把它分配给团队里一个了解此类问题的工程师。整个TensorFlow团队的成员都有自己的GitHub账号，因此我们可以用正常的GitHub issue追踪器来实现任务的分配。我们确实考虑过把GitHub上提交的bug复制到我们的内部系统中，但要为相同信息同步两份副本，代价太高了。最后，我们让工程师们除了留意内部系统的追踪器之外，也要打开邮件通知，以便能够及时看到自己被分配了哪些GitHub上的问题。

　　Stack Overflow

　　Derek Murray是Stack Overflow值班小组的带头大哥，我觉得他回答问题的技能真是碉堡了。根据他的资料页，这个人发过的帖子已经触及到了130万人；为了让我们能够及时追踪网站上那些带有#TensorFlow标签的问题，他还设法创建了一个RSS驱动的自动化电子表格。起初我们采取每周轮班制，但发现要处理问题的量对于一个人来讲实在是太大了；后来我们采用了自动分配系统，情况变得好多了。

　　我本人就在这个轮班小组里，因此每天早上我浏览完自己的邮件后，我都会查看电子表格来弄清楚自己被分配到了哪些问题。很遗憾，我们没法自己回答全部的问题，但每一个新进来的问题我们都会看。如果问题相对简单的话，我们就自己把它答了。

　　当然，值班的工程师得顶到被问题轰炸的前线去，但有些时候，回答某些问题需要更多的时间和专业知识。如果某个问题看上去能被答出来，但社区里却没看见站出来的英雄，我们就会研究一下代码，扒一下团队里有谁可能会对这个问题有些想法（通常是用git blame）。然后值班工程师就会向我们找到的人发封邮件，看其是否能提供一点帮助。

　　邮件列表

　　我们设置了一个邮件列表，但起初却并不知道该怎么用它。我们很快就看出来，用这种方法来追踪issue和回答一般问题有多辣鸡。

　　后来，我们把它当成讨论区来用，GitHub和Stackoverflow都不合适的话题，就发到邮件列表，但是在实际操作中我们发现，即便是架构问题，用GitHub issue来讨论也比邮件列表合适。

　　现在我们用这个邮件列表来发送信息和贴通知，还算是值得订阅的。

　　代码同步

　　和我聊过的许多人都对一件事表示十分吃惊——那就是在谷歌内部，我们使用的代码库和我们在GitHub上所开放的几乎完全相同。不过，两者间还是存在一点区别的，比对谷歌专用基础设施的支持是独立的，路径也和GitHub版不一样，但同步的过程是完全机械的。我们至少每周推出一次内部更新，更多时候是下载GitHub版本。

　　麻烦的是，我们要进行双向同步。在GitHub的公共项目和我们的内部版本上，有很多变动是同时发生的，而我们需要反反复复地把它们全部进行合并。没有现成的基础架构可供利用，因此我们使用了自己创造的一套Python脚本来处理这些问题。这些脚本能够将GitHub上所有的变动拉进我们的内部资源库里，转换所有的header path和其他细微的变化，将它们和最新内部版代码合并，并在内部创建一个副本。随后就可以进行另一个方向的同步了，我们会将所有的内部代码转换成外部的格式，并用相同的脚本把这些结果合并到最新的GitHub版上。

　　对于内部的修改，我们同样会尽力让每次check-in都呈现为单独的git commit，同时把作者的GitHub账号和解释这些变动的评论包括在内。我们在GitHub上有一个特别的“TensorFlow园丁”账号来完成上述过程，一个内部的commit被转移到GitHub上之后，是这样的：

　　要确保即使代码变了，这个转换流程依然有效，是很有挑战性的。为了验证这种有效性，我们要求把内部代码通过这个脚本转换成外部版本，再转换回来之后，和最初的内部版一模一样。在任何接触到TensorFlow代码库的内部更改上，我们都会运行这个测试，通不过测试的修改会被拒绝。

　　对于那些提交pull request的人，我们常常会提一些奇怪的变更要求，通常，这样做的原因是我们必须确保他们的代码能适用于这个同步流程。

　　Jenkins测试

　　因为要支持很多不同的平台，我们希望有一个适用范围很广的测试工具。TensorFlow会在Linux、Windows、OS X、iOS、Android、Android Things、以及树莓派上运行，同时我们还有为GPU准备的不同代码路径，包括CUDA和OpenCL支持、以及Bazel、cmake，和无格式makefile的构建进程。