-
一文收录16张DevOps ”拍照神图”
image
- 致产品经理： 持续集成、持续交付、持续部署和DevOps
- 基于 Docker、Kubernetes 实现高效可靠的规模化 CI/CD 流水线的搭建
- The Product Managers’ Guide to Continuous Delivery and DevOps
- 如何理解持续集成、持续交付、持续部署？
- 持续集成是什么？
背景
业界为什么会出现DevOps ：
- 开发部门的驱动力通常是“频繁交付新特性”
- 运营部门则更关注IT服务的可靠性和IT成本。
- 两者目标的不匹配，在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。
- 产品管理、研发、运维、运营分属于不同部门，没有有效拉通
- 缺少全功能团队，设计、开发、测试分工过细，导致效率不高
- 规划、开发、运维、运营各自执行自己的流程，缺少业务集成
互联网：
- 交付周期短，快（AWS一周就可以上线交付一个云服务）
- 简约敏捷
- 试错
- 业务竞争力强
- 过程灵活
- 高效运营
- 互联网服务变动频繁，发布周期短，强调早发布、常发布，注重用户反馈
DevOps的目的：
- 促进研发（应用程序/软件工程）、技术运营（运维）部门之间的沟通、协作与整合，持续交付可靠的软件产品和服务。通过快速反馈提升用户体验和研发效率。
- DevOps是以业务驱动的软件交付方法。从需求到交付生产环境，研发与运维间紧密协的文化运动与实践。DevOps文化更注重沟通，快速获得用户反馈提升创新能力。
定义
-
DevOps基于敏捷与精益的理念，从业务和整个价值链角度，推动组织优化软件交付方式，从敏捷的开发，走向敏捷的运维和敏捷的业务。DevOps提倡打破孤岛，促进开发和运维之间高度协同，在实现小批量迭代交付、增量式发布、高频率部署、快速闭环反馈的同时，提高生产环境中软件部署及运行的可靠性、稳定性、可伸缩性和安全性。 DevOps通常指软件行业新兴的专业化运动，是一组文化、流程与工具整合后的统称。
-
DevOps解决的业务问题：
DevOps并非目标，而是实现目标的方法，使用DevOps模式可以发现交付通道中的瓶颈，解决监管障碍、流程复杂、技能不足和组织孤岛问题。
实践
通过小批量持续发布、自动化部署、灰度发布、持续监控和数据分析驱动建立交付通道。通过全功能团队、服务化架构和基础设施即代码增强交付通道
将大任务分解为可以迅速完成的较小任务，以服务化/微服务架构模式进行敏捷交付，细粒度持续向生产环境发布。
自动化部署：以完全一致的方式自动化地将应用或服务部署到Dev、SDV、SIT、类生产、生产等各个环境， 并对部署进行自动化验证。
灰度发布：灰度发布是指在新旧版本之间，平滑过渡的一种发布方式。灰度发布可以减少发布后的质量风险，通过分批次发布将风险控制在可接受的范围内。
持续交付流水线
Alpha -> Beta -> Gamma -> Release
需求 -> 设计 -> 开发 -> 构建（自验，UT） -> 部署（集成测试） -> 验证（类生产） -> 部署 -> 运维（灰度发布，运维监控）
互联网金融
客户体验和市场竞争要求系统响应快速，同时还需保持稳定、可靠
- 建设一个平台；工具化、标准化；多种关键技术；全链路贯通；线上协作；流水线；
- 联结三个角色：开发、测试、运维共同协作，提频繁、高效沟通，打破部门墙，构建全功能团队，
- 打通五个环节：打通需求、开发、集成、测试、运维5个环节，实现顺畅流畅、高效运作、高效交付
最终高质量软件的快速交付。
误解
- 既然有了DevOps平台，就把所有工作全交给DevOps平台的支持团
队；
• DevOps的理念是开发自运维，DevOps平台仅仅是提供自运维的工具和环境，实际的
运维应该由研发团队自己负责； - 希望通过界面操作解决所有问题；
• 最灵活，最强大的工具，应该是命令行脚本，不应该期望将所有功能都通过UI支持，
可视化的关注点应该是结果和报表；
网友评论