快速指南：在DevOps中实现持续交付

等等，速度难道不是所有软件开发的关键吗？现如今，公司通常都会要求开发人员每天，每周或是每月进行软件更新或者添加新的功能。这在过去，甚至在敏捷开发时代下都是闻所未闻的严苛要求。

不止于此，一些公司还会追求更快的软件更新速度。Sehringer说：“如果你在亚马逊工作，那很可能每几秒钟就需要进行一次更新。”

不论你是软件漏洞的行家，或是开发人员又或是运维专家，当必须快速完成构建与发布任务时，大家该如何提供高质量且“不破坏任何既有成果”的代码呢？面对这样的问题，每个人都有自己的妙招。“敏捷开发”，“持续构建”和“持续集成”则是其中呼声最高的三种方案。

下面让我们对其进行概括说明。

软件服务供应商Nexient公司资深交付主管Nate Berent-Spillson指出，“你可以把持续性看成是‘自动化’。它降低了开发和部署的成本与时间。”

那为什么不直接使用自动化作为专业表达？

持续构建的本质在于“通过小步骤进行构建。”每个小的步骤都是为了把软件以持续性方式集成到生产环境中这一目标而服务。

尽管部分实践者会对“持续集成”概念作出进一步细分，但“持续集成”这一标签仍常常被指向同一类事物。持续构建属于持续集成的组成部分：在持续构建的过程中，开发者只需编写代码，并将其与仓库中现有的代码合并，之后就可以让自动化来接管构建和测试合并后的代码。这样开发者将不必浪费时间在手动编译和测试上，而是把更多时间投入到代码编写与创新实现身上。

但是，仅仅利用部分自动化工具并不意味着能够提升整个发布流程的速度表现。毕竟代码本身还没有部署完成——而部署工作可能需要手动操作，也可能因为开发人员忙不过来而被推迟。