混沌初开，DevOps落地从哪个实践开始会更合适？我选择制品管理

DevOps相关的管理实践和工程实践有很多，从精益看板，版本控制，流水线，TDD，代码检查，部署发布等等，对于混沌初开的组织，从哪里开始呢？

我选择制品管理

交付协作步调一致从统一制品开始

一个组织或团队的效率低下，一定和交付的混乱有关系，而制品（通常我们说的安装包）就是交付价值的载体。无非表现下面几个情况：

• 稍微好点的有个FTP服务器存放，差点的就通过乱七八糟的工具来回传递
• 制品的版本追踪混乱，相互问来问去，测试问开发，开发问测试，运维问开发，实施问xxx
• 大点的组织，可能好点，搭建个开源制品库，可能又会出现，好多个不同团队的制品库，浪费严重
• 后面的自动化部署也就不用考虑了，肯定也不咋地
• ...

上述情况，可以想象开发和测试很难好好玩耍，愉快的工作，最起码信息是不通畅的。

为什么首选不是CI/CD流水线呢？

理由如下：

• 成本相对高（相对于制品而言），周期长，不是所有团队自动化能力都很高
• 基本自动构建能力还都是有的，只是好坏问题，CI/CD建设是个持久战
• 但是安装包，肯定都是有的吧？是刚需
• 是刚需，对于团队来说抵触情绪就少一点，别给“团队找事”是第一位 （我不赞成上来就搞不切实际的实践，团队几斤几两不清楚？），赢得用户好感是第一位的

说白了，制品管理体系的搭建性价比高，见效快，哪怕手动上传，大家放在一个地方都是好的。

制品被忽视的”战略地位“

制品往往是最容易被忽略的，不就存放个包吗？如图所示，制品在整个DevOps的“地缘政治”里，处于中间环节，承上启下，战略地位及其重要。

• 构建的终点是它
• 部署的起点是它
• 制品是版本控制的产物，承载了很多研发过程信息
• 制品还可能是黑客关注的对象，潜藏未知的风险

控制了“制品”，你就控制了“团队交付要道”，左边跟他们可以谈构建，右边可以跟他们谈部署，下一步合作机会不是就有了？

总结

制品管理实践落地

• 难度系数：⭐⭐⭐
• 推荐理由：刚需，成本低，见效快，快速赢得客户
• 适合客户：混沌初开，团队多，客户多，分支机构多
• 实施重点：版本规范
• 实施难点：分级分类治理，异地分发，权限控制（PS: 超过30人多团队情况再考虑这些）