华为云DevOps系列之 —— 持续部署与发布（一）持续交付与持续部署

前言 - 一个 ATM 取款系统

• 技术实现
  • ATM机：机械系统控制，智能卡识别，接收用户输入，连接银行系统，监控等等
  • 传输层网络：数据加密，数据完整性，监控
  • 核心银行系统：账户认证，账务信息，审计，风控等等
  • …
• 挑战
  • 紧耦合，系统复杂、错综加护，牵一发而动全身，研发难度大
  • 业务规模大，团队人员多，管理协作成本高

软件交付的挑战

从上面提到的 ATM 机取款的案例，我们可以发现目前软件交付的几个困难点

• 协作成本高，业务响应慢。在传统架构中，一般公司内部都会按照功能模块划分工作，每一次新版本上线总会出现各种问题，例如分支、合并、冲突、代码不一致等带来很大的协作成本、沟通成本
• 系统复杂度增加，难以维护。随着业务量不断的增加和扩展，以及随着组织人员的变化，业务代码也会变得越来越难以维护，一次小小的改动可能会带来灾难性的风险
• 错误不能隔离。当所有的业务功能模块都聚集在一个程序集当中的时候，如果其中一个小的功能模块出现问题，那么都有可能会造成整个系统的崩溃，这就是软件开发中常说的 涟漪效应。被影响的系统如果较为复杂还可能会造成 二次涟漪效应
• 应用扩展能力差。传统架构不能够按需扩展。例如，某一天我们网站中某个模块访问量暴增，如果我们要对服务扩展，只能把整个系统进行打包，发布，而不能针对特定的模块进行扩容

系统耦合的三个级别

• 大家对 耦合 这个词已经耳熟能详，高内聚低耦合，它已经成为软件设计质量的标准之一
• 耦合就是对某元素与其他元素之间的连接、感知和依赖的量度，这里所说的元素既可以是功能对象也可以指系统、子系统、模块。例如，假如一个元素 A 和元素 B，当 B 不存在的时候，A 就不能正常工作，那么就说元素 A 与元素 B 耦合。耦合带来的问题是，当元素 B 发生变更或不存在时，都将影响元素 A 的正常工作，影响系统的可维护性和易变更性，同时元素 A 只能工作于元素 B 存在的环境中，这也降低了元素 A 的可复用性。正因为耦合有种种弊端，我们在软件设计的时候才努力追求 低耦合
• 耦合的级别分类
  • 代码级耦合：常见于 单体架构项目 中，这种项目往往模块非常多，且模块的边界模糊，依赖关系不清晰，代码质量参差不齐，整个项目非常复杂
  • 组件级耦合：将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，一个独立的组件可以是一个软件包、外部服务、外部资源，或者是封装了一些函数的模块，这样独立出来的组件可以单独维护和升级，而不会影响到其他的组件。组件级耦合时多团队协作成为可能，不过组件级耦合的缺陷也较为明显：接口定义不通用，无法跨技术栈使用
  • 服务级耦合：也就是我们常说的微服务，它通过将功能分散到各个离散的服务中，以实现对解决方案的解耦，通过服务级耦合，多团队多技术栈协作成为可能
    

• 随着耦合级别的提高，团队自由度、业务敏捷能力、交付速度及质量都得到了很大的提高
• 但是相应的，随着自治服务的增多，系统的复杂度和运维复杂度也直线上升

通过微服务容器化实现架构工程解耦

• 简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发、独立部署、独立测试、独立运行的一组小的应用，并且使用轻量级通用的机制，在这组应用间进行通信
• 微服务的特点是 小而独立，轻量级通讯
  • 正是因为小，每个微服务的逻辑相对简单，代码量也小很多，进而修复问题及修改更变会快很多
  • 因为独立，每个微服务都可以单独进行修改、测试、部署，使多个微服务可以并行演进，从而可以缩短测试部署和发布的时间
  • 同样因为独立，立每个微服务都可以根据实际情况单独的 横向拓展，贯彻高内聚低耦合的架构思想

