DevOps理念

一、软件开发生命周期（SDLC）

（一）概述

Software Development Life Cycle（SDLC）是组织和实施软件开发管理的框架，定义系统工程师和开发人员在软件开发和维护中的工作阶段，主要包括需求收集、可行性研究、设计、编码、测试、部署和维护等环节。

（二）主要SDLC模型

1. 瀑布模型（Waterfall）

   1. 开发过程线性，所有阶段界限分明且逐个完成，如同瀑布自上而下流动。

   2. 是软件开发史上第一个、最简单且优秀的SDLC方法之一。

   3. 适用场景：复杂领域项目（如飞机制造、医疗）、法规和要求相对稳定、需求明确、有严格截止日期和固定成本的项目。

   4. 缺点：不允许返回到以前的开发阶段纠正或实施更改，只能在下一个迭代中进行。

   5. 流程：System engineering → Analysis → Design → Code → Testing → Maintenance

2. 迭代/增量模型（Iterative Development）

   1. 先以较低成本快速创建产品版本，再通过快速连续的迭代测试和增强。

   2. 每次迭代生成更新、更可靠的版本，需历经多次迭代至最终版本成型。

   3. 典型特征：可在未完全了解需求时启动开发。

   4. 适用场景：ERP系统等复杂项目，需求已明确定义、目标确定但未来可能有细微变化的项目。

   5. 流程：Initialization → Requirements → Planning → Design → Implementation → Verification → Evaluation → Deployment

3. 敏捷模型（Agile）

   1. 结合增量和迭代方法，适应灵活的应用需求。

   2. 项目分成小的子部分，在迭代中交付，每次迭代结束提供版本供客户审查和反馈，测试信息可融入下一个版本。

   3. 流行实践方法：Scrum、SAFe、Extreme Programming（XP）、Kanban。

   4. 流程：Requirement Analysis → Design Document & Prototype → Development → Testing → If some errors are there, return to previous steps → Next Iteration

4. DevOps模型

   1. 产生背景：传统SDLC中，产品设计、开发、测试、运维团队目标不同（测试人员关注找Bug、开发人员关注技术和高效开发功能、运维关心系统稳定），易产生矛盾、增加成本；竞争加剧下，持续交付成为大势所趋。

   2. 核心目标：将协同但目标不同的团队聚集，共同实现目标，推动标准化环境、降低新版本失败率、缩短交付时间、加快平均恢复时间。

   3. 好处：减少交付周期，更快创建新功能，推动创新，提升员工参与度和沟通，确保应用程序更安全稳定；通过CI/CD实现部署频率、交付周期等多方面改进；支持快速实验、原型设计和A/B测试；避免技术债务。

   4. 关键指标：平均投产时间（Mean-time to production）、平均提前时间（Average lead-time）、部署速度（Deployment speed）、部署频率（Deployment frequency）、生产失败率（Production failure rate）、平均恢复时间（Mean-time to recovery, MTTR）。

   5. 流程：PLAN → CODE → BUILD → TEST → RELEASE → DEPLOY → OPERATE → MONITOR

对比维度	传统开发模式（瀑布式）	DevOps模式
团队协作	开发、运维、测试割裂，沟通成本高	跨团队协同，共享责任，沟通高效
开发周期	周期长，迭代慢，难以快速响应需求	小步迭代，周期短，快速响应需求变化
部署频率	低，通常以周/月为单位，风险集中	高，通常以天/小时为单位，风险分散
问题修复	响应慢，需等待下一阶段，修复成本高	响应快，实时反馈，修复成本低
自动化程度	低，大量手动操作，易出错	高，全流程自动化，稳定性高
风险控制	后期暴露风险，难以提前预判	全流程持续监控，风险提前识别与控制

二、DevOps概念

基本概念

在如今互联网的格局下，抢占市场变得尤为重要，因此敏捷开发越来越被大家所推崇。于是，慢慢的有了DevOps这个概念，含义就是开发-运维一体化，能够理顺开发和运维之间相互配合关系的任何事物。

DevOps是一组过程、部署及开发系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

可以看到上图是一个无穷大的一个符号，Dev对应开发，Ops对应运维。

DevOps的方式可以让公司能够更快地应对更新和市场发展变化，开发可以快速交付，部署也更加稳定。

核心就在于简化Dev和Ops团队之间的流程，使整体软件开发过程更快速。

开发流程

整体的软件开发流程包括：

1. PLAN：开发团队根据客户的目标制定开发计划

2. CODE：根据PLAN开始编码过程，需要将不同版本的代码存储在一个库中。

3. BUILD：编码完成后，需要将代码构建并且运行。

4. TEST：成功构建项目后，需要测试代码是否存在BUG或错误。

5. DEPLOY：代码经过手动测试和自动化测试后，认定代码已经准备好部署并且交给运维团队。

6. OPERATE：运维团队将代码部署到生产环境中。

