开启生长之旅！这是我参加「日新计划 12 月更文应战」的第2天，点击查看活动概况
很久没有写文章记录了，上一篇文章像流水账一样，把所见所闻一个个记录下来。这次专门聊聊DevOps渠道的建造吧，有些新的领会和考虑，期望给正在做这个工作的同学们一些启示吧。 DevOps落地实践点滴和踩坑记录-(1)
企业落地DevOps该买商用仍是自己研制呢？
- 如果团队人数少，技能栈或许技能债款不是许多，前史包袱不重，领导急于看到成果，能够使用devops商业产品。条件仍是看商业产品是否满足你们现在场景。
- 自建东西链，分成简略东西搭建 和 更上一层的二次开发做渠道，看你们需求哪种。
- 前者相对简略点，比方常见的gitlab+jenkins+harbor/nexus+kubernetes等这样的组合
- 后者 前期需求投入成本，仍是看 你们方针是什么，处理什么问题。
以终为始，看方针，找适宜的计划，是比较适宜的。渠道可大可小，功用也可大可小，处理的问题也可大可小，看看现在的问题是什么？
有哪些好用的DevOps价值流交付渠道引荐？
国外
- Azure DevOps
国内
- Coding
- 蓝鲸
- JD行云
- 阿里云效
- 简略云ezone
- 华为DevCloud
国内许多，以上这些都算是整合各个环节比较归纳的，其他像禅道、Ones等这些项目办理类渠道虽然号称DevOps渠道，可是他们更擅长笔直范畴，不是归纳性渠道。
有哪些好用的DevOps VSDP（DevOps价值流交付渠道）引荐？ – 知乎
自研DevOps渠道面临的问题
上面说的渠道都很好，可是面临上千规划的研制团队，往往会有“心有余力不足”，“杀鸡用牛刀，可是还杀不了鸡”的感觉。说白了，便是买了仍是做二次开发，并且往往还不是简略二次开发这么简略。听我细细道来
1. 企业内部各渠道鱼龙混杂
关于中小型企业，你能够经过采购外部DevOps渠道服务的方法，快速构成战斗力。可是关于必定规划的企业，并不是一穷二白，而是各种渠道现已存在了。 这是一个企业的案例，很明显管需求的在OA, 管工单在一个体系，项目办理在另外一个体系。那我买了外面的渠道（一般都是全家桶的处理计划），究竟和我内部体系怎样融合呢？
- 举个例子，如果公司现已用了JIRA, 外面大部分DevOps渠道都自带同类功用的模块，你让我把JIRA干掉，买你的产品，虽然JIRA国内有点水土不服，可是这需求办理者做出抉择，哪怕是数据搬迁也是需求成本和时刻的。
2. 自研渠道实质仍是“企业的数字化转型”
关于传统软件企业，他们要的渠道不仅仅是一个跑CI/CD，做布置的渠道，更重要的是能够度量内部革新成果的渠道。提到度量，就意味着你要打通整个研制进程所有环节，从外部客户需求，到内部研制环节，到对外发布，再到产品反馈，构成闭环。 能够幻想，革新进程会遇到多少不同的角色，不同的渠道，所以研制打造自己渠道的进程也是企业内部自我革新的进程，这个进程会很漫长，也会很痛。
- 关于互联网企业，他们必须拥抱改变，快速抢占市场，所以从基础设施到人员素质，必定程度上比传统软件企业会好许多，数字化程度会好许多，他们注重更多其实是线上的快速发布，回滚，试错，监控告警。技能栈上，相对简略统一，个性化定制会很少，一般都是骨干开发骨干发布，或许骨干开发分支发布。
- 可是，关于传统企业，他们的特点是产品线丰富，客户定制化需求多，重产品定制（轻运维），他们更需求标准化的办理和规则约束。可是往往他们的技能设施（容器化，环境快速生成）比较落后，研制人员不太注重工程化手法处理问题，技能栈没有很好统一，东西各个团队各自为营，因此整合东西链条就变得更困难。
所以自研渠道实质仍是企业自我的革新和决计，如果把传统软件企业比作工厂，经过自研渠道进行功用和数据的整合，便是期望构建一个真正的“数字化“工厂，让信息活动和共享。
3. 自研渠道建造离不开部分间的拉通对齐
如下图所示，DevOps触及诸多研制阶段和范畴
- 项目办理
- 需求/缺点盯梢
- 代码办理
- 构建/布置/测试
- 发布
- 日志监控
- 影响全体技能架构设计，或许导致许多返工
- 部分间合作缺失，各自为营，不仅无法构成合力，还或许相互掣肘，相互或许在做重复工作
- 无法制定久远渠道演进规划
- 数据拉通遥遥无期
- 最终或许导致DevOps革新的失败，团队士气消沉，领导层看不到预期效果
处理思路-安排结构
- 成立虚拟的进程改善团队，包括安排级研效办理团队，渠道东西建造团队，效能/工程教练团队，对事务研制团队进行支撑
- 事务研制团队对效能提高负首要责任，每个月事务技能leader 报告发展；事务研制团队需求证明自己技能架构改善，处理成员的诉苦；需求对自己团队担任；
- 根绝“东西渠道团队”对效能成果担任的局面，东西团队一般供给的是通用的功用，关于“北极星”方针（ps:产品成功的要害方针）影响有限； 对技能担任，打包更快，上线工作流更好
- 效能/工程教练团队要走进一线，和团队成员面谈，深入了解团队“痛点”，进行教导
- 安排级研效办理团队（一般是PMO安排），树立安排级标准进行发布；（PS: 实践情况中，该部分或许需求DevOps东西/教练团队的支撑，特别是工程技能方面，防止标准无法落地）
- 需求一位德高望重，技能能力威望都还能够的领导统领进程改善团队 （PS: 处理拉通进程的困难，协助和谐资源，敢于拍板）
4. 围绕“版别”和“相关”做文章，构建研制范畴模型
- **”版别“ **记录了整个研制进程的演进，经过“版别”作为枢纽，串联起来真个研制进程的元数据，再适宜不过。
- **”版别“**的标准化，也是流程标准化的重要体现，只要“版别”标准化，进程才或许标准化。试想，如果你的安排连标准的版别号以及发布标准都没有，其他自动化手法就底子不用提
- “版别”相关元数据 – 在笔者看来，是整个DevOps渠道的重要方针之一，如果没有做到这一点，必定影响价值流打通
5. 围绕安排内实在事务场景，防止照虎画猫
在我们自己建造DevOps渠道进程中，往往会参考一些商用的渠道，这个无可厚非，可是要防止“机械仿照”。任何一家公司的DevOps演进都不是一蹴即至，或多或少都有前史原因，仿照的一同要考虑他们为什么要这样做，是不是真的合适自己的场景，借鉴能够，可是要弄清楚为什么需求。 举例说明
- 大部分公有云的DevOps渠道基因里都或多或少都有互联网的基因，它们的关于继续布置发布（灰度，蓝绿）会格外注重，那么作为传统软件企业，你是否真的需求？
- 再比方，这些渠道的流水线编列都很灵敏，可是在你的企业过度的灵敏是否真的有用？ 也许开发团队只需求傻瓜式的，乃至无脑，严格控制的流程呢？
熟悉安排的软件研制活动，经过和事务研制团队座谈的方法，搜集实在的痛点，在“灵敏形式”和“呆板形式”中需求平衡。功用做的再酷炫，不能处理实践问题，也是没有任何价值的。
如图所示，能够经过绘制事务流程图的方法，将渠道的事务流程和实践的事务场景结合，指导渠道分阶段建造，事务与技能演进相结合。
总结
上面我分享的几个问题，相信你都会遇到，这儿仅供参考。每个安排想要的DevOps渠道是彻底不一样的，别人的场景功用未必就合适自己，首要仍是以处理问题为目的。 DevOps实践进程是漫长和困难的，渠道能力是整个安排一同尽力的成果，不要试图你的团队单枪匹马搞成这个工作，离不开你的“客户”（需求），离不开上层领导的支撑（自上而下推动），离不开安排运营标准的牵引（流程标准）。