通过自动化实现软件快速部署和发布

• 以往在单体应用架构时，开发只需要整体打包成一个服务交给测试去做自动化测试，交给运维去部署发布就可以了。但是微服务架构下，一个单体应用，被拆分成了多个细小的微服务，并且需要独自开发，测试和上线，如果继续按照之前的单体应用模式运维，那么测试和运维的工作量都相当于成倍地增加，因此需要对以往的开发、运维、测试模式进行升级
• 通过自动化的方式实现持续集成与持续交付。如果开发的功能服务相对独立，那么就能越快实现持续集成与交付，使业务得到尽快的部署与发布。那么微服务能够帮助我们更好的进行持续交付
  

持续交付概念

• 持续交付（Continuous Delivery，CD），持续交付以持续集成为基础，将集成后的代码部署到更贴近真实运行环境的类生产环境中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上
• 如果说等到所有东西都完成了，才向下个环节交付，导致所有的问题只能在最后才爆发出来，这样会导致解决成本巨大，甚至无法解决。比如我们完成单元测试后，可以把代码部署到连接数据库的staging环境中，进行更多的自动化测试，试如果代码没有问题，可
  以继续手动部署到生产环境中
• 当然，持续交付不是指软件每一个改动都要尽快部署到生
  产环境中，它指的是 任何的代码修改都可以在任何时候实施部署
  

持续交付主流工具

持续部署的生命周期

• 持续交付、持续部署与 DevOps 的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps 的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付、部署、运维的过程 自动化。另一方面，持续交付、持续部署是一种 自动化的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程
• DevOps 可以说是三个持续的一个产物，持续交付和持续部署直接汇入 DevOps

CI、CD & CD

持续集成与持续交付

• 持续集成（Continues Integration，CI），指的是频繁地(一天多次)将代码集成到主干

  • 目的：让产品可以快速迭代，同时还能保持高质量
  • 核心措施：代码集成到主干之前，必须通过自动化测试试。只要有一个测试用例失败，就不能集成
  • 持续集成并不能消除 Bug，而是让它们非常容易发现和改正 Bug
    

• 持续交付（Continuous Delivery，CD），指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的
  

持续部署

• 持续部署（Continuous Deployment，CD），是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署的目标是：代码在任何时刻都是可部署的，可以进入生产阶段
  

持续部署与持续交付的关系

• 持续部署与持续交付
  • 持续部署意味着所有的变更都会被自动部署到生产环境中
  • 持续交付意味着所有的变更都可以被部署到生产环境中
  • 出于业务考虑，可以选择不部署
  • 如果要实施持续部署，必须先实施持续交付
  • 持续部署不适合交付软件的公司，适合交付服务的公司
    

“持续部署并不意味着每一次变化都要尽快部署到生产环境中，而是意味着每一次变化都是随时可以部署的” ——Carl Caum

持续部署流水线衔接开发与生产

持续部署工具链全景图

• 通过项目管理工具进行敏捷项目管理，将需求下发
• 团队成员接到需求后，通过 IDE 进行应用代码、测试代码、部署脚本、环境配置文件的编写，完成后，推送到代码仓库，自动触发持续集成服务
• 通过构建工具进行单元测试，构建打包，并将成果物上传镜像仓、发布仓等进行版本管理
• 测试无误后，通过部署流水线进行各类环境的配置、部署，并通过后台运维管理工具进行管理、检测，然后通过数据上报和采集功能进行运营数据的分析，并提交新的需求给产品，形成一个闭环

思考题
（多选）关于持续集成、持续部署和持续交付的说法，以下哪些是正确的（）？

• A. 持续交付以及持续部署等概念的核心：将技术行为与业务决策解耦
• B. 持续交付是指，所有开发人员都在主干上进行开发工作，在需要发布时直接发布
• C. 持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本
• D. 持续集成，要求每个开发人员提交了新代码之后，就对整个应用进行构建，并对其执行全面的自动化测试集合
   

答案：ACD

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