7. MONITOR：项目部署上线后，需要持续的监控产品。

8. INTEGRATE：然后将监控阶段收到的反馈发送回PLAN阶段，整体反复的流程就是DevOps的核心，即持续集成、持续部署。

总的来说就是：

1. Code阶段（编码）：Git+GitLab

2. Build阶段（构建）：Maven或Gradle

3. Operate（运行）：Docker

4. Integrate（集成）：Jenkins

   • CI/CD(持续集成)：操作Jenkins，编写对应脚本文件

   • Code review（代码质量检测）：Jenkins集成Sonar Qube

   • 自定义镜像：Harbor

   • Jenkins流水线操作

   • WebHook：通知操作，如：钉钉机器人通知

5. K8S编排：更加方便我们管理容器

三、为什么会出现DevOps？

1. 容器化技术的发展，微服务架构的发展，直接促进了DevOps的迅速发展

2. 敏态需求的增加，即探索性工作的增加软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求，近些年创新型的应用不断涌现，在这些应用的研发过程中多采用小步快跑、快速试错的方式，这些探索性工作要求运维能够具备一天发布多次的能力，需要企业完成由稳态到敏态的转变。

3. 软件开发活动在企业经营活动中占比的不断增加业务发展对软件的依赖由轻度依赖、中度依赖发展到目前的重度依赖。

4. 企业存在对消除浪费的需求

   • 软件开发活动在企业中的位置越来越重要，而像企业经营活动一样，软件开发活动中也存在着许多的浪费，企业管理上必然存在着 「识别并消除浪费」 的需求。

   • 软件开发中的浪费包括不必要和必要的浪费，不必要的浪费有：无人使用的功能、软件bug、等待测试、等待审批等；必要的浪费包括：工作项移交、测试、项目管理等。

四、DevOps的优势

1. DevOps 的主要优势在于，自动化流程可以比人员更快，更可靠地执行重复操作。对于组织而言，让开发人员或其他人员整天构建和部署代码既不可行，也无济于事。使这些重复性任务自动化可以使开发人员腾出精力去做自己最擅长的工作 ~ 修改代码。

2. 这样做是允许在几分钟之内构建和部署代码，这仅受组织选择管理其DevOps管道的方式的限制。这意味着从开发功能或错误修正到向最终用户提供更好的体验之间的时间可以大大缩短，从而使用户更加满意。

3. 它还创建了更好的反馈循环。新功能越早交付给用户，组织就越早可以收集反馈和指标并深入了解用户对其产品的喜好。这使组织保持敏捷并为创新提供了更好的环境。

五、DevOps生命周期

DevOps生命周期主要包括产品（策划、研发、运营、推出）、项目（立项、执行、完工），而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。

DevOps 在支持全生命周期的过程，要以产品的视角来看待，真正进行交付的时候，也要以产品为维度进行组织的设立。

DevOps 的核心是一组工具和实践，可帮助组织更可靠，更快地构建，测试和部署软件。DevOps 使组织能够比具有传统开发和发布周期的组织更快地发展和交付其产品，从而可以提供竞争优势。与其每天两周或更长时间发布一次版本，不如每天向用户交付新功能，并且可以在数小时内部署错误修正，所有这些都遵循相同的可重复自动化流程。

六、DevOps三大原则

1、流动原则

• 加速从开发、运维到交付给客户的流程；

• 坚持少做，产品开始开发时采用 MVP 原则，产品迭代时要适时做减法；

• 持续分解问题，大的变更或需求拆解为一系列小的变更，快速解决；

• 工作可视化，采用 Sprint 看板将工作可视化；

• 控制任务数量，减少前置时间，降低测试人员的等待时间；

• 减少交接次数，减少不必要的沟通和等待；

• 持续识别和改善约束点，提高搭建环境、需求文档、QA、开发、运维的生产力；

• 消除价值流中的困境和浪费；

2、反馈原则

• 建设安全可靠的工作体系；

• 在复杂系统中安全地工作；

• 及时发现问题；

• 在源头保障质量；

• 为内部客户优化工作；

3、持续学习与实验原则

• 采用科学的工作方式，将对组织的改进和创新作为工作的一部分。

• 建立学习型组织和安全文化；

• 将日常工作的改进制度化；

• 把局部发现转化为全局优化；

• 在日常工作中注入弹性模式；

• 领导层强化学习文化；

七、DevOps与CICD的联系与区别

（一）核心定义

1. CICD：软件工程实践方法，包括持续集成（CI）、持续交付（CD）、持续部署（CD）三个典型阶段，通过自动化实现高频度向客户交付应用。

2. DevOps：一种文化，容器、容器编排、微服务等技术使其落地；DevOps团队的最终目标通常是在开发环境中自动化CI/CD。

（二）联系与区别

