一年前，我写了关于如何为云为开发-ops管理提供了新的机会。OpenLogic刚刚发布的产品就是从头开始在云中运行的。我们将应用程序设计为允许在很大程度上实现零停机部署，并构建了我们的部署策略，以便在必要时从头构建所需的一切，并动态地交换正在运行的服务器。这个过程对我们非常有效。我们可以在几分钟内启动新的应用服务器，这个过程给了我们从零开始或从中间保存的基线开始的灵活性，以尽可能地提高部署时间。加上看板风格的连续发布过程，我们快速、自信、安全地部署了新特性。这与我们十多年前开始时的情况相去甚远，当时我们每六个月提供cd和dvd。
在过去的一年里，我的团队制定了一些长期目标，以充分利用我们在CloudSwing上从零开始构建的方法，并将它们应用到我们的团队中OpenLogic交易所(OLEX)产品套件。以下是我最初的博客中的三项内容，以及过去一年在简化开发过程中所取得的进步。
1.敏捷过程将特性转化为能够快速交付价值的小故事。
我们已经从主要基于Scrum的工程过程调整为混合过程，将Scrum的特性与类似于看板的连续发布过程相结合。对于大型系统，在将新代码投入生产之前，可能需要执行相当数量的回归，因此我们的目标是更快地将特性通过QA(质量保证)过程。如果特性通过QA的速度不能快于它们进入QA的速度，那么连续发布将无法工作。为了做到这一点，我们利用了每一个工程师，以及其他内部团队，作为QA过程的一部分。我们强调创建一个自动化的测试平台，其中每个人都对QA回归套件负责，而不仅仅是我们较小的QA团队。
2.可重复的构建、功能测试和持续集成将质量控制转变为可预测的、可自动化的过程。
为了完成上述流程更改，我们让整个团队参与到回归套件维护中。我们的开发测试和QA测试是在两个不同的系统中进行的，因此我们仔细研究了现有的测试工具，选择了最好的，给定的标准是它必须是可自动化的并在持续集成中运行。
使用开放源码，利用最新趋势需要尽可能保持依赖项最新。在我们的案例中，我们需要对Rails进行重大升级，以充分利用新的测试工具，比如水豚。在完成必要的升级之后，我们实现了一个新的持续的、可重复的构建过程，团队中的每个人都要维护这个过程。这分散了测试负载，因此即使是接受测试和回归测试问题也可以在代码完成之前更早地识别和解决。
随着这个新系统的成熟，我们的发布回归时间显著减少，并且我们保持了一个高的发布节奏。我们快速地为客户提供新功能。
3.Dev-ops让开发人员参与如何为生产环境构建，并尽早经常地测试该环境。
OLEX是一个比CloudSwing更大、更复杂的产品，在部署期间涉及许多不同的系统。由于我们非常注重自动化，部署过程的许多部分已经自动化了，可以使用Capistrano、Webistrano和内部脚本等工具。但是，流程需要停机，因为所有服务都切换到新代码。利用固有特性的项目像独角兽™和Resque®,组织我们的特性交付进度,和更新我们的部署模型使用磁盘工具如威士忌和撒,我们创建了一个过程,使我们能够发布代码,通常为零停机时间,在短短几分钟。由于我们的客户中越来越多的是国际用户，这一点尤其有帮助。
所有这些都是观念转变的延续，即从周期较长的大型发行版快速转变为许多较小的发行版。通过保持我们的开源依赖关系的最新状态，我们可以利用新项目和新想法，而无需进行大量的投资。这是敏捷的本质，并不断利用我们的敏捷性。
