Atlassian是怎样进行持续交付的？且听 Steve Smith一一道来

Steve ：实际上，在我们实施持续交付时总共面临着三方面的问题：有技术方面的，也有组织和管理方面的问题。

首先来谈一下技术方面的问题，这方面的问题是比较明显的。包括搭建服务器、设置机器、创建必须的脚本用于自动部署相关的变更，等等。但还有一些更微秒的挑战，会随着对深入交流的需求而渐渐浮出水面。一旦你创建了某种环境，能够实现将变更一键部署到生产环境，你就需要确保所有团队都保持灵活与开放式的沟通，而不会因为变更的节奏加快而使他们失去警惕性。Atlassian是一个高度分布式的公司，它的办公室遍及悉尼、越南、阿姆斯特丹和旧金山，传统的沟通渠道无法满足我们的需求。我们所需的沟通能力不仅能够让人们简单地进行信息交换，还能够在团队之间建立密切的关联。因此我们在这方面的技术上投入了很大精力，这些技术能够让我们实现高质量视频会议、共享图片、团队聊天等等，对于我们十分关键。

分布式团队面临的另一个问题与时区的不同有关。如果你需要与某位同事进行协作，只要你们处于同一时区，即使是身处不同的办公室，也能够很方便地进行视频会议、共享屏幕。但如果你与同事处于不同的时区，那么就需要寻找某些工具，能够帮助你进行线下协作。你可以提交一个pull请求，让同事帮你审查某个变更。但同时，为了实现这一点，需要某些工具帮助你方便地检索相关的变更，并且以一种集成的方式提交反馈。并且所有这些工具必须与其它工具进行集成，以提供一种无缝的工作流体验。

这就带来了组织方面的变更。一般来说，人们对于任何改变都是相当谨慎的。当开发者开始习惯于创新新服务的思想，那么系统管理员就会对由此带来的网络变更而感到担忧。当开发者开始部署容器化的应用（使用Docker或类似技术），系统管理员则会对于容器中可能包含的软件，以及它所带来的整体影响心存顾虑。与之类似的是，如果系统管理员要求开发者以某种特定的方式编写应用，或是对某种技术的使用进行干预，开发者也会因为缺乏自由而感到不快。只有在所有人齐心协力的前提下，持续交付才能够发挥其作用，所有团队之间必须进行合作，才能够让变更顺利地生效。

最后，我们还遇到了大量管理方面的问题。Atlassian提倡一种文化“想要寻求怎样的改变，就要身体力行”，这鼓励人们努力推动他们所期望的改变。它能够让人们打破技术壁垒，鼓励人与人之间的互动。但同时它也带来了大量的问题，例如由谁来管理风险，或者说由谁担当某种改变的最终业务负责人。Atlassian处理着大量的客户请求，因此我们必须对相关的风险加以管理，这意味着像SOX和PCI这样的制度会对我们的内部流程施加影响。我们需要适当地分配责任，对软件进行变更的人与最终将其发布到生产环境中的人必然是不同的，因此在持续交付服务中需要引入控制功能，让特定的角色能够对某个特定的检查点进行校验。

Steve ：创建一种工作流的思想非常重要。问题跟踪系统为某个特定请求过程中发生的每一件事创建了一个流程的标识符，使每个人都能够对它的状态进行从头至尾的全程跟踪。通过将问题跟踪系统与VCS和CI进行集成，提出这个ticket的人就能够看到它的任何变化：开发过程是何时开始的、问题是何时出现的，并且经过了怎样的处理、以及它是何时部署的等等。这样一来，人们就能够更好的了解相关信息，对于整个流程的满意度也更高。

这一点也为开发者带来了一种积极的副作用：因为项目干系人能够随时找到所需的信息，他们就不必再去打扰开发者、系统管理员或其它任何人。这种趋势正在得到人们的认可，举例来说，大多数云系统都提供了某种状态页面，展示了每个系统的运行状况，因此每个人都能够随时了解相关情况。