维度	DevOps	CICD
核心定位	文化，强调协作与共同目标	实践方法，强调流程自动化
关注重点	文化、角色、协作	流程、工具、自动化
目标	改善客户体验和底线结果，实现持续交付	高频度、高质量交付应用
关系	CICD是DevOps的关键实践和落地手段	是DevOps团队的重要目标之一

（三）CICD详细解析

1. 核心概念

   1. 持续集成（CI）：开发人员的自动化流程，实现开发工作流程自动化，包括代码提交、构建、单元测试、集成测试等。

   2. 持续交付：开发人员的更改自动进行错误测试并上传到存储库（如GitHub或Image Registry），由运维团队部署到生产环境；解决开发和运维沟通问题，减少部署工作量。

   3. 持续部署：自动将开发人员的更改从存储库发布到生产环境；以持续交付为前提，解决手动流程导致的交付速度慢、运维超负荷问题。

2. CICD Pipeline

   1. 定义：为交付新版本软件必须执行的一系列步骤，是一套专注于改进软件交付的实践，加入监控和自动化。

   2. 核心价值：自动化（手动可执行但自动化是关键）。

   3. 典型阶段：

      • Build（构建）：应用编译。

      • Test（测试）：代码测试（如JUnit Tests、性能测试）。

      • Release（发布）：将应用交付到存储库（如NPM Registry、Maven repository、Container Registry）。

      • Deploy（部署）：将代码部署到生产环境（如Review App、生产环境部署）。

      • Validation和Compliance（验证与合规）：镜像安全性扫描（如Clair）等。

   4. 云原生支持：传统CI/CD为虚拟机设计，云原生技术带来突破，如Tekton项目可构建Kubernetes风格的Pipeline。

3. 简单工作流程

   1. Commit Change：开发人员提交代码至代码仓库。

   2. Build Binary：CI Server构建应用程序。

   3. Deploy UAT：部署到用户接受度测试（UAT）环境。

   4. Test UAT：在UAT环境完成测试。

   5. Deploy PROD：部署到生产（PROD）环境。

   6. Test PROD：在PROD环境完成测试。

4. 常见流水线示例

   1. 自动化CICD工作流：Close Pull Request → GitHub Pull Request → Build → Test → Feedback → Success merges PR to master → Release type → Git tag → More Tests → Upload Artifacts → Staging Deploy → More Tests → Upload Artifacts → Production Deploy

   2. 多分支Release流水线：UpdateMetaData → Deploy to Dev → Test Dev → Notify Dev；UpdateMetaData → Deploy to QA → Test QA → Notify QA；UpdateMetaData → Deploy to Stage → Test Stage → Notify Stage；UpdateMetaData → Deploy to Prod → Test Prod → Notify Prod

   3. Kubernetes相关Pipeline：

      • Push Pipeline（CI/CD Pipeline Workflow with Kubernetes）：Developer Commit code, push to git → Git Repo → CI Server notices new code & starts pipeline → Run tests → Build new Docker image → Push new Docker image to REPOSITORY → Kubernetes Pull new Docker image → Create new pod → Check pod health → If new pod is healthy, Restart deployment, Delete old pod; If new pod is not healthy, Continue running old pod

      • Push Pipeline（CI/CD With Kubernetes and Helm）：Developer Feature Branch → Push → Pull Request → Reviewer Review → Merge → Build Image → Publish Chart to ChartMuseum → Deploy Helm Chart to Development → Verify → Push to Staging Branch → Deploy Helm Chart to Staging → Verify Staging → Merge to Master Branch → Deploy Helm Chart to Production

   4. Pull Pipeline（Weave Cloud的DevOps方法）：依赖Config Updater（监视image变动并更新配置清单）和Deploy Synchronizer（维护应用当前状态）；工作机制：Developer push code change → Git → CI Server build Docker Image → Config Updater update config repo → Deploy Synchronizer pull config and deploy to Kubernetes Cluster

（四）Pipeline模型演进

1. Push Pipeline

   1. 特点：代码从CI系统开始，经脚本自动化或手动完成Stage；凭据可能保存于代码中，存在安全风险。

   2. 架构：Dev（RW Code Repo）→ CI（RW Image Repo）→ Cluster（RO）

2. Pull Pipeline（GitOps）

   1. 特点：凭据保存于集群；CI Pipeline构建并推送新Image后，Deployment Automator拉取Image并更新config repo，Deployment Synchronizer察觉集群状态落后，获取配置并更新Image。

   2. 架构：Dev（RW Code Repo）→ CI（RW Image Repo）→ Config Repo（RO）→ Operator（RW Cluster）

   3. 典型GitOps Pipeline：两个Git仓库（代码仓库：开发人员推送代码变更；配置仓库：运维人员推送基础设施和应用配置）；工作流程：Developer push code → CI工具链测试和构建 → CD工具链测试和交付（推送Image至工件仓库）→ Config Update推送Image变更至配置仓库 → 根据分支和发布策略部署应用。