CI/CD:随时可以部署到生产环境的软件


持续集成和持续交付采用自动化来确保新应用代码始终经过测试、安全且随时可用于部署,让团队可以适时交付到生产环境。

能够响应用户反馈并快速、安全地将新应用代码交付到生产环境,这是成功的云原生企业的标志性特点。持续集成(CI)和持续交付(CD)在这个过程中扮演着重要角色,让团队可以大幅提高测试新应用代码并使之做好生产部署准备的速度。不过,为了充分发挥CI/CD的价值,团队必须做好准备摒弃一些陈旧的行事方式并采用新的开发方法。


什么是CI/CD?

CI/CD包含两个独立而又互补的部分。

持续集成是指在应用代码的新组件集成到共享存储库之后自动测试和构建软件的流程。这样一来,就可以打造出始终处于工作状态的应用“版本”。持续集成流程中纳入了单元测试,因而可以验证软件的功能。这样可以提前识别错误,并避免反馈回路后期的周期浪费。 持续交付是指将CI流程中创建的应用交付到类似生产环境的过程,在该过程中将对应用进行额外的自动化测试,以确保应用在部署到生产环境以及交付到真实用户手中时能够发挥预期作用。这样还可以确保最新构建版本能够以预期方式与其他软件和应用交互。成功的CD意味着,无论是通过自动化(一种称为持续部署的相关流程)还是cf push之类的手动流程,构建版本都随时可以部署到生产环境。


CI/CD的重要意义

基于业务要求按需部署软件

采用CI/CD的团队只需几分钟即可将新应用代码部署到生产环境,并且可以在最符合业务需求的时候而不是按照预定的发布时间进行部署。

降低软件在生产环境中无法正常运行的风险

采用CI/CD,代码在交付之前会经过严密的自动化测试,从而大幅降低错误或问题代码进入生产环境的风险。

实现根据客户反馈进行快速迭代

CI/CD优化了敏捷方法和DevOps,它可以提供必要的功能,将向用户持续学习所得的经验付诸实践,使团队能够以小批量快速迭代和交付软件。

加快发生故障时的恢复速度

如果生产环境中发生故障(这种情况极少发生),CI/CD可以快速找出错误代码并将修复程序推送到生产环境,让团队能够缩短平均恢复时间(MTTR),从而最大限度减少对最终用户的影响。



主要差异:CI/CD对比传统开发
CI/CD
传统开发
基于频繁的用户反馈,以小工作块的形式进行迭代式软件开发。 以大型复杂单元的形式进行软件开发,且用户反馈不太及时。
在开发流程进行期间编写和应用测试,以确保交付优质的应用代码。 在开发流程完成后,将软件测试完全交由QA团队处理。
通过自动化快速部署安全补丁和错误修复。 不定期批量提供安全补丁和错误修复,或通过手动例外流程随时提供。
新应用代码频繁与现有代码库集成并在真实场景中进行测试,从而确保软件始终做好部署到生产环境的准备。 新代码与现有软件集成的频率较低,通常只在预定发布时间进行的部署之前集成。


正在考虑采用CI/CD?需要注意的事项

CI/CD能够帮助团队更快速地交付高质量的软件和应用,但也需要团队改变开发工作流程并采用新的最佳实践。如果您正在考虑采用CI/CD,请先考虑以下要求:


打破孤立团队模式

采用CI/CD后,应用代码问题不会再一股脑丢给QA人员,因为测试会成为开发流程(亦称DevOps)的一部分。您无需再依靠单独的工程师小组来测试新代码,这个责任将落在开发团队的肩上。这要求您打破孤岛模式,让QA工程师与开发人员、设计人员和项目经理一同组成均衡的开发团队。

开发人员必须负责编写更多测试

这样一来,为了获得成功,开发团队必须努力编写更多测试(例如单元测试和端到端测试)来模拟流经应用的用户流。这可能会导致开发周期延长,但对测试的前期投资可以让您对构建自动化充满信心。

团队必须采用新工具和自动化

尽管CI/CD的成功在很大程度上依赖于组织和流程的变更,但工具和技术元素的作用也不容忽视。团队必须同意并切实采用新工具以便开发、实施和监控自动化CI/CD管道与测试。这意味着采用新的测试框架(如JUnit)、现代化源代码存储库、工件存储库和持续交付工具(如Concourse)。

必须重新思考旧版审批流程。

在传统环境中,向生产环境交付新软件可能需要成功完成一个或多个手动审批流程。例如,有些企业要求新软件获得变更顾问委员会的认可,而这可能会使针对生产环境准备软件的过程延长数天时间。企业需要重新评估这些可能产生瓶颈的手动审批流程,并将其替换为符合CI/CD要求的自动化流程。




下一部分
观点