运维助力敏捷交付-我们的运维看板
2019-12-30
来源： 高效运维 许颖维&廖君怡
块，就是在软件开发生命周期里，运维这个职业向什么方面发展，在软件开发生命周期能做什么事情。
看一下从传统到敏捷DevOps这块的生命周期整个最大的变化在哪，左侧图我们看到从设计开发测试部署管理评估这些，DevOps最开始都是各个一波人在做一系独立的事情，Dev做Dev的事情，Ops做Ops的事情。
后面你会发现最大的变化不是运维方面的变化，其实是把业务加进来了，就是在整个研发过程产品是越来越重要的，现在是产品为王的时代。当然整个研发生命周期里，产品，开发和运维都是紧密的联系在一起，就是说可以看到一个很明显的特征，现在软件开发的过程提倡的是越来越协作化，每一个环节都有不同的团队在合作。
敏捷交付的三阶段
敏捷交付的阶段划分方法有很多种，这个只是其中的一种，不代表全部。我们只是用这种划分作为例子来讲，在这个敏捷交付三阶段里，运维大致是能做什么工作。我先大概的介绍一下敏捷交付的三阶段。
开始的阶段，可能在大型一点的软件组织里，可能会有一些初步的建模，比如领域建模，还有一些高级的排序，比如说业务哪些是重点，哪些是相对重点发布的计划，现在新一点的是用用户故事地图这种简单一点的方法，也是用各种卡片，就可以简单的一些业务排序做完了。
构造阶段，我们是Scrum，或者极限编程，精益生产和Kanban，还有开发解决方案在构造阶段。
软件部署和交付的阶段，我们称之为转换阶段交付出去了，就是一些部署的解决方案和交付以后一些最后的监控等等属于软件的转换的阶段。
开始阶段运维能做的
在开始的阶段，我们认为从DevOps的角度中我们运维可以做什么？我们从需求的角度其实是应该把运维作为首要干系人，可以在需求的过程，比如提出日志监控的需求和服务级别协议的规格和容量的规划，业务连续性的服务和策略还有信息安全，我觉得这个是稍微大型一点的组织，都是需要考虑这些方面的，除非你是非常纯创业的小型APP创业团队，从工程的角度发布计划其实应该比较严谨一点，可以包括发布调度和运维的配合还有运维人员可能需要做哪些培训。
构造阶段运维能做的
构造阶段，大家可以看到图很眼熟，这个图讲了一个比较理想的状态，大家可以看到代码提交到编译到单元测试分析，测试员可能会自动化一键部署测试环境，到验收测试的阶段，到运维人员可能去一键部署，中间会有容量测试，但是容量测试也是由运维还有开发还有性能测试人员一起来做这块的，最后是到一个部署和生产环境，那下面可能有一个总体的制品仓库在支撑这块的工作。
前面的图其实是描绘了比较理想的最终的目标的状态，我们部门跟运维部门其实也是正在合作开发DevOps的平台，我们从开发环境开始，到提交测试，其中从集成环境，代码质量检查，单元测试覆盖率，还有安全扫描，到最后一个预发布和发布环境，这块运维在里面也做了很多的工作，比如说是环境的管理，应用部署，容量的规划和管理，都是由运维团队配合我们的。
我们现在看到很多的公司，他可能都是用一些开源的框架来做这个流水线，由需要部署的人员直接实施。
但是我们公司里不一样，我们当时做了一个切割点，就在服务环境提供里，因为只有运维能接触到环境，因为我们本身有一个原有的运维和部署的系统，我们这边会区分，也就是运维负责怎么把包放到线上，怎么做容量管理。
而这个Devops的前面部分原来完全由质量部门做，怎么
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
