到目前为止，你已经确定了听说“每个公司都从事软件业务。”这不再是一句随口就说的话了。今天，所有类型的公司——不仅仅是技术公司——都必须快速交付高质量的软件才能生存。考虑到标准普尔500指数公司的平均年龄从20世纪50年代的60年下降到现在的不到20年。一个关键原因是，技术正在扰乱各行各业的业务。如今，如果不使用应用程序或网站，你就无法购买一杯咖啡、看电影或看医生。
这就为技术团队带来了巨大的新工作量。2018年对IT专业人士的一项调查发现，IT专业人士去年面临的项目请求平均增加了27%——其中大部分与创建新应用程序或修改现有应用程序有关。由此产生的工作量令人望而生畏:大多数IT专业人员都要负责交付2018年新增10个或更多应用。有三分之二的人承认他们无法完成所有要求他们完成的项目，这是一个引人注目的警告。
作为回应，企业显著地加快了他们的软件开发工作，通过采用诸如敏捷开发、DevOps、云计算以及越来越多的持续集成、持续部署和持续交付(通常称为CI/CD)等技术，将快速应用开发转变为战略性的业务武器。这篇文章解释了CI/CD如何改变了现代软件的面貌。
软件开发现在是战略重点
现代软件公司理解快速交付高质量面向员工、客户和合作伙伴的应用程序的重要性的人具有优势。他们知道，通过提供更好的用户体验，同时保护敏感数据，他们将获得更多的客户，提高员工的工作效率，增加收入和利润。
但他们必须非常迅速和有效地做到这一点。这意味着不断更新和发布产品代码的新版本。
那么他们在开发什么?三分之二(66%)的人关注的是客户和合作伙伴作为优先事项，并将服务于他们的应用程序放在他们的待办事项列表的首位。但这只是故事的一部分。内部效率和效力也岌岌可危,超过一半的公司都在开发支持内部运营的应用。这些是业务关键(但困难)的目标，开发人员迫切需要帮助来实现它们。输入CI / CD。
CI/CD:软件开发实践成为主流
结果是，软件开发实践这个神秘的主题不再只对软件开发人员感兴趣，而是正在成为战略业务决策(包括CI/CD)中的一个前沿和中心主题。而是因为这些项持续集成，持续交付，和持续部署它们是如此相似，以至于很难区分。
让我们试着把它们拆开。
在最基本的层面上，持续集成当开发人员频繁测试提交到项目主存储库的任何新代码，以确保新代码与现有代码兼容时发生。持续集成也是另外两种“持续”方法的组成部分。持续交付这意味着确保您的代码随时可以部署，尽管在将其投入生产环境之前可能需要等待—通常是出于业务原因。持续部署实际上只是将持续交付向前推进了一步，自动发布，不需要人工干预。
记住这些基础知识后，让我们看看每个术语的起源，并探索它们如何帮助软件团队更快地交付更好的应用程序。
持续集成
如前所述，持续集成指的是开发人员对代码兼容性保持严格的控制。在实践中，它是每次开发人员做出更改时自动构建和测试代码的过程。开发人员在进行最小的更新后，通过将更改合并到共享的版本控制存储库来共享代码和单元测试。然后运行自动构建和测试。这可以帮助开发人员在开发过程的早期发现错误，从而避免发布日的困境，而在开发过程的早期，这些错误相对容易修复。
持续一体化的第一次出现是在20世纪90年代。IBM的Grady Booch首先命名并提出了该方法在他的Booch软件开发方法中，在他的书的早期版本中，面向对象的分析与设计。1996年，史蒂夫·麦康奈尔描述了”每日构建和冒烟测试”技术在IEEE日报》建议什么是“极端的”实践，每天测试代码。当极限编程在20世纪90年代末出现时，它采用持续集成的概念每天整合不止一次的概念。
然后，在2000年，Martin Fowler写下了那个时期持续集成实践的基石描述:
- 为源代码建立一个单独的存储库，这样每个人都可以获得当前和以前的源代码。
- 自动化构建，这样任何人都可以在任何时间用一个命令从源构建系统。
- 自动化测试，以便您可以在任何时候使用单个命令运行测试套件。
- 确保每个人都能访问到当前最好的可执行文件。
持续集成是敏捷的一个关键方面
然后出现了敏捷编程方法。持续集成最终成为敏捷哲学的关键部分。
敏捷是对曾经占主导地位的“瀑布式”软件构建方法，它强制执行建立用户需求的顺序模型，然后构建一个单一的、完成的软件版本来满足这些需求。不幸的是，客户的需求在开发过程中经常发生变化。当软件在传统的瀑布过程下交付时，客户通常想要完全不同的东西。这浪费了大量的时间和资源，并导致了大量失败的软件项目。
20世纪90年代，开发人员意识到瀑布模式不再有效，开始尝试其他方法来构建软件。尝试了许多新方法，包括Scrum和看板。在2001年,敏捷软件开发宣言在敏捷软件开发的标签下聚集了许多这样的实践。
当使用敏捷方法，开发人员和其他涉众协作不断迭代需求和解决方案，鼓励快速和灵活地响应变更。亚博直播平台使用这种迭代方法，就不存在最终的软件产品。
持续集成是敏捷方法论的核心因为它最小化了风险，并使敏捷团队能够以快速而可持续的速度工作。同样重要的是，每次迭代都交付了新的价值，以及向开发人员提供持续反馈的机会。
持续交付
然而，持续集成仅仅为企业提供了将高质量软件快速交到用户手中的部分途径。这条路径的下一步是:持续交付。
实践持续交付的开发人员生成的代码总是可以部署的，并且随时可以投入生产。持续交付是软件开发实践和方法的集合，可以在提高质量的同时加速上市时间。
根据马丁·福勒的戒律，持续交付的要点可由以下几个关键问题来概括:
- 您的软件在整个生命周期中都是可部署的吗?
- 在开发新功能时，您的团队能否优先考虑并保持软件的可部署性?
- 每当有人对其应用程序和基础设施进行更改时，任何人都能收到关于其应用程序和基础设施的生产就绪状态的快速、自动反馈吗?
- 您能否按需将任何版本的软件部署到任何环境中?
关于持续交付的一个关键点是，当团队拥有软件时准备好了要部署，他们不一定要立即部署。他们可能会保留它——通常是出于商业原因——直到他们决定将其发布到生产中。因为每个代码更改都是通过自动化交付到分段环境的，所以他们只需按一下按钮就可以部署它。
连续交付的概念是一个重大突破。正如库尔特·比特纳(Kurt Bittner)所言福雷斯特研究公司,广泛引用的一句话是，“如果敏捷是开始，那么持续交付是最重要的。”然而，有些人认为这是一种误导，因为它意味着持续交付来自敏捷。虽然它经常与敏捷一起使用以加速代码开发，但它并没有这样做。
如果持续交付不是敏捷的一部分，那么做了它从何而来?这是持续集成的自然扩展，它与另一种重要的新it哲学并行开发:DevOps。虽然独立于DevOps，持续交付有助于使DevOps成为可能。为了充分理解持续交付，我们需要深入研究DevOps。
DevOps和持续交付
如果敏捷是对瀑布缺陷的一种回应，创建DevOps是为了解决一个相关问题:软件开发(dev)和IT运营(ops)团队的非自然分离。
DevOps从整个组织中引入涉众，并共享软件性能和可靠性的责任，在将软件解决方案应用于重要的业务任务和流程时，平衡开发中的灵活性需求和所需的严谨性——关于安全性、遵从性和兼容性的严谨性:亚博直播平台
随着公司开始使用敏捷和DevOps，他们意识到了显著的协同效应。正如持续集成对于敏捷至关重要一样，持续交付对于DevOps也是必不可少的。敏捷是作为开发人员的哲学而诞生的，而DevOps，通过持续交付，将IT操作添加到组合中，旨在改善跨业务的多个元素的通信。
持续部署
从持续集成和持续交付到持续部署，又向软件开发生命周期的自动化迈进了一步。通过实践持续部署，您可以确保每个更改都足够健壮和清晰，可以立即发布给用户—或客户—而无需任何手动干预。
换句话说，如果持续交付在向用户交付软件的过程中插入了一个“暂停”按钮，那么持续部署就会亮起永久的绿灯。一些专家认为连续部署应该是每个组织的最终目标，这些组织没有对自动化软件发布的遵从性或其他约束。
因为持续部署不需要人为防范有缺陷的代码，所以团队应该使用它进行频繁的、小规模的、增量的更新，而不是对大型系统进行大规模的更改。此外，开发人员必须安全且严谨地遵循严格的持续集成和自动化测试方法，包括部署工具当新代码发布给用户时，提供可见性并避免意外。最后，您需要能够从导致用户体验到自动测试无法捕捉到的错误或崩溃的更新中退出。
持续部署的好处是开发项目变得更加可预测和常规。即使每天有数以百计的开发人员要做多个更改，新代码也能快速、顺利地部署，越快越好。
最终的结果是:持续的软件开发
持续集成、交付和部署统称为持续软件开发。与敏捷和DevOps相关联，它们共同工作，使企业能够利用自动化来更快地开发、构建、测试和部署更高质量的代码。同样重要的是，它们允许软件组织更快更容易地理解和响应市场变化，并且已经被证明与业务成功相关。
尽管CI/CD可能不适用于所有企业，软件部署的频率经常被引用为高功能软件组织的最佳单一度量并日益与商业成功联系在一起。最好的、最高效的现代软件公司每天会多次更新他们的站点，对产品代码的更改只需要几秒钟，而不是几个月或几年。
敏捷实践和持续集成就像花生酱和果冻。如果不考虑持续集成，你就不能正确地使用敏捷。同样地，为了可靠地建立DevOps，您需要持续交付，这包含了持续集成。最后，如果您在完全自动化部署的同时严格地应用持续集成和持续交付方法，您就可以实现持续部署——端到端自动化软件开发的顶峰，也是当今软件和业务成功的最佳途径。
