DevOps实践总结，涵盖CI/CD、自动化部署流水线等核心概念及实践要点，助力快速、频繁的软件交付。
原文标题：Devops的一些总结
原文作者：牧羊人的方向
冷月清谈：
DevOps的知识体系包括规范敏捷、持续交付和IT服务管理三大支柱，并以精益理念为基础。它涵盖了应用和服务生命周期管理、项目章程和可视化控制、基础设施和架构设计等方面。
在DevOps的开发和部署阶段，持续集成、持续交付和持续部署是关键环节。持续集成强调频繁地将代码集成到主干并进行自动化测试；持续交付致力于保持主干始终处于可部署状态；持续部署则通过自动化手段将软件频繁地交付到生产环境。
文章还介绍了蓝绿部署、金丝雀发布等部署策略，以及部署流水线的概念和基本流程。部署流水线涵盖了提交、自动化验收测试、手工测试和发布等阶段，实现了软件交付过程的自动化。
最后，文章指出DevOps的实施需要结合企业的组织、技术、流程和文化，并强调了在DevOps平台建设中，自动化部署、工具链集成以及与现有企业流程的结合是实现CI/CD部署流水线的关键。
怜星夜思：
2、文章中提到了蓝绿部署和金丝雀发布两种部署策略，它们各自有哪些优缺点？在什么场景下更适合选择哪种策略？
3、除了文章中提到的实践，您认为还有哪些关键因素能够促进DevOps的成功落地？
原文内容
前段时间参加了Devops Master培训，本文对Devops培训内容进行简要的总结回顾，以加深对CI/CD持续交付和持续部署整个流程的理解。
1、Devops是什么？
Devops是开发和运维的缩写，它是一组最佳实践，强调IT专业人员在应用和服务生命周期中的沟通和协作。Devops强调整个组织的合作以及交付和基础设施变更的自动化，从而实现持续集成、持续交付和持续部署。Devops不能简单的认为是一种工具、方法、技能和组织架构，Devops的框架是结合所有这些元素来建立一个流水线的过程，使业务能够更快的运营，并且应对变化。
Devops的目标是建立一种文化和环境，在这种文化和环境中，建立流水线式的及时制的业务流程，构建、测试和发布软件和服务可以快速、频繁的发生，并且只需要很少的支持，就可以实现业务增长和客户满意度。
2、Devops的知识体系
-
规范敏捷：意味着IT服务要以更频繁、更快速的发布周期来响应业务变化，使用到的方法有SCRUM方法和精益看板
-
持续交付：应用程序的构建、部署、测试和发布流程的自动化实施，从而能够构建端到端的自动化持续交付流水线
-
IT服务管理ITSM：IT服务的连续性和高可用性是业务存亡的关键因素，基于Devops的ITSM服务管理需要严格聚焦于业务连续性的轻量级的ITSM
-
以精益理念（TPS）为基础：TPS的概念包括JIT和自动化，JIT意味着以单件流的方式建立流水线式的供应链，而自动化意味着整个流程过程中的自动化
3、Devops规划需求和设计
应用程序生命周期管理聚焦在应用的开发阶段，应用的运维和维护是一个输出服务的循环过程，这个过程基于应用的生命周期。服务的生命周期管理是在应用的开发阶段，聚焦于服务交付的准备，服务交付有其自身的生命周期—战略、设计、转换、运营和持续改进。
Devops项目中服务经理会定义项目的范围，参与业务规划以了解业务目标，创建项目的愿景、目标和价值，然后将Devops团队成员组建在一起。Devops项目中的可视化控制有利于Devops实践，支持快速查看进度和识别问题。常见的可视化方法如Obeya作战室，建立价值流图分析，识别部署流水线工作流，计算部署流水线的处理时间、流动时间流动效率以及综合C/A（完整并准确的比率）。
Devops项目中基础设施的管理是一个自动化的过程，使用Ansible等自动化运维工具实现基础设施的自动化准备和自治性维护。基础设施即代码是使用一种新的技术来构建和管理动态基础设施的方式。在基础设施的架构设计中通过云计算和虚拟化技术，可以减少部署的时间，实现快速扩展，并形成标准化的堆栈，无需担心测试和生产环境配置和维护上的差异。
4、Devops开发和部署
持续集成是指在软件开发过程中，频繁地将代码集成到主干上，然后进行自动化测试。持续集成要求每当有人提交代码的时候，就对整个应用进行构建，并对其执行全面的自动化测试集合。假如构建或测试过程失败，开发团队需要立即修复，持续集成的目标是让正在开发的软件一直处于可工作的状态。
持续交付是指所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态。开发人员在引入任何回归错误时候，都能快速得到反馈，一旦发现问题，就立即加以解决，从而保持主干始终处于可部署的状态。持续交付有三种基本分支模型：
1）“主干开发，主干发布”
只需要对主干分支做继续集成，只需要一个持续集成服务，关注主干分支的代码变更即可
2）“主干开发，分支发布”
团队每当准备发布时应该创建新的发布分支，并为这个发布分支创建对应的部署流水线
3） “分支开发，主干发布”
需要为每个开发分支架设一条对应的部署流水线，并且每当有分支向主干合入代码时，立即出发主干对应的部署流水线；当分支上的代码提交不再活跃，或者分支直接被删除后，其对应的部署流水线也可以被删除
持续部署是通过自动化部署的手段将软件功能频繁的进行交付，在持续交付的基础上，把部署到生产环境的过程自动化。对比图中持续交付和持续部署就可以发现持续部署最终部署到生产环境是自动化的。
在实践中，通常交替使用“部署”和“发布”这两个词，其中部署是指在特定环境中安装指定版本的软件，发布是把某个特性提供给客户。根据不同的发布策略，将部署与发布解耦，有以下几种发布策略：
-
蓝绿部署
蓝绿部署是两个集群A和B，正常情况下集群A和集群B的代码版本是一致的，并对外提供服务。在系统升级的时候，把集群A从负载列表中摘除，进行新版本的部署，集群B继续提供服务。当集群B升级完毕后，再把负载指向集群A并把集群B从列表中摘除，并对集群B升级新版本。当集群B升级完成后，再加到负载列表中，这个时候两个集群都升级到新版本，并且服务没有中断过。蓝绿部署的优势是同一时间对外服务的只有一个版本，容易定位问题，升级和回滚以集群为粒度，操作相对简单。不过需要维护两个集群，成本较高。
-
金丝雀发布（灰度发布）
-
不停止老版本，额外搞一套新版本，不同版本应用共存。
-
灰度发布中，常常按照用户设置路由权重，例如百分之九十的用户维持使用老版本，百分之十的用户尝鲜新版本。
-
经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来
《持续交付》提出了“部署流水线”的概念， 从某种抽象层次上讲，部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。基本的部署流水线如图所示：
-
提交阶段是从技术角度上断言整个系统是可以工作的，这个阶段会进行编译、运行一套自动化测试并进行代码分析
-
自动化验收测试阶段是从功能和非功能角度上断言整个系统是可以工作的，即从系统行为上看满足用户的需要并且符合客户的需求规范
-
手工测试阶段用于断言系统是可用的，试图发现自动化测试未能捕获的缺陷，并验证系统是否为用户提供了价值。这一阶段通常包括探索性测试、集成环境上的测试以及UAT用户验收测试
-
发布阶段是指将软件交付给用户，既可以是套装软件的形式、也可能直接将其部署到生产环境或试运行环境
5、总结
DevOps 的实施和企业的组织、技术、流程、文化紧密结合，在企业中，技术方面的实践最容易在团队中实践，流程次之，组织的优化与变革则是最为困难的。在建设DevOps平台中，如何实现异构环境和应用自动化部署、如何打通工具链的集成、如何和现有企业流程紧密结合，才能实现真正意义上的CI/CD部署流水线。
参考资料
-
Devops Master高级培训，许峰
-
持续交付2.0，乔梁
-
https://blog.csdn.net/qq_35368183/article/details/84558134
-
https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/
-
http://blog.itpub.net/28624388/viewspace-2158717/