DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3605 人已学习
课程目录
已完结 39 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球，DevOps究竟有什么魔力？
免费
基础理论篇 (4讲)
01 | DevOps的“定义”：DevOps究竟要解决什么问题？
02 | DevOps的价值：数字化转型时代，DevOps是必选项？
03 | DevOps的实施：到底是工具先行还是文化先行？
04 | DevOps的衡量：你是否找到了DevOps的实施路线图？
落地实践篇 (16讲)
05 | 价值流分析：关于DevOps转型，我们应该从何处入手？
06 | 转型之路：企业实施DevOps的常见路径和问题
07 | 业务敏捷：帮助DevOps快速落地的源动力
08 | 精益看板（上）：精益驱动的敏捷开发方法
09 | 精益看板（下）：精益驱动的敏捷开发方法
10 | 配置管理：最容易被忽视的DevOps工程实践基础
11 | 分支策略：让研发高效协作的关键要素
12 | 持续集成：你说的CI和我说的CI是一回事吗？
13 | 自动化测试：DevOps的阿克琉斯之踵
14 | 内建质量：丰田和亚马逊给我们的启示
15 | 技术债务：那些不可忽视的潜在问题
16 | 环境管理：一切皆代码是一种什么样的体验？
17 | 部署管理：低风险的部署发布策略
18 | 混沌工程：软件领域的反脆弱
19 | 正向度量：如何建立完整的DevOps度量体系？
20 | 持续改进：PDCA体系和持续改进的意义
平台工具篇 (8讲)
21 | 开源还是自研：企业DevOps平台建设的三个阶段
22 | 产品设计之道：DevOps产品设计的五个层次
23 | 持续交付平台：现代流水线必备的十大特征（上）
24 | 持续交付平台：现代流水线必备的十大特征（下）
25 | 让数据说话：如何建设企业级数据度量平台？
26 | 平台产品研发：三个月完成千人规模的产品要怎么做？
27 | 巨人的肩膀：那些你不能忽视的开源工具
28 | 迈向云端：云原生应用时代的平台思考
转型案例篇 (2讲)
29 | 向前一步：万人规模企业的DevOps实战转型案例（上）
30 | 向前一步：万人规模企业的DevOps实战转型案例（下）
特别放送 (5讲)
特别放送（一）| 成为DevOps工程师的必备技能（上）
特别放送（二）| 成为DevOps工程师的必备技能（下）
特别放送（三）| 学习DevOps不得不了解的经典资料
特别放送（四）| Jenkins产品经理是如何设计产品的？
特别放送（五）| 关于DevOps组织和文化的那些趣事儿
总结答疑篇 (2讲)
期中总结 | 3个典型问题答疑及如何高效学习
期末总结 | 在云时代，如何选择一款合适的流水线工具？
结束语 (1讲)
结束语 | 持续改进，成就非凡！
DevOps实战笔记
登录|注册
30 | 向前一步：万人规模企业的DevOps实战转型案例（下）
石雪峰 2019-12-28
你好，我是石雪峰。今天，我们接着上一讲的内容，继续来聊一聊微软 DevOps 转型的故事。
经常有人会问，企业的 DevOps 转型应该由哪个团队来负责，是否要组建一个全新的 DevOps 团队呢？带着这个问题，我们来看看微软是怎么做的。
1ES
微软有一个特殊的团队，叫作 1ES。1ES 是 One Engineering System 的缩写，直译过来就是“一套工程系统”的意思。从这个名字，相信你就可以看出来，在微软内部，有一套统一的工程能力平台来支撑微软内部各种形态产品的研发交付工作。没错！这个 1ES 团队包含了近 200 名工程师，作为组织级的研发效能团队，他们的目标就是通过一整套通用的工程能力平台，来提升内部的研发交付效率。
1ES 团队的工作职责可不仅仅是开发通用工具平台，他们还要负责公司的文化转型、最新的工程方法导入试验、研发过程改进、安全合规性检查、内部研发效率咨询以及在工程团队推广最佳实践等等，可以说是一个“全功能”的企业研发效能和生产力团队。截至 2018 年，数据显示，总共有近 10 万名用户在 1ES 提供的平台上协同办公。
但国内的现状是，很多企业对于研发效能的关注才刚刚起步。即便有人员负责类似的事情，也大多分散在各个业务内部，难以形成合力。组建了企业级统一的研发效能团队，而且规模能够跟微软的 1ES 相提并论的企业，基本上一只手就可以数得过来，就更别提建立一套统一的工程能力平台了。我曾见过一家大型企业，他们内部的工具平台有 1700 多个，殊不知，这里面有多少的重复建设和资源浪费。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(6)
Robert小七制品晋级是如何标识的？有没有好的流程设计分享？作者回复: 好问题，制品晋级背后的核心理念就是单一制品原则，也就是构建一次，多次部署，不重复进行构建，这里面要解决的就是构建包和配置的关系，常见的包括配置分离，配置中心，或者是根据环境加载。
制品晋级一般都是会有多个制品库，可以是多个服务器，也可以是多个目录，当制品在测试环境验证通过后，自动晋级到预发布环境的制品仓库，这个动作可以是物理上的文件复制，也可以通过文件打标或者添加属性便签的方式完成，这样取决于你的制品库是如何设计的哈。
流程方面的建议还是自动化，你需要明确在什么时间点，什么动作来触发晋级，晋级的目的是提供下一级环境的部署使用，所以应该要在部署动作之前完成。2019-12-28 1
johnny在27讲架构图的jenkins图框中，
提到Acceptance Stage、Staging Stage（Manual）。
我的问题是假设某个产品的1.0版本代码编写完成，如果顺利通过Acceptance Stage，那么这时测试环境制品库和预发布环境制品库中都存在1.0版本的制品，暂命名为V1.0.war。
如果在Staging Stage（Manual）的Smoke Test步骤中测试失败，那么就不能完成制品从预发布环境制品库到发布环境制品库的晋级，这时发布环境制品库中不会存在制品V1.0.war。
接下来开发人员要修复Smoke Test步骤中测试失败的代码，假设代码经过修复后，顺利通过Acceptance Stage、Staging Stage（Manual），那么这时测试环境、预发布环境、发布环境制品库中的制品分别都有哪些制品？
是不是这样的。
测试环境制品库中有V1.0.war、V1.1.war（还是只有V1.0.war，只不过这个制品是经过重新编译后生成的。）；
预发布环境制品库中有V1.0.war、V1.1.war（还是只有V1.0.war，只不过这个制品是经过重新编译后生成的。）；
发布环境制品库中有V1.1.war。
我的问题是当制品和产品的版本结合时，制品是怎么管理以及如何晋级的？2019-12-30
leslieDevOps有时是企业发展到一定程度逼出来的产物，各方的需求如何提升且让多方看到效果，其实DevOps在一定程度可以展现。微软的案例这其实就展现了一个问题；企业的发展中如何保持创新和效率。突然觉得中国军工的使用一代、测试一代、设计一代真的非常不容易且有魄力。
最近刚把老师的课程重新过了一遍整理里一遍：然后又看到了不一样的东西。工程效率的后期发展应当是非常好的，其实整件事情就看什么时候去做。前几天去了一个初创企业和几个朋友聊天：几个合伙人为了初期需求围攻技术总监，然后就和他们拆问题，拆到最后一堆需求砍成了几个，不过确实他们总监的效率和做事风格有点匀速，不符合初创的该快就快该慢就慢，核心需求还是要提速，其实早期最小精简版的介入可以起到作用；这其实就展现了-DevOps的介入和企业规模没有过大的关系，不同时期不同版本。
这门功课是我第一门学的过程中还做了1遍梳理-课程完成时其实学了2遍了：只是某些具体的做法待将来有机会时去实现落地。谢谢老师的分享，一路走来收获颇丰-谢谢。2019-12-29
陈斯佳老师今天文章里讲到微软关于测试的转型，从原来的要不要做测试，到现在的分级做测试，这让我想到得到老喻《人生算法》里关于认知和决策的定义:灰度认知，黑白决策。然而现实中很多人确颠倒了，变成黑白认知，灰度决策，在认知的时候，非黑即白，即要么做，要么不做，而决策的时候却犹犹豫豫，模棱两可。其实如果用灰度认知的方法，你可以给每一个选项加上一个百分比，最后的决策通过乘以加权后的结果大小来判断。微软的例子异曲同工，不是黑白认知的决定做测试还是不做测试，而是通过分级的方式来处理不同的测试活动，从达成共识的部分开始，一个阶段一个阶段的推进，完成了最后的阶段测试模型。2019-12-29- 陈斯佳很喜欢一句话:“做正确的事，一直做，等待时间的回报”2019-12-29
- 陈斯佳很认同老师对自动化程度识别的标准，也就是一个非专业人士是否能独自完成发布。我现在正在用Jenkins做QA发布部署的自动化，我的终极目标就是QA发布只要做两步，第一步选择要发布的版本号，第二步就是点击运行Jenkins Pipeline。2019-12-29
收起评论