DevOps 管道

DevOps 管道是一组自动化流程和工具,它允许开发人员和运营专业人员协作构建代码,并将代码部署到生产环境中。

Krishna Sai 头像
TOM HALL

DevOps 推广人员和从业人员


DevOps 是一项创新运动,它彻底改变了开发和运营分离的孤立式组织结构。其结果是文化的转型,即开发人员和运营专业人员相互协作,采用自动化,提高部署速度和灵活性。

由此产生的 DevOps 结构具有明显优势:采用 DevOps 实践的团队可以改进和简化其部署管道,从而降低事件发生频率和影响。“谁构建,谁运行”的 DevOps 实践正在迅速成为一种常态,这是有充分理由的:2020 年 DevOps 趋势调查中的几乎所有调查对象 (99%) 都表示,DevOps 对他们的组织产生了积极影响,同时近一半的调查对象发现 DevOps 有助于缩短上市时间并提高部署频率。

实施 DevOps 说起来容易,但做起来难。成功实现 DevOps 需要适宜的人员、流程和工具。

什么是 DevOps 管道?


DevOps 管道是一组自动化流程和工具,允许开发人员和运营专业人员协作构建代码并将代码部署到生产环境中。虽然 DevOps 管道可能因组织而异,但它通常包括构建自动化/持续集成自动化测试、验证和报告。此外,它可能还包括一次或多次在允许代码继续运行之前需要进行人工干预的手动控制。

连续性是 DevOps 管道的一个差异化特征。这包括持续集成、持续交付/部署 (CI/CD)、持续反馈和持续运营。每个功能都具有持续性,而不是一次性测试或有计划的部署。

互联圆环图标
相关资料

免费试用

工具图标
相关资料

了解有关 DevOps 工具的更多信息

构建 DevOps 管道的注意事项


由于没有一个标准的 DevOps 管道,因此组织对 DevOps 管道的设计和实施取决于其技术堆栈、DevOps 工程师的经验水平、预算等。DevOps 工程师应对开发和运营有广泛了解,包括编码、基础架构管理、系统管理和 DevOps 工具链。

另外,每个组织都有可能会影响流程的不同技术堆栈。例如,如果您的代码库为 node.js,那么考虑因素将包括您是使用本地代理 npm 注册表,还是下载源代码并在管道的每个阶段运行“npm install”,亦或是只执行一次并生成在管道中移动的工件。或者,如果应用是基于容器的,则需要决定使用本地或远程容器注册表,只构建一次容器然后通过管道移动容器,还是在每个阶段重新构建容器。

DevOps 管道:提交、构建、单元测试、合并到主干、集成测试、预备、回归测试、部署。如果测试在任一阶段失败,管道都会停止,并向开发人员提供反馈。

尽管每个管道都是独一无二的,但大多数组织都使用类似的基本组件。在进入管道的下一阶段之前,需对每一步的成功与否进行评估。如果失败,管道将停止,并向开发人员提供反馈。

DevOps 管道的组件


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

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

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

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

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

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

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

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

2. 持续反馈

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

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

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

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

3. 持续运营

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

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

总之...


DevOps 旨在简化软件开发、部署和运营。DevOps 管道是在实践中实现这些想法的方式,从代码集成到应用运营,一切都具有持续性。

要了解有关持续交付的更多信息,请查阅我们关于使用 Bitbucket 进行持续交付的教程,该教程允许您使用集成的 CI/CD 进行构建、测试和部署。这些教程将帮助初学者和专业人士使用 Bitbucket 实现持续交付。准备好开始了吗?免费开始使用 Bitbucket Pipelines

Tom Hall
Tom Hall

Tom Hall 是 DevOps 流程的倡导者和实践者,他热爱阅读,还是一名业余钢琴家。
过去 20 年,他获得了 Novell、EMC、VMware 和 AWS 的认证。2016 年,他在亚特兰大协助主办了 DevOpsDays,之后数年又在德克萨斯州奥斯汀协助主办了 DevOPSDays。


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

DevOps 学习路径

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up