根据IDC最近的一项研究，全球DevOps软件市场在2017年达到29亿美元，预计到2022年将达到66亿美元。随着去年超过50%的组织采用DevOps，
持续集成(CI)和持续交付(CD)已经成为软件开发过程中不可或缺的一部分。PlusMode · 使用可视化工具快速构建应用程序 基于大数据与拖拽式产品工具自动关联项目组件，并帮助项目快速落地
APICloud企业IT敏捷项目管理工具
APICloud需求分析工具
本文，我们将重点讨论CI / CD最佳实践，无论企业正在处于DevOps的哪个阶段，这些实践都有助于加速DevOps采用。
从最初的瀑布模型，到后来的敏捷开发，再到今天的 DevOps， 这是现代开发人员构建出色产品的技术路线。随着 DevOps 的兴起，出现了持续集成，持续交付（CI/CD）和持续部署的新方法， 而传统的软件开发和交付方式在迅速变得过时。过去的敏捷时代里， 大多数公司的软件发布周期是每月、每季度甚至每年， 而在现在 DevOps 时代，每周、每天甚至每天多次都是常态。
我们为什么要实践DevOps？持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次， 主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
持续交付的目的是最小化部署或发布过程中团队固有的摩擦，它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。 持续部署是一种更高程度的自动化，无论何时代码有较大改动， 都会自动进行构建／部署。持续集成和持续交付是指在以自动化为基础的构建-配置-部署-测试-发布的短周期内开发和交付软件的过程。简而言之，我们使用CI/CD来高频且可预测地交付更高质量的软件。
持续集成（CI）在软件开发中已经无处不在。因此，作为开发的基础，CI成为DevOps组织中的关键实践不足为奇。通过持续集成，开发人员能够频繁地将其代码集成到公共代码仓库的主分支中。开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。通过让开发人员更快、更频繁的做到这一点，从而降低了集成的开销。在实际情况中，开发人员在集成时经常会发现新代码和已有代码存在冲突。如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。
持续部署（CD）实际上是 CI 的扩展，将软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。在这样的流程中， 不需要人为决定何时及如何投入生产环境。CD从CI的开发、构建、单元测试、静态代码分析(SCA)和静态分析安全测试(SAST)开始。最终，软件交付流程将自动化扩展到功能、集成、性能和安全测试，以及配置管理和部署。这些是自动化的关键要素，在DevOps环境中，它们是必不可少的。我们甚至可以说，如果不做持续部署（CD），那么你就做不好DevOps。为什么？采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。 用户对无用或者误解需求的功能的快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。企业不会在一夜之间完成DevOps转变，这是一个持续改进的过程，当你掌握了一个最佳实践的时候，还会有新的实践出现，我们目标是更好的交付软件。DevOps 8个CI/CD最佳实践
1、采取“安全第一”的方法在一个漏洞和脆弱性持续给各种规模和能力的企业造成巨大声誉和财务损失的世界里，再怎么强调安全的必要性都不为过。
由于CI / CD系统可以访问代码库和凭据以在各种环境中进行部署，因此它通常会被作为主要目标。回想一下臭名昭著的优步入侵事件，黑客侵入了嵌入在GitHub软件库中的AWS凭证，窃取了5700万用户和60万司机的个人信息。
为了实现自动化的目的，将凭证存储在私有存储库中当然并不少见。因此，我们需要考虑隔离CI / CD系统，并将其放置在安全的内部网络中。强大的双因素身份验证、身份和访问管理系统将帮助您执行最小特权原则，并限制暴露于威胁。例如，将代理容器化并将其放置在安全网络上。此外，我们还应该确保从开始到结束都将安全性考虑到开发过程中。这通常被称为DevSecOps。
2、评估企业微服务架构
为了有效地实现DevOps，微服务架构是最好的方法。然而，重新架构现有应用程序可能是一项艰巨的任务，可以考虑使用增量方法来维护任务关键型系统，并围绕其构建新架构。这将有助于逐步用新的体系结构替换旧的系统。
3、执行跟踪和版本控制工具
像Jira和Bugzilla这样的工具可以帮助您更好地了解软件的进展，并轻松地与分布式团队协作。像Git这样的版本控制系统，它可以为团队创建“单一事实来源”，允许跟踪代码库中的更改，并且在需要回滚时提供帮助。通过允许团队协作并将更改集成到共享存储库中，GitOps可以显著提高MTTR。
4、每日提交，避免分歧
减少分歧的目标是花更多的时间在开发上，花更少的时间在版本控制上。然而，要充分利用GitOps，开发人员应至少每天一次直接提交到主分支或合并其本地分支中的更改。这将迫使开发人员处理更小，更小规模的集成难题，而不是在发布前将许多分支合并到主干中时发生的大规模集成难题（以及相关的返工）。
5、只生成一次
消除重复构建源代码的做法，即使必须构建、打包或捆绑软件，也应该只执行一次该步骤并升级二进制文件。大多数成功的CI实施都将构建过程作为CI / CD循环的第一步，以将软件打包在干净的环境中。这消除了疏忽，并减少了以后随时引入或遗漏错误的机会。此外，每次都应对生成的工件进行版本控制并将其上载到Git，这样无论何时提取它，构建都不会发生变化。
6、确定首先自动化哪些流程和测试
尽管采用渐进式自动化方法听起来不错，但是从手动过程过渡到自动化过程的组织经常发现很难决定首先自动化哪些过程。例如，首先将编译代码的过程自动化是有益的。由于开发人员需要每天提交代码，所以进行自动冒烟测试是有意义的。单元测试通常首先自动化，以减少开发人员的工作量。
因此，可以自动化功能测试，然后是UI测试。功能测试通常不需要在自动化脚本中频繁更新，不像UI测试需要频繁更改。其主要思想是考虑所有可能的依赖关系，并评估它们的影响，，以合理地确定自动化的优先级。
7、经常释放
频繁的发布只有在软件处于准备发布状态并且已经在类似生产的环境中测试过它的情况下才可能。这就是为什么最佳实践是在发布之前添加一个与生产环境非常相似的部署阶段。一些发布最佳实践包括：
- 金丝雀的部署：发布给一个用户子集，在这个基础上进行测试，如果成功，就将其推广到更广泛的人群中(如果失败，就将其撤回到迭代中)。
- 蓝绿色部署：从两个相同的生产环境开始，一个是现场生产，另一个空闲。当推出新版本时，更改将被推到空闲环境中。然后，他们将包含新版本的环境切换为实时环境。如果出现错误，、可以立即回滚到另一个环境(不包含新版本的环境)。如果一切顺利，环境将再次趋于平等。
- A / B测试:A/B测试在风格上与蓝绿色部署类似，但不要与之混淆。A/B测试是一种测试应用程序内部特性的方法，比如可用性。性能更好的胜出。
8、使用按需测试环境应该考虑在容器中运行测试，因为这种方法允许质量保证团队减少开发和生产环境之间的环境变量和变化。使用这种测试环境的主要优点是它们为CI/CD周期增加了敏捷性。QA团队不需要从CI服务器提取构建版本，并将其安装到单独的测试环境中;相反，它可以针对容器映像运行测试。启动容器(它们没有单独的安装或配置要求)和在不需要时销毁它们要容易得多。DevOps或CI/CD最佳实践的主要目标是自动化构建、测试和发布软件的过程。这意味着我们将需要使用DevOps工具，这些工具可帮助简化自动化并更好地了解软件的进度。此外，应该有一种机制来跟踪DevOps在整个软件交付生命周期中的性能指标，并在发布或部署中出现错误时发出警报，以便快速恢复。
