实施DevOps加强开发商管控（6.10）

内容简介：实施DevOps加强开发商管控（6.10）

对于传统企业，当大量的IT系统开发和实施都外包的情况下，如何加强对开发商的管控是必然面临的一个重要问题。其中对于稍微做的好点的企业可以看到类似上图， 优点就是需求方案和统一发布控制一头一尾，确保需求正确并并高质量发布，但是缺点就是中间都是弱管理，对于中间过程监控较弱，中间过程执行偏差可能影响到一头一尾，这也是很多时候甲方项目管理存在的关键问题。

对于这点，在早期我也提出了很多关键思路，总结来说包括了：

1.打开开发商过程黑盒，但是不是完全接管，而是增加各种管控点，包括评审，决策等各种机制建立

2.需求方案不仅仅是简单需求，而是业务方案+技术方案，防止后续走偏

3.配置管理要加强，特别是后续可能接管源代码管理和集中发布部署

4.加强各个项目执行中的项目执行监控，必须增加里程碑点监控和评审机制，及时发现问题

5.形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制

6.加强中间过程管理，要制定各个开发商共同遵守的大中间过程管控机制，至少这种粗粒度的要完全遵守

7.形成专家团队，做好各项评审工作，专家团队为虚拟团队，包括业务专家团队，技术专家团队等

8.需求方案+统一发布真正可以贯穿整个软件生命周期

9.由传统的被动发布，转变为围绕需求方案和优化更新的有计划有节奏的产品版本发布

在原来推持续集成的时候 ，我们还有一个重要目的就是能够打开开发商的黑盒，加强对中间过程的监控和管理，让质量问题及早地暴露出来，方面后续甲方能够顺利的接管运维 。从这个目的来看，完全是和当前的DevOps思路是吻合的，即协同好技术，质量和运维三者之间的关系。对于甲方如果作为后续运维方，那么从一开始就介入到整个IT系统开发和实施的全生命周期管理过程中。

在DevOps思路实施中，仍然注意要推进两个重点， 其一是组件化和微服务架构，其二是和PaaS云和各种 工具 集成实现整个过程的自动化和流水线作业 。

在实施DevOps的时候，我们对开发商可以提出更多的方便后续运维和管控的要求，从一开始的 开发环境，开发框架，单元测试，代码静态检查，持续集成工具，服务接口标准，配置管理环境，版本发布规则，环境迁移规则 ，包括甲方需要做的各种质量方面的人工审核和检查，这些内容都可以嵌入到整个DevOps流水线作业中。

在这种情况下， 开发商从一开始提交的代码，代码的质量，单元测试的结果就全部可视化给甲方和客户，开发商想在这块藏着掖着就相当困难 ，这既方面了一开始就监控和暴露问题，同时也方便了后续基于整个代码质量的检查和工作量，规模的度量体系的建设。

对于开发测试环境，开发框架和工具，配置管理等从开发商自己管理到迁移到由甲方统一配置和管理将极大的提升甲方对开发商的管控力度。虽然在前期推行涉及到甲方和开发商本身的技术能力和成熟度是否能够达到，已经开发商本身对该方式的抵触思想等，但是整个趋势如此，在12年我们实施的私有云PaaS项目中，其实已经参考该思路在实施和验证。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 行业人士分析游戏开发商如何逆向推动平台进步
• Improbable发文质疑游戏引擎开发商Unity更改用户协议
• PokémonGO 开发商宣布将向第三方开发者开放 AR 平台
• TiDB 开发商 PingCAP 完成 C 轮 5000 万美元融资
• WordPress 主题开发商将客户当肉鸡，向对手发起 DDoS
• 网络协议之数据中心：我是开发商，自己拿地盖别墅

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。