DevOps 管道

1. 持续集成/持续交付/部署 (CI/CD)

持续集成是频繁提交至通用源代码存储库的一项实践。它不断将代码变更集成到现有代码库中，以便快速识别不同开发人员的代码变更之间的所有冲突，且能相对轻松地进行补救。该实践对于提高部署效率至关重要。

我们认为，基于主干的开发是持续集成的必要条件。如果您未频繁地提交至共享源代码存储库中的公共分支，则无法称为“在进行持续集成”。如果您的构建和测试流程已实现自动化，但您的开发人员正在使用孤立且长期存在的功能分支，且这些分支很少集成到共享分支中，那也无法称为“在进行持续集成”。

持续交付可确保应用源代码的“主”或“主干”分支始终处于可发布状态。换句话说，如果管理层在星期五下午 4 点 30 分来到您的办公桌前说：“我们需要立即发布最新版本”，那么您只需按一下按钮即可部署该版本，而不必担心失败。

如此一来，您将拥有与生产环境几乎相同的预生产环境，并确保执行自动化测试，以便在将代码合并到主或主干分支之前，识别可能导致失败的每个变化因素。

持续部署需要进行一定程度的持续测试和运营，这样便可在无需任何人工干预的情况下验证新版本的软件并将其部署到生产环境中。

此情况极少出现，且多数情况下均非必须。通常只有拥有数百或数千名开发人员，且每天要进行很多发布的独角兽企业才需要甚至想要拥有此等自动化水平。

为了简化持续交付和持续部署之间的差异，可将交付想象成 FedEx 人员递给您一个盒子，并将部署想象成您打开盒子并使用其中的东西。如果在收到盒子和打开盒子这段时间内需要更改产品，那么制造商就会遇到麻烦！

2. 持续反馈

以往的瀑布式软件开发方法的最大痛点便是缺乏及时反馈，这也是设计敏捷开发方法的原因所在。我们几乎可以肯定，如果新功能从构思到实施需要数月或数年的时间，那么最终结果应该并非客户所期望或想要的。敏捷开发可确保开发人员更快地收到利益相关者的反馈。如今，有了 DevOps，开发人员不仅可以从利益相关者处获得持续反馈，还可通过管道中代码的系统化测试和监控获得反馈。

持续测试是每个 DevOps 管道的关键组件，也是持续反馈的其中一个主要推动因素。在 DevOps 流程中，变更不断地从开发转移到测试再到部署，这不仅可以实现更快的发布，而且还可以交付更高质量的产品。这意味着在整个管道中进行自动化测试，包括在每次构建更改时进行的单元测试、冒烟测试、功能测试和端到端测试。

持续监控是持续反馈的另一个重要组件。DevOps 方法需要使用预备、测试甚至开发环境中的持续监控功能。监控生产前环境中的异常行为有时很有用，但总的来说，这是一种用于持续评估生产中应用的运行状况和性能的方法。

现在有许多工具和服务具有此功能，这可能涉及监控本地或云基础架构（例如：服务器资源、网络等）或是应用或其 API 接口的性能等任何方面。

3. 持续运营

持续运营是一个相对较新且不太常见的术语，其定义也各不相同。其中一种解释是“持续正常运行时间”。例如，在采用蓝/绿部署策略的情况下，您有两个独立的生产环境，一个是“蓝色”（可公开访问），另一个是“绿色”（不可公开访问）。在此情况下，新代码会部署到绿色生产环境中，且当它被确认可以正常运行时，开关（通常位于负载均衡器上）就会打开，流量便会从“蓝色”系统切换到“绿色”系统。如此一来，便可消除最终用户的停机时间。

持续运营的另一种理解是持续警报。这是一种概念，即如果应用或基础架构中出现任何性能异常，工程人员将随时待命并收到通知。多数情况下，持续警报与持续监控是相辅相成的。