DevOps落地切入点的确定及实施实例(2)

把以上所有的内容都分析好就能确定你的第一个切入点是什么.从研发角度来看可以选择用一个管理工具把信息集中,或者推广SCRUM或kanban开发.从测试角度可以进行代码变动后的自动部署及自动化测试.从配管角度可以选择持续集成.从运维角度可以选择自动生产环境部署和回滚.我选择的切入点是管理工具、SCRUM团队、自动部署.因为原有的Redmine信息不完整,大量信息不对称的情况,计划形同虚设.配管整天手工上线,疲于奔命.开发效率低,延误情况很严重.

在实施过程当中要注意要用利去引诱改变,不要试图立刻改变所有的现状,因为你如果改变所有现状,把所有的东西搞乱,搞乱之后,就会影响业务.影响了业务你就有了大麻烦.所有的改变必须是局部的,影响范围是可控的.

要把资源向敏捷团队倾斜,要给他们提供便利.因为变革前期必然会混乱和低效率,如果不去注意改善,就会变成坏榜样.如果变革使得他们的工作更顺利,这样的就树立了一个典型,使得其他团队可以看到这么做是有好处的,然后在适当的时候你就可以一刀切,全面推行.下面给出一个例子,我把上线的窗口定义成：

1. 项目上线日期为工作日的周一-周四,自动上线8点45分开始工作,处理前一日完成测试的需求.
2. 敏捷项目上线日期为所有工作日,自动上线11点-17点处理测试完成的需求.
3. 手工上线的需求上线日期仍然为周二到周四.

这样就吸引大家进行迁移,有些项目会主动选择敏捷开发模式.

下面说一下工具选型的过程.流程软件放弃了原有的Redmine.从DevSuite,禅道,Jira中选了Jira.DevSuite适合超级大公司,看重管理审核.禅道过于简单,和其他软件集成能力弱.Jira有非常丰富的插件库,同时有非常成熟的开发接口和开发库.同时在世界范围Jira有几千家公司在用.所以最终选择了Jira.测试插件用了Kanoah Tests和JIRA Capture.版本控制在单纯git和github、gitlab中选择了gitlab.主要是比较认可gitlab flow.CI工具用Jenkins,这个基本没啥可挑的.而且Jira、gitlab、Jenkins都有插件可以互相连接起来.自动化测试使用的自己开发+SOAPUI+APPINUM等.自动化部署是自己开发.

下面是Jira中的一个自动上线需求的状态变迁图：

大部分状态都是程序在流转,开发只需要处理2个状态.测试需要处理6个状态.程序使用了Jira的Restful接口来进行操作.

代码的分支使用标准的Gitlab Flow.代码单向流动.MASTER给开发用.PRE-PRODUCTION和集测环境的JENKINS集成,代码变动后自动编译部署及自动化测试.PRODUCTION分支和系统测试环境JENKINS集成,上线也从这个JENKINS直接拉最终的上线包.

一个完整的持续集成过程如下图：

由于测试网络和生产网络是隔离的.所以自动部署分成两个部分,一端在测试环境属于配管,一端在生产环境属于运维.需求测试完成后,自动上线程序就会按照上线窗口来选择对应的需求进行上线.

在全部系统投入运行后,还有很多事情要持续进行.首先最难的是观念的转变,新流程经过多次培训,文档也已提供,还是有很多人两耳不闻窗外事,继续按照老一套进行.同时敏捷的方式也不是所有人能接受,思维的顽固性影响深远.其次迁移工作的工作量巨大,要逐步对老系统按计划迁移.迁移包括代码从SVN到GITLAB.Jenkins上已有脚本的迁移.测试环境的重整.Jira上流程也需要逐步完善,例如：后期我们把申请新发布单元、紧急上线审批、线上数据修复等流程也放入Jira.再增加各种数据分析和报表.最后一点就是定期对照成熟度模型,看可以进行哪方面的改进.

总结一下最关键的几条原则：

• 要根据自己所在的位置来选择变革的范围.
• 要分析利益相关方来确定变革的阻力.
• 要根据现状和条件来选择最容易突破的地方.
• 要通过利益引导来吸引大家主动改变,同时在适当的时候一刀切.

以上就是我自己的方法论和一些实践经验,欢迎大家讨论.

作者：木鱼,在通信和互联网跌打滚爬近20年.几乎干过研发体系内各种岗位.从初级码农到管理层.中国第一批EXIN DEVOPS MASTER认证通过者.

（编辑：ASP站长网）