CICD与DevOps
软件开发生命周期
- 软件开发生命周期
- Software Development Life Cycle，简称为SDLC帮助人们组织和实施软件开发管理的框架，有助于定义系统工程师和开发人员在软件开发和维护工作中的工作阶段
- 由多个阶段组成，大致包括需求收集、可行性研究、设计、编码、测试、部署和维护等
- SDLC模型
- Waterfall
- Iterative Development
- Agile
- Lean Software Development
- DevOps
- Spiral Development
- V-Model Development
瀑布模型
关于瀑布模型
瀑布模型中的开发过程是线性的，所有阶段界限分明且逐个完成，就像瀑布一样，开发的进度由上而下流动
瀑布是软件开发史上第一个、最简单、也是最好的SDLC方法之一
适用场景
- 复杂领域的项目（例如飞机制造、医疗），法规和要求相对稳定
- 要求明确，有严格的截止蜞，有固定的成本
但是
- 瀑布模型不允许返回到以前的开发阶段来纠正或实施更改
- 做到这一点的唯一方法是在下一个Waterfall迭代过程中进行
迭代/增量模型
关于迭代增量模型
先以相对较低的价格快速创建产品版本，然后通过快速和连续的迭代过程对其进行测试和增强
每次迭代都会生成更新、更可靠的版本；一般需要历经多次迭代，直到最终软件版本成型
典型特征：人们可以在未完全了解需求的情况即启动开发过程
适用场景
- ERP系统等复杂项目
- 需要已明确定义，项目的目标已经确定，但未来可能会有细微的变化
敏捷模型
关于敏捷模型
敏捷模型结合了增量和迭代方法，旨在更好地适应灵活的应用需求进行软件开发
在软件开发的敏捷方法中，项目被分成小的子部分并在迭代中交付
- 在每次迭代结束时，都会提供一个版本供客户审查和反馈
- 对每个版本的测试都提供了有价值的信息，这些信息可能会被合并到下一个版本中
存在多种流行的实践方法
- Scrum
- SAFe
- Extreme Programming (XP)
- Kanban
敏捷模型发布速度不一 有的时候甚至半天一个发布 这对运维稳定性的打击是巨大的
解决办法是协商发布时间 例如在每周日晚上发布一次 但是这又对开发团队很难受
然后就产生了DevOps
DevOps模型
关于DevOps模型
DevOps产生的背景：传统SDLC的团队模型
- 大型IT组织中传统上存在完全不同的几个团队——产品设计、开发、测试、运维
- 每个岗位都有自己的价值追求，测试人员关注找出更多 Bug、开发人员关注技术和高效开发功能、运维关心系统稳定
- 结果：分工带来的好处，就是复杂的任务可以分给不同的人来做，这也有助于技能的专业化，提高工作效率；但如果只站在自己的立场去考虑问题，没有人关注整体价值，就容易相互误解，产生矛盾、增加成本
DevOps模型
- 在竞争日益激烈的环境中改善客户体验和底线结果的压力越来越大，持续交付成为大势所趋
- DevOps旨在将几个需要协同但目标不同的团队完全聚集在一起，让每个团队都可以通过共同实现目标而更加成功
DevOps组织优先推动的目标
- 一组标准化的环境
- 降低新版本的失败率
- 缩短版本之间的交付时间
- 更快的平均版本恢复时间
开发人员-测试-交付给运维 完成自动化------持续交付 全自动化上线部署 自动化 ----持续部署
开发人员-测试 自动化实现-----持续集成
DevOps的好处
采用DevOps模型的团队能够增加交付周期，以更快的速度创建新功能，同时推动创新并增加员工参与度和沟通，最终，也确保了应用程序更加安全和稳定
利用DevOps并实施持续集成和持续交付 (CI/CD)，组织可以看到部署频率、交付周期、网络安全漏洞和缺陷检测、平均修复时间和平均恢复时间方面的巨大改进
允许快速实验和不确定性，同时专注于任务最终目标
支持快速原型设计和 A/B 测试或金丝雀发布
得益于自动化测试和实时扫描，通过不断修复错误和安全问题来避免技术债务
DevOps的关键指标
- 平均恢复时间：Mean-time to recovery (MTTR)
- 平均投产时间：Mean-time to production
- 平均提前时间：Average lead-time
- 部署速度：Deployment speed
- 部署频率：Deployment frequency
- 生产失败率：Production failure rate
DevOps与CICD的联系与区别
- CICD是软件工程实践的方法
- DevOps是一种文化：也正是容器、容器编排、微服务等技术使得DevOps最终能够以应有的方式得以落地；
- 通常， 在开发环境中自动化持续集成和持续交付（CI / CD）是DevOps团队的最终目标
持续交付和持续部署
持续交付
- 通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如GitHub或Image Registry）然后由运维团队将其部署到实时生产环境中
- 旨在解决开发和运维团队之间可见性及沟通较差的问题，目标在于确保尽可能地减少部署新代码时所需的工作量
持续部署
- 通常是指自动将开发人员的更改从存储库发布到生产环境，以供客户使用；
- 主要解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题
- 以持续交付为前提，完成Pipeline后续阶段的自动化
CI/CD术语
- 通常，CI/CD这一术语既可能仅指持续集成和持续交付构成的关联环节，也可以指持续集成、持续交付和持续部署这三项构成的关联环
- 甚至于，很可能有些人口中所谓的"持续交付"也包含了持续部署流程
CICD Pipeline
CI: 持续集成，用于实现开发工作的流程自动化
CD：持续交付/持续部署，前者常用于描述在自动化的CI流程之后，自动将已验证的代码发布到存储库中（而后流程转移至运维团队），后者则指的是自动将开发人员提交的代码变更部署到生产环境中，以提供给客户使用；
开发人员每做一个很小的功能都要拿过来去构建 对接 看看能不能对接上去 这个过程就叫持续集成
到生产是一个CD 但是交付也是一个CD 交付需要成品库 各种仓库
CICD中的典型阶段
再看CI/CD
CI/CD是一种在应用开发阶段引入自动化实现以较高频度向客户交付应用的方法
- 广为接受的模型，存在三个典型阶段：持续集成、持续交付和持续部署
- CI/CD可以让持续自动化和持续监控贯穿于应用的整个生命周期（从集成到测试、到交付，再到部署）
- 这些关联的事务通常被统一称作CI/CD Pipeline，它一般需要由开发和运维团队以敏捷方式协同支持
CI和CD的关系
- CI是指持续集成，它属于开发人员的自动化流程
- CD指持续交付和持续部署，两者都事关Pipeline后续的自动化，但有时也会单独使用以评估自动化程度
CI/CD Pipeline
为了交付新版本的软件而必须执行的一系列步骤
一套专注于使用DevOps或SRE方法来改进软件交付的实践
加入了监控和自动化来改进应用开发过程，尤其是在集成和测试阶段，以及交付和部署过程中
- 即便可以手动执行CI/CD Pipeline的每个步骤，但CI/CD Pipeline的真正价值就在于自动化
CI/CD Pipeline的要素
构成CI/CD Pipeline的步骤被划分为不同的任务子集（subsets of tasks），称之为Pipeline Stage
Pipeline中典型的Stage包括
- Build（构建）：应用编译
- Test（测试）：代码测试
- Release（发布）：将应用交付到存储库
- Deploy（部署）：将代码部署到生产环境
- Validation和Compliance（验证与合规）：镜像安全性扫描（例如Clair）等，具体的步骤取决于实际需求
最初，传统的CI/CD系统是为使用虚拟机的Pipeline而设计，但云原生技术却为CI/CD Pipeline的价值实现带来了新的突破
- 使用Tekton项目，用户可以构建Kubernetes风格的Pipeline，控制微服务的生命周期
Simple Version of CICD Workflow
CICD简单工作流程中的6个步骤
Commit Change：开发人员提交代码至代码仓库中;
Build Binary：CI Server针对最新的变更构建应用程序；
Deploy UAT：CI Server将二进制程序部署到UAT环境中；
Test UAT：在UAT环境中针对测试计划完成测试；
Deploy PROD：CI Server将二进制程度部署到PROD环境中；
Test PROD：在PROD环境中针对测试计划完成测试
自动化的CICD工作流示例
多分支Release流水线示意图
DevOps方法示例一
CI/CD Pipeline Workflow with Kubernetes (Push Pipeline)
DevOps方法示例二
CI/CD With Kubernetes and Helm (Push Pipeline)
Weave Cloud的DevOps方法
Weave Cloud的DevOps方法使用Pull机制，它依赖于两种特殊组件
Config Updater：用于监视image的变动并更新配置清单；
Deploy Synchronizer：维护应用的当前状态；
工作机制：Pull Pipeline模型的中心是配置中心或配置仓库（config repo）
开发人员推送代码变更至代码仓库中；
CI Server 自动完成CI Pipeline并生成Docker Image；
Config Updater，注意到Image的变动，并以此更新config repo中的配置清单；
Deploy Synchronizer 在察觉到集群当前状态已过期后，将从配置仓库中pull到变更的配置清单并部署到集群上；
Pipeline 模型的演进
Push Pipeline
传统上的大多数CI/CD工具都使用基于Push的模型，即代码从CI系统开始，可以经由一系列脚本代码自动化完成其执行路径，或手动完成相关的Stage；
Pull Pipeline
WeaveNet倡导一种新的基于Image Pull的Pipeline模型，并且将凭据直接保存于集群之上
一个典型的GitOps Pipeline
GitOps模型中存在两个Git仓库
- 代码仓库（code repo）：开发人员使用
- 推送代码变更
- 配置仓库（config repo）：运维人员使用
- 推送配置变更
- 包括基础设施配置以及应用配置
简要工作流程
- 开发人员推送代码变量至代码仓库
- CI工具链完成测试和构建
- CD工具链完成测试和交付（新版本的Image推送至工件仓库)
- Config Update（即Deployment Automator）将Image的变更信息推送至配置仓库
- 随后，根据使用的分支和发布策略，完成应用的部署
