ReaderMX.
持续交付2.0

研发效能提升要多高，只需 180 就行

持持续交付20约 7 分钟

  • 【连载】谷歌代码健康指南（二）- 完整版群友讨论：依赖管理怎么搞？有工具么？

  • 持续部署实践 对 ToB 软件企业也是一样有效的，前提是：你真的理解「持续部署」

  • 做好依赖管理的十五条准则（上）

  • 做好依赖管理的十五条准则（下）

  • Mob CR, 是快速提升团队工程技能的一种有效方式

  • 不稳定测试用例是自动化测试的主要挑战之一（Part One）

  • 不稳定的测试是自动化测试的主要挑战之一（PART II）

  • 我的 Selenium 不稳定

  • 向更多的端到端测试说：“NO”

  • 避免写出不稳定的测试用例

  • 累积流图-1：团队刚接触持续交付实践，遇到这种状况，怎么办？

  • 累积流图-2：如何发现更深的项目管理风险

  • 我，2012年QCon大会，关于 DevOps 的预言，成真！！！

  • 你每天都能遇到的事儿～ 绝对真实～ 同意的点赞、收藏、好看

  • 使用密封服务器（Hermetic Servers）进行端到端测试！

  • 测试金字塔及三种反模式

  • 谷歌的不稳定测试用例来自哪里？统计分析

  • CTO 一定要关注自动化测试的 “驾驶舱警报”

  • 制定测试策略，千万要记住这几个要点

  • CTO 应该知道的五大「非传统」指标

  • 2021 年度最受欢迎的十篇文章

  • “测试左移”的初级阶段，就有四个台阶了……

  • 用数据说话：即使提高软件发布频率，质量与产量也能兼得！移动端的持续交付实践

  • 提升工程效率的方法.docx

  • 谷歌如何度量工程生产力

  • 谷歌工程生产力度量的十年之变

  • DevOps即将进入下一阶段，IT 组织应为此做好准备

  • 2021 DevOps 报告(上篇） ：调查新发现

  • 2021 DevOps 报告(下篇） ：如何改进组织效能，如文档、安全、文化

  • 三大DevOps报告综述（Puppet，DevOps Institute and DORA）

  • 谷歌眼中的持续交付（警告：8000字的枯燥长文，慎入！）

  • 谷歌发布 2021 DevOps 报告

  • 一致性，是研发效能提升的必经之路（长文慎入）

  • 效能度量与工程师文化

  • 提升研发效率的基本工作原则

  • 有多少测试才算足够？

  • 不要  MOCK  不属于你的组件！

  • 千万不要过度依赖于 MOCK！

  • 针对 UI 逻辑，如何写正确的自动化测试呢？

  • DevOps 在百人组织中的前三步

  • DevOps动力模型与组织绩效

  • 谷歌PH值：软件项目的健康度度量

  • 谷歌的测试认证：目的与进程

  • 谷歌当年的TE 要花多大精力解决功能测试自动化用例不稳定的问题

  • 谷歌的工程经理，每天都在忙些什么？

  • 大问题都是由小问题发展来的

  • 一月份最受欢迎的五篇文章

  • 原子性提交是持续交付的必备技能

  • FACEBOOK 如何进行大规模持续交付

  • 软件依赖，风险越来越高，怎么办？

  • 湖水岩石与“当日事，当日毕”

  • 度量：MTTR，MTBF，MTTF，你分得清楚么？

  • 扎堆编程：一次重构之旅

  • 再谈谷歌如何做发布

  • 微反馈回路让开发人员效率最大化

  • 微软：测试左移，更快、更可靠

  • 微软：测试右移，TIP

  • 如何写好提交注释

  • 年度最受欢迎的十篇文章

  • 微软承认了在软件测试方面的失误

  • 如何做到高效的Code Review

  • 测试替身对象的分类与最佳实践

  • SRE落地：用VALET模式统一语言

  • 代码覆盖率最佳实践，谷歌权威推荐……

  • 微软巨人，如何将敏捷原则应用于团队改造

  • 微软VSTS，走向云节奏的DevOps旅程

  • （5000字长文）微软测试转型的历程与心法

  • 什么样才算单元测试？谁该负责写？微软和谷歌这么说……

  • 除了SWE，谷歌还有哪些角色，怎么做绩效评估？

  • 如何衡量团队的DevOps状态？可以参考谷歌云平台呀

  • 测试人员在DevOps转型过程中的发展路径是……

  • GitLab如何衡量工程生产力

  • 工程效能，质量提升，原来它是第一秘笈？

  • 硅谷顶级互联网公司的产品研发管理框架

  • 可测性指南：构造函数不该做太多事（一）

  • OKR & CFR 并重，最简 OKR 实践指南

  • 马桶测试系列(六）：对微服务调用进行契约检查

  • 马桶测试系列（五）：不要测试实现细节

  • 马桶测试系列(四）：如何写出稳定运行的测试用例

  • 马桶测试系列(三）：测试替身对象

  • 马桶测试系列(二）：写好端到端的测试

  • 谷歌的马桶测试系列(一）：测试行为，原因与影响清晰

  • 【身边案例】如何对旧代码进行可测性改造

  • 谷歌代码健康指南（四）

  • 谷歌代码健康指南（三）

  • 谷歌代码健康指南（二）

  • 谷歌代码健康指南（一）

  • 乔帮主说：“测试覆盖率多少合适”

  • 谷歌使用 OKR 的七个原因

  • 谷歌OKR指导手册（全文）

  • 【连载】 Facebook的配置项管理十大经验

  • 【连载】Facebook的工程师文化与数字化

  • 【连载】Facebook如何管理移动客户端的配置项

  • 【连载】Facebook的老家底—工具 GateKeeper

  • 【连载】配置项的大规模分发，Facebook如何保证可靠一致性

  • 【连载】践行“配置即代码” ，看Facebook怎么做

  • 【连载】后互联网时代，我们用什么工具集来管理海量配置项

  • 【谷歌OKR系列】制定OKR需要遵循的规则

  • 到底有哪些“周期时间”可以作为衡量改进的指标

  • 衡量软件产品团队效能指标，你知道多少？

  • 复盘（甩锅），你真的会么？向谷歌学习～

  • IMVU如何在实施持续部署的同时确保软件质量

  • 【连载】开关最佳实践(九）：建立反馈环

  • 【连载】开关最佳实践(八）：提前为规模化应用而制定规范计划

  • 【连载】开关最佳实践(七）：开关要考虑可测试性

  • 【连载】开关最佳实践(六）：一个开关归属于一个团队

  • 【连载】开关最佳实践(五）：让开关离业务逻辑更近

  • 【连载】开关最佳实践(四）：开关喜欢增量且兼容式数据库变更

  • 【连载】开关最佳实践(三）：让服务端来决策

  • 【连载】开关最佳实践(二）：小心处理“登录态切换”

  • 【连载】开关最佳实践(一）：保持一致性

  • 只使用一个指标，引导“祖传”代码的质量改进？

  • “双环模型与文化四步法”解读

  • 谷歌制定代码规范的六条原则

  • 硅谷公司的工程效能案例集

  • 帮主说 | 程序员与单元测试

  • 帮主说 | “CMMI vs 敏捷”PK赛，CMMI大获全

  • 帮主说 | 程序员与文档

  • 干货 | 测试扁平化之必备神器：好的单元测试

  • 问答 | 传统企业如何做DevOps转型（一）

  • 观点 | 工程生产力之"10X"法则

  • 对话 | 谷歌VP谈工程生产力（二）

  • 对话 | 谷歌VP谈工程生产力（一）

  • 观点 | 那些真真假假的“敏捷”,头图很靓

  • 观点 | 2019，软件产品研发理念与管理模式新纪元

  • 案例分析 | Google和Facebook如何做Code Review

  • 资料放送 | 持续交付2.0-北京第1届活动回顾

  • 案例综述 | Google和Facebook如何做质量保证

  • Facebook 终于向“持续交付”又近了一步

  • Git-flow, Github-flow, Gitlab-flow 你应该选哪一种？

  • 有九大指标可以对软件开发团队带来巨大改变

  • “低调、务实、简单”：腾讯副总裁为《持续交付2.0》作推荐序

  • KPI 即价值观......吗？书写价值观的格式

  • 领域驱动设计：应对软件复杂度的一种方式

  • CD2.0  | 软件配置管理的自查七问

  • DevOps领军人物Jez Humble为《持续交付2.0》亲自作序

  • 学习Google研发模式，先需要学习这个

  • 书摘 | 发布模式与分支策略

  • 书摘 | 持续集成实践的自查表

  • 一线经理八项基本管理能力的提升指引

  • 跨越鸿沟：再析DevOps历程中的烟斗曲线

  • 美团点评运营配置平台的设计与实践之道

  • 从谷歌看企业文化变革成功四要素

  • DevOps实施过程中的烟斗曲线

  • 《2018全球DevOps现状报告》—Part2

  • 《2018全球DevOps现状报告》-Part1

  • 11月2日，新书预告——《持续交付2.0》

  • 腾讯研发效率领先的秘密：高效率的工具

  • GoCD 如此一个简洁漂亮的软件

  • 敏捷培训课中那些不当的数据引证

  • 一张图带你了解CD&DevOps的前世

  • 开发人员写测试，Google是这样做到的，你想到没有

  • Google的代码质量文化，花了5年时间

  • 走向“持续部署”

  • 最早的“部署流水线”原来在这里~

  • 另外两种DDD，来自QCon上海的闲聊

  • Netflix如何做构建和部署？

  • 持续（集成&部署&交付）的区别与联系

  • DevOps，从三个维度改进！其中，最后一个最难！

  • Facebook移动端一周发布一次，咋搞？

  • “普朗克知识”和“司机知识”

  • 版本发布模式有几种？ 

  • 【读书笔记】MM of DevOps handbook

  • 软件无Bug交付有捷径，Just Do It!

  • 所有模型都是错的，但其中一部分是有用的。

  • DevOps，请吃下这9个馒头先~~~

  • 发布速度提升六倍，运维同学怎么说？

  • 小团队(30人以下)是如何获得持续交付能力的？

  • 【连载】持续集成九问

  • 做到无Bug按期交付，重点在这儿

  • 到底是谁说得对？

  • 如何制定项目计划

  • 如何做好迭代活动管理？

  • 换一种视角看，DevOps就是“开发与运维解耦”

  • 估算那点事儿，很简单

  • 有的放矢最重要

  • 一张图快速评估交付能力

  • 一张图带你了解“持续交付”和“DevOps”

  • 【连载(大结局)】DevOps：使持续交付成为可能！

  • 【连载】应用运维：为什么要排队上线？

  • 开发人员总是高估自己的能力

  • 建立部署流水线(pipeline)时，最先遇到的那些“坑儿”啊

  • 移动App发布后，质量成本高？看Esty如何应对发布质量

    • KEEP THE THREAD GOING

    更多来源文章

    3700条流水线怎么管？腾讯蓝鲸五年前的特性，恰好适配AI研发

    本文以3700条部署流水线的治理困境为切入点，分析UI配置模式在规模化下的短板，阐述Pipeline as Code如何实现配置版本化、校验前置和模板复用，并探讨其作为AI治理地基的适配性。读者将获得规模化配置治理的实战思路与借鉴建议。

    阅读全文