由于我们所用的问题跟踪、版本控制以及CI系统都是Atlassian自身的产品，因此它们从一开始就是紧密集成的。不过他们的相互集成是通过公开的RESTful API实现的，因此其它产品也能够通过对相关的终结点进行相应的调用而实现集成。

InfoQ：在你的演示中，使用特性分支是整个方法的核心，与将所有代码都放在master分支的策略相比，这种策略是否存在某种缺陷？

Steve ： 如果你的多个特性之间存在着联结性，它们就会变得非常复杂。同时，如果他们之间存在相互依赖，或是需要对方进行某种改变，问题就会出现。不过，一旦发生这种问题，这很可能意味着他们实际上是一个特性，因此这两个问题应当被合并在一起。

有时，这种互依赖性更多地是由技术方面导致的。如果公开暴露的API没有足够的封装性，使用者就可能会对其它系统的内部工作进行某些假设，导致了人为的互依赖性。因此遵循优秀的编程实践是关键，并且要确保技术依赖性不可进一步变为业务方面的依赖性，这将妨碍你在并行的分支中开发并行的功能。

最后，你需要时刻牢记，当你创建某个特性分支时，就是对主线的一次转移。因此你需要经常进行rebase，或从master分支进行pull操作，以确保你的特性分支的经常更新。否则，最后的合并工作可能会面临极大的挑战。

Steve ： 这一点又回到了测试的基本思想：测试是一组被编写的代码，但不会部署到生产环境中。在某些人一眼看来这似乎是一种浪费。然而，随着时间的推移， 已经有大量的研究证实了测试的价值 。

对于持续交付来说也存在着同样的争议：对于任何一个有一定复杂度的软件项目来说，开发的成本都是最高的。因此，为了保证软件能够正常工作，这就是对于进行测试所必须的基础设施投入成本的理由。运行测试的资源成本往往低于开发者的时间，以及未能及时找到bug所带来的影响，这就意味着测试资源是值得投入的。这也是为什么许多CI系统都支持按需进行纵向扩展，以使用云端的资源。为了应对峰值时的请求而进行临时性的纵向扩展，通常来说都是值得的。

最终，这些额外的成本会将敏捷理念带到下一级别：提供更小的反馈循环，以及尽快交付。

Steve ： 目前在实施持续交付的人可以说在站点了科技的前沿，因为CD的理念才刚刚得到普及。最大的困难或许在于如何在内部进行推销：搭建这一整套过程可能要花上很长时间，而要向那些保守的管理人员灌输CD的价值也是非常困难的。关键在于向人们传授知识，告诉他们CD能够带来的益处，并将信息传递给所有角色（系统管理员、项目干系人、风险管理员等等），让他们认可这一点是大家共同的思想。你无法强行推行这一举措，或者只是因为别人这么做而跟风。

大型组织需要理解每种CD系统都是不同的。要在其中找到一个共性，使整个过程成为可重复的，这一点或许并不容易。此外，其中的某些权衡之处可能使它未必对于每个人都有好处，因此对于每种特定的情况都需要进行分析。它还对组织的文化有所要求，要做到对变更进行积极地反应，而不是一开始就设计好所有的计划。

容器技术或许能够对整个搭建流程有所帮助，虽然它自身也必须克服一些挑战。其中主要的问题在于安全性，尤其是如何对容器中的软件进行管理，并保证它的实时更新。传统情况下，这一过程是由系统管理员负责的。但由于现在开发者也能够创建容器，因此这一责任也延伸到其它团队了。我们要对所有权进行重新定义，可以采取共同所有权的形式。

另一方面，像Puppet和Chef这样用于创建大量机器的技术，它们的管理是通过配置实现的。而这种配置如今看上去越来越像代码了，这也意味着系统管理员不得不应用一些软件开发的实践。此外，如果业务分析师也希望参与持续交付的流程，对哪些特性在何时部署到生产环境进行校验，那他们也必须熟悉开发者所使用的工具。

这也意味着组织中的每个人不得不成为某种通才，公司必须鼓励进行跨职能的培训，才能够实现这一点。Pull请求对这一点能够有所帮助，每个部门或角色都可以请求其它部门对变更进行审查和批准，然后再继续下一流程。