剖析“持续交付”：五个核心实践
来源：互联网 发布：安卓变女声软件 编辑：程序博客网 时间：2024/05/17 03:26
原文发表于 InformIT
持续交付 是一种软件开发策略，用于优化软件交付流程，以尽快得到高质量、有价值的软件。这种方法让你能更快地验证业务想法，通过直接在用户那里进行试验，做到快速迭代。 尽管《持续交付》一书主要讲的是工程实践，但持续交付的概念对整个产品交付过程都有重大意义，包括对特性的”fuzzy front end”、设计和分析的意义。
持续交付的一般性原则如下：
与其设计一大堆特性，再策划一个持续数月的版本发布，不如持续不断地尝试新想法，并独立发布给用户。通过充分思考，即便很大的特性或者大范围的变更，也能够通过一系列小步骤得到更快反馈，而且一旦你认为有必要停下来的话，可以随时停下来。利用 跨功能团队 在几小时或几天内交付这些小且增量式的功能，就能比竞争者有更多的创新，将投资回报最大化。
持续交付五个关键实践，为你建立一个从猜测到持续反馈的最有效途径，它们就是：
- 从最小可行产品（MVP）开始——Start with a minimum viable product
- 衡量新特性的价值——Measure the value of your features.
- 做恰好充分的预先分析——Perform just enough analysis up front.
- 少做——Do less.
- 用户故事中要包括特性开关——Include feature toggles in your stories.
Continue reading
为什么要做持续部署？
本文是《Lean Startup》一书的作者Eric 在2009年发表的一篇博文，他是IMVU的创始人之一。文中没有讨论如何做持续部署，而是讨论了一个更关键的问题：“IMVU为什么要做持续部署？”这也充分地表达了他关于“Learning from production and customer”的观点。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
在我所倡导的Lean Startup所有实践中，没有哪个实践比持续部署更有争议（持续部署是指：让公司在几分钟内发布软件的过程，而不是几天或几个月才发布一次）。我之前所在的一个创业公司IMVU使用这个流程，平均每天部署50次。这也引发了一些争论，有些人说：这种快速发布流程会导致低质量的软件，或者阻碍公司的创新。假如我们能够接受由客户来评判，而不是专家的判定，那么，我想这些说法就很容易消散了。一个更为常见，且更为困难的问题是：如何回答那些只想知道这种持续部署是否可以用于他们自己的业务、行业或团队的人们。Continue reading
LinkedIn:移动APP开发中的自动化测试与持续部署流水线
最近，有很多人问我关于“移动应用开发中的自动化测试如何做？持续集成和部署流水线从哪里开始？”的问题，觉得有必要写一写。恰好这个周末在家无意间看到Linkedin的做法，觉得非常有意思，尤其是截屏做对比测试的做法，在移动应用中比较少见， 在这里与大家分享。原文地址在这里。
Continue reading
围绕最终交付物，而不是角色来组织软件交付活动
——持续交付与跨功能团队
在实施持续交付的过程中，我们很容易聚焦于自动化和工具，因为作为起点，它们通常是最容易做的。然而，持续交付的成功实现，还依赖于根据最终交付物而对组织结构所做的优化。对于持续交付来说，最大的障碍是依据角色和分层结构来组织团队，而非业务上的最终交付物（即产品或服务）。
Continue reading
持续集成案例分析系列(1)——大规模项目团队持续集成历程
这篇文章是我在两年前写的，记录了一个150+人的软件团队（最多时近200人）如何在一个庞大的遗留系统上，通过逐步建立一个持续交付部署流水线，从而达到频繁发布的状态。最终在该团队的持续交付基础设施中，共有260台服务器用于构建、测试和部署（几乎全部是虚拟机）。而这个产品也可以每六周发布一次。
Continue reading
用veewee创建vagrant的虚拟机
感谢larrycai的投稿。
原文链接：https://github.com/larrycai/blog/blob/master/cn/veewee_create_vm.mkd
简介
虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，会在软件开发中起到极大作用。
在上一篇vagrant和jenkins的文章中我们说到了vagrant这个工具，你必须要先有一个盒子：vagrant box，它是vagrant对virtualbox虚拟机的进一步封装。将virtualbox虚拟机转变成vagrant的盒子有点麻烦，可以参见vagrant的说明，所以，大家都是找一个现成的盒子来用。
但是，没有更好的办法了吗？现在网络的开放精神真是强大，你能想到的一般都存在了，它就是我要介绍的veewee，它的功能就是从你的ISO光盘开始，准备好你需要的vagrant虚拟机（盒子）。
Continue reading
《持续交付》封面上的故事——福斯铁路桥
不知道有多少人把《持续交付》一书的前言看全了。最后一部分讲的是福斯铁路桥（本站Logo上的这座美丽的桥），并把它和软件做类比。现摘录如下：
福斯铁路桥是英国第一座使用钢铁建造的大桥。其钢铁使用最新的西门子马丁平炉工艺制造，并由在苏格兰的两个钢铁厂和威尔士的一个钢铁厂交付。钢铁是以管状桁架的形式运送的，这是英国首次使用大规模生产的零部件组装桥梁。与早期的桥梁不同，设计师John Fowler爵士，Benjamin Baker爵士和Allan Stewart计算了建筑压发生率，以便减少后续的维护成本，并计算了风压和温度对结构的影响，而这很像软件开发中的功能需求和非功能需求。他们还监督了桥梁建设，以确保这些要求都能得到满足。
当时有4600名工人参与建造该桥，其中不幸死亡约一百人，致残数百人。然而它仍是工业革命的一个奇迹，因为1890年建成时，它是世界上最长的桥，而到了21世纪初，它仍是世界第二长的悬臂大桥。就像长生命周期的软件项目一样，这座桥需要持续维护。这已在设计时考虑到了，大桥配套工程中不但有一个维护车间和场地，而且在Dalmeny车站还有一个50个房间的铁路“聚居点”。据估计，该桥的使用寿命还有一百多年。
使用vagrant+jenkins来管理虚拟机的技巧
感谢larrycai的投稿。
简介
虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，显然会在软件开发中起到极大作用。
在《持续交付》第十一章（11.7.1）中就提到了虚拟机环境的管理。如下图
它描述的是在你的持续集成的Jenkins CI服务器（以下简称jenkins）中，需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中，启动需要的各种类型虚拟机，而不是每个都重新安装（省时），完成测试，产生报告后，也快速消失（省钱）。
让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。
Continue reading
《持续交付》中文版已上架销售，欢迎对译文进行意见反馈。
《持续交付》中文版已于2011年10月17日上架销售。
该书由Jez Humble 和 Dave Farley历时三年完成，
Martin Fowler为该书作序，并称其为“2010年最重要的持续书籍”，
同时，在2011年8月获得 “Jolt 杰出奖”。
从下面网站均可购得：
- 中国互动出版网
- 当当网
- 卓越亚马逊
如果您在书中发现有些地方翻译欠妥，您有多种渠道反馈建议。
- 请在下面直接回复即可。内容包括：问题所在页号、原文句子，以及您的建议。
- 点击这里，进入图灵社区的《持续交付》专栏勘误。
- 直接邮件给译者，邮箱是：qiaoliang.email@gmail.com
谢谢！
持续交付成熟度模型更新，新版本v1.2发布
《持续交付》一书中提供的“持续交付成熟度模型”是1.0版本。
这是经过再次调整的改进版，更具有指导性和可操作性。
使用说明：
建议使用该模型进行现状分析，发现改进点，不建议将其作为绩效衡量的标准。
一、七个维度
它们分别是：
1. 持续集成（Continuous Integration)
2. 环境与部署（Environments and Deployments）
3. 可视化与可追踪性（Visibility and Traceability）
4. 测试（Testing）
5. 数据管理（Data Management）
6. 配置管理（Configuration Management）
7. 组织协调性（Organisational Alignment）
二、每个维度又分成五个级别，它们分别是：
一级：阻碍级（Regressive）
二级：可重复级(Repeatable)
三级：可定义级
四级：可定量级（Quantitatively managed）
五级：优化级（Optimizing）
其中，持续集成维度的五个级别分别是：
一级：阻碍级（Regressive）
1. 软件的构建过程是手工的。
2. 构建过程冗长，而且其中的主要步骤常常出错。
二级：可重复级(Repeatable)
1. 在开发人员的代码上进行定期的自动化构建和单元测试。
2. 利用自动化过程，能够从源控制中重新生成任意一个构建版本。
3. 开发人员的提交频率是不定的。
三级：已定义级
1. 每次提交都会触发构建和各类测试。
2. 公共工具集中的脚本或工件得到重用。
四级：可定量级（Quantitatively managed）
1. 构建数据度量项被收集，高度可视化，并执行相应的改进活动。
2. 构建失败不会没人管。所有团队成员至少每天提交一次。
3. 尽可能在最后时刻（即将发布时）才拉发布分支。
五级：优化级（Optimizing）
1. 随着可以从主干上拿到已全面集成且生产环境可部署的构建版本。
2. 关注点是：随着对代码质量信心不断提交，能够进行更加频繁的提交。
环境与部署的五个级别分别是：
一级：阻碍级（Regressive）
1. 手工准备环境，无适当方法管理环境冲突。
2. 手工部署软件。
二级：可重复级(Repeatable)
1. 环境已被定义，并可自动化地准备和控制。
2. 部署操作是手工和自动化相结合才能完成。
三级：可定义级
1. 开发和测试环境是全面自动化且自服务的。
2. 已具备 “点击按钮即可向任意环境进行部署”的能力。
3. 为了完成自己的工作，每个人都有相应权限访问并操作相应的环境。
四级：可定量级（Quantitatively managed）
1. 协调的部署管理。
2. 发布计划自动产生。
3. 对所有的失败进行根因分析。
4. 回滚流程被脚本化，并被管理起来。
5. 建立了环境和系统健康状态指示板（Dashboard），其上显示的数据被监控和报告。
五级：优化级（Optimizing）
1. 环境的准备是全自动化的。
2. 已具备根据需求快速重建完整环境和基础设施的能力。
3. 端到端的业务度量项被监控。
这里可以下载全部。
- 剖析“持续交付”：五个核心实践
- devops [持续交付实践] 开篇：持续集成&持续交付综述
- 大象如何跳舞-支付宝持续交付实践
- 大象如何跳舞-支付宝持续交付实践
- 云端基于Docker的微服务与持续交付实践
- 云端基于Docker的微服务与持续交付实践
- 持续交付之应用标准化模型与实践
- 云上应用docker化持续交付实践
- DevOps实践-打造自服务持续交付-上
- DevOps实践-打造自服务持续交付 -下
- 持续交付实践之helloCD-jenkins+dotnet项目
- 基于Docker持续交付平台建设的实践
- 基于Docker持续交付平台建设的实践
- 基于Docker持续交付平台建设的实践
- 基于Docker持续交付平台建设的实践
- 基于Docker持续交付平台建设的实践
- 持续集成与持续交付
- 持续交付模式
- ashx中使用HttpContext.Current.Session ，出现未将对象引用设置到实例
- 遍历字符串应该取出字符
- NodeJS 安装Express
- 10 个你需要了解的项目管理工具
- 第六章：Android组件之间的信使Intent
- 剖析“持续交付”：五个核心实践
- 图片上传到数据库
- javascript数组操作大全，数组方法总汇
- db2 全量+增量备份数据
- c++builder 动态创建控件及销毁
- MFC程序和Win32程序的关系
- mysql 记录
- Trustee
- 用过的linux命令
