阅读之后，对你有帮助，那就点个赞再走吧

今天，我和你一起分享了移动客户端持续交付流水线的几个详细点：利用发布快车的发布模式，可以有效地管理客户端的版本，保证研发工作按节奏持续向前进展；采用带发布分支的 GitLab Flow 配合发布快车的模型，可以使其做到物理落地；发布快车本身也有一些弊端，比如对 Master 分支的合并，检查不够严格的话，会拖累项目进度，因此我们采用改造构建通道的方式，避免了这个问题的产生；移动 App 的发布，有其独特的流程，通常是先内测，后正式发布；但其流程相对固定，且容易自动化。

可见，做好项目信息管理在移动 App 的持续交付中尤为重要，而在后端服务的持续交付中却没那么受重视了，这也是移动 App 的持续交付体系与服务端的一大不同点。也就是说，除了从技术角度来看，移动 App 的持续交付会存在依赖管理的内容外，从项目角度来看，也常常会存在功能依赖和功能集成的需要。我在专栏的第四篇文章《一切的源头，代码分支策略的选择》中，和你分享了各种代码分支策略（比如，Git Flow、GitHub Flow 和 GitLab Flow 这三种最常用的特性分支开发模型）的思路、形式，以及作用。

今天我通过三个实际工作中的例子，和你分享了应该如何利用持续交付中产生的数据。首先，你可以利用与业务量相关的数据模型来衡量持续交付系统的稳定性;然后，在日常的数据分析中，除了要抓住主要数据的大趋势外，你还要关注那些异常的个性数据，它能帮你及早地发现问题;最后，通过日常的数据分析，你也能发现持续交付流程上的一些问题，并协助团队一起改进。当然，这只是三个比较突出的例子而已。在实践中，实施持续交付的过程中还有很多数据需要我们关注。我也一并把这些数据分成了三类，包括:1. 稳定性相关指标;

云计算的弹性能力，可以帮助我们改善环境管理模块的能力，使得环境管理的方式更加灵活。比如，原先一个测试子环境的生命周期往往与某个功能研发或是项目研发不一致，会提前准备，或是多次复用;又或者由于资源紧缺的原因，测试环境只能模拟部分实际环境:另外还会有一些环境被作为公共的资源一直保留，从不释放。这些问题都增加了环境管理的复杂度。现在，有了云计算平台的强大能力，我们完全可以打破这些限制，将环境的生命周期设计得与项目生命周期一致，每个项目或每个功能都可以拥有自己独立的测试环境;

平台化”这个词，你应该已经听到过很多次了吧。特别是互联网领域，我们都爱谈论平台化。那么，“平台化”到底是什么意思呢?其实，早在 20 世纪 70 年代，欧洲的军工企业就开始利用平台化的思维设计产品了。当时的设 计人员发现，如果分别研制装甲车、坦克和迫击炮的底盘，时间和金钱成本的消耗巨大。因为这些武器的底盘型号不同，所以它们所需要的模具、零件也就不同，除了要分别设计、制造、测试、生产外，还要花费巨额成本建设不同的生产流水线，而且各底盘的保养和使用方式不同，需要进行不同的人员培训。

我以提出问题 - 分析问题 - 解决问题的思路，和你展开了今天的分享内容。首先，我和你分享了自动化回归测试会遇到的三个难题:测试数据的准备和清理、分布式系统的依赖，以及测试用例的高度仿真。我们可以利用 Mock 技术(即通过代理的方式模拟被依赖的对象、方法或服务的技术)，通过 不同的框架，解决自动化回归测试的前两个问题:基于对象和类的 Mock，解决一个应用内部依赖的问题;基于微服务的 Mock，解决应用与应用之间外部依赖的问题。

顾名思义，破坏性测试就是通过有效的测试手段，使软件应用程序出现奔溃或失败的情况，然后测试在这样的情况下，软件运行会产生什么结果，而这些结果又是否符合预期。这里需要注意的是，我们需要使用的测试手段必须是有效的。为什么这样说呢，有两点原因：第一，破坏性测试的手段和过程，并不是无的放矢，它们是被严格设计和执行的。不要把破坏性测试和探索性测试混为一谈。也就是说，破坏性测试不应该出现，“试试这样会不会出问题”的假设，而且检验破坏性测试的结果也都应该是有预期的。

在分享和你分享代码静态检查实践这个主题时，我分享了近五年国内的大型互联网公司在持续交付实践中摸爬滚打的经验。从这五年的发展实践中，我们可以清楚地看到，越来越多的研发团队把静态检查作为了一个不可或缺的环节，这也确实帮助研发团队提升了代码质量。当然，机器是死的，人是活的，我们千万不要过分迷信静态检查的结果，还要时刻擦亮眼睛，看看是否存在误报等问题。

今天，我围绕着灰度发布的最后一个过程:监控，展开了这次的分享。因为我们这个专栏要解决的主要问题是持续交付，所以我并没有过于详细地阐述如何设计一个监控系统，而只是为你介绍了监控体系的一些基本概念，以及一些与持续交付、持续部署相关的问题。首先，我介绍了监控的几种分类，以及分别可以采用什么方式去采集数据:1. 用户侧监控，可以通过打点收集，或者定期采集日志的方式进行数据收集;2. 网络监控，通过模拟手段或定期采样进行收集;3. 业务监控，需要定义正确的指标以及相匹配的采集技术，务必注意实时性;

因为发布系统最终服务的对象是业务应用，所以发布系统的设计除了考虑用户体验，核心架松外，还要注意业务、系统架构对发布系统的影响，并且要合理利用业务、系统架构的能力，去完善发布系统的设计。业务、系统架构对发布系统的影响，主要体现在是选择单机单应用还是单机多应用、选择增量发布还是全量发布这两大方面。在这里，我的建议是简单的才是最好的，即采用单机单应用的部署架构;对于后台应用，以及发布非常频繁的应用来说，全量发布更直接，更容易达成版本控制并做到快速回滚。

我今天分享的主题就是，从后端系统设计的角度，来看看一套发布系统的核心架构和功能应该如何设计。我以携程目前使用的发布系统为例，从发布系统的架构、核心模型、发布流程及状态流转三个方面，展开了今天的分享。首先，高效的发布系统架构应该是清晰的、健壮的、低耦合的，携程在经历各种迭代后，采用了 以 Protal、Controller、Roll Engine、Salt Scripts 为核心的分层架构。...

一路看下来，不知道你是否已经发现，整篇文章的 6 个章节，恰好能用 1~6 这六个数字串接提 炼，我也正是希望这种形式能够加深你对发布系统产品设计的概念理解。这里，我们再一起简单 回顾一下吧。1 张页面展示发布信息，且仅有 1 张页面，展示发布当时的绝大多数信息、数据和内容，这个页 面既要全面，又要精准。2 个操作按钮简化使用，即页面上除了“回滚”按钮常在外，最多同时展示 2 个操作按钮。目的 是要降低发布系统的使用难度，做到“谁开发，谁运行”。...

首先，我分享了“不可变”模型的概念，以及它的由来，介绍了三个非常有价值的模型:发散模型、收敛模型和一致模型。其次，我解释了为什么“不可变”如此重要的原因，也就是重复发散到收敛过程无法解决的三个问题:顺序问题、频率问题和蝴蝶效应。最后，我针对“不可变”及容器，提出了持续交付面对的新问题，即:每一次变更都是一次发布，每一次发布都是一个独立的镜像的启动。...

无论是为新需求添加的代码，还是静态配置的变更，线上应用的任何变动都要经过发布这道工序才能最终落地，完成交付。通常，发布意味着应用重启、服务中断，这显然不符合如今系统高可用的需求。同时，软件工程和经验也告诉我们，世界上不存在没有 Bug 的代码，即便经过详尽细致地测 试，线下也很难百分之一百地复制线上的环境、依赖、流量，更难穷举千变万化的用户行为组合。于是，发布变更，在许多时候是一件被标记为“高风险系数”的工作，工程师和测试人员经常在深夜搞得筋疲力尽，甚至焦头烂额。...

我们允许用户在编译后的代码包内放入包含自定义环境脚本的 .paas 目录(这是一个自定义的隐 藏目录)，来满足用户对环境的个性化需求。这个.paas 目录中，可能会存在 build-env.sh 和 image-env.sh 两个文件，分别运行于构建代 码和构建镜像的过程中。其中，build-env.sh 是在构建代码之前运行，image-env.sh 是在构建镜像的时候插入到我们规 范的 Dockerfile 中，从而被打到容器内部。...

在虚拟机时代就有镜像的说法，当我们创建一个虚拟机时，通常会去网上下载一个ISO格式的虚拟机镜像，然后经过VirtualBox或者VMware加载，最终形成一个包含完整操作系统的虚拟机实例。而容器镜像也是类似的意思，只不过它不像虚拟机镜像那么庞大和完整，它是一个只读的模板，一个独立的文件系统，包含了容器运行初始化时所需要的数据和软件，可以重复创建出多个一模一样的容器。容器镜像可以是一个完整的Ubuntu系统，也可以是一个仅仅能运行一个sleep进程的独立环境，大到几G小到几M。而且。...

我主要介绍了几种流行的持续集成工具，以及基于Jenkins的高可用构建系统的一些基本设计理念和我们系统的演变过程。1.通常建议使用成熟的CI产品(比如，TravisCl、Circle CI、JenkinsCI)来作为平台的基础;2.虽然这些CI工具是成熟产品，但面对日新月异的技术需求，高可用和伸缩问题还是要自己解决;3.通过请求分发等设计，可以实现Master节点的横向伸缩及高可用问题;4.利用容器技术，可以解决Salve节点的弹性伸缩和资源利用率问题。...

Maven Enforcer 插件提供了非常多的通用检查规则，比如检查 JDK 版本、检查 Maven 版本、 检查依赖版本，等等。下图所示就是一个简单的使用示例。上述的配置会在构建时(准确的说是在 validate 时)完成三项检查:requireMavenVersion 检查 Maven 版本必须大于 3.3.9;requireJavaVersion 检查 JDK 版本必须大于等于 1.9;requireOS 检查 OS 必须是 Windows 系统。...

流程成本主要包括沟通成本和测试成本两个方面。沟通成本每增加一套环境，你都需要考虑团队成员如何在新环境上沟通协作。谁在占用，何时退出这些信息，你都需要第一时间告知团队。当环境的数量变得非常多以后，做好这些事的难度就很大了。测试成本在开发环境，集成测试环境，验收测试环境，预发布环境，生产环境这样的结构下，核心功能的测试流程就至少会执行五次。每引入一套新的环境，测试流程都会变得更加复杂。我们究竟需要多少套环境，这个问题的答案应该是这样的https。......

我介绍了五种常见的构建提速的方式，分别是:1.升级硬件资源，最直接和粗暴的提速方式;2.搭建私有仓库，避免从外网下载依赖;3.使用本地缓存，减少每次构建时依赖下载的消耗;4.规范构建流程，通过异步方式解决旁支流程的执行;5.善用构建工具，根据实际情况合理发挥的工具特性。然而，每个公司持续交付的构建流程不太一样，面临的问题与挑战也都不太一样，所以在优化前，一定要先了解问题原因，再对症下药。...

在传统模式下的开发到部署流程是这样的:1. 在本地电脑上安装开发应用所需要的库文件、扩展包、开发工具和开发框架，完成开发工 作;2. 本地开发完成后，将开发好的应用部署到测试环境进行测试;3. 一切就绪后，再把应用部署到生产环境。但问题是，你该如何保证开发、测试和生产这三套环境，甚至更多套环境是完全一致的呢?再有就是，环境的变更问题，虽说“百分之九十九的故障是由变更导致的”是一句废话，但也是一句实话，你又该如何确保每套环境的变更是一致的呢?而容器的出现，似乎解决了这些问题。......

对于如何快速搭建一套环境，我从虚拟机环境准备、应用部署流水线和环境变更，这三个方面给你总结了一些常见问题和原则:1. 可以使用虚拟机资源池，提升获取机器资源的速度;2. 合理打造并行的应用部署流水线，是进一步提升环境创建速度的方法;3. 利用配置等方式快速达到环境变更需求，可以再次有效地提升整个环境部署的效率。...

很多人分不清配置和配置管理，但其实它们是完全不同的概念。配置管理:是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。它的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期的各个阶段都能得到精确的产品配置信息。配置:是指独立于程序之外，但又对程序产生作用的可配变量。也就是说，同一份代码在不同的配置下，会产生不同的运行结果。从上面的定义中，你可以看到配置和配置管理有着本质上的不同:配置管理服务于软件研发过程，而配置则服务于程序本身。...

我主要围绕环境配置的问题，讲了它的内容和一些特性，以及简化和优化的一些方案。一定要意识到，环境配置是非常复杂的，直接影响你的环境治理能力，而环境治理能力又直接影响着持续交付的能力。但是我们还是可以通过标准化、约定、自描述等方式去简化和优化环境配置工作。我们的目标是，让环境自己能说话。...

在和你分享什么是好的测试环境前，建议你先思考一下开发环境、功能测试环境、验收测试环境、预发布环境这四种测试环境形成的原因是什么，这样有利于你更好的理解好的测试环境的含义。首先，搭建测试环境的目的是保证最终交付的软件质量，但每套测试环境的用户并不完全一样1.开发环境的用户是开发同学;2.功能测试环境的主要用户是测试同学;3.验收测试环境的用户是产品经理和测试同学;4.预发布环境的使用者是测试同学，但收益者却是运维同学。而每种角色对于产品研发流程中的需求也是不同的1.开发同学关注研发效率;...

我介绍了由6人组成的“两个披萨”团队代码管理的实践，通过周一到周五的具体活动，你可以看到采用特性分支开发的团队是如何创建分支、集成分支和删除分支的，希望能对你的日常工作也有所帮助。httpshttps。...

在我正式开始今天的分享前，先给你讲两个核心概念1.包回滚是指，线上运行的系统，从现在的版本回滚到以前稳定的老版本。2.代码回滚是指，Git分支的指针(游标)，从指向当前有问题的版本改为指向一个该分支历史树上没问题的版本，而这个版本可以是曾经的commit，也可以是新建的commit。......

软件工程是多人合作的结果，我们在开发软件的时候经常会使用一些别人编写好的，比较成熟的库。比如，早期的前端开发用到了iQuery库，那么通常的做法是去官网下载一个最新版本的jQuery，然后放在自己本地的项目中。对于简单的前端项目来说，这样可以简单粗暴地达到目的。但当项目越来越庞大，除了jQuery之外，你还会依赖一些其他的第三方库。比如Bootstrap与Chosen，这两个流行的前端库也都依赖jQuery，如果这些第三方库依赖的jQuery版本一致还好，但大多数情况并没有这么乐观https。......

今天，我主要给你介绍了各种代码分支策略的特性。你应该已经比较清晰地理解了“主干开发”和“特性分支开发”两种策略的各自特性1.“主干开发”集成效率高，冲突少，但对团队个人的开发能力有较高要求;2.“特性分支开发”有利于并行开发，需要一定的流程保证，能保证主干代码质量。相信在没有绝对自信能力的情况下，面对绝大多数的场景，企业还是会选择“特性分支开发”的策略。所以，我给你介绍了几种主流的特性分支方法，并对比了各类策略的优劣，以及它们适用的场景。httpshttpshttpshttps。......

今天，我和你一起回顾了DevOps产生的历程。同时，也顺便带你回顾了一下爱打盹儿的持续交付。我希望通过这篇文章，你可以理清持续交付和DevOps的关系1.DevOps的本质其实是一种鼓励协作的研发文化;2.持续交付与DevOps所追求的最终目标是一致的，即快速向用户交付高质量的软件产品3.DevOps的概念比持续交付更宽泛，是持续交付的继续延伸;4.持续交付更专注于技术与实践，是DevOps的工具及技术实现。......

今天，我和你分享的主题是影响持续交付的因素，为了便于你理解，我将其划分为人(组织和文化)事(流程)物(架构)三个方面1.组织和文化，是最重要的因素，是持续交付推进的基础;2.流程因素，实施持续交付也是一次流程改造之旅;3系统架构,与持续交付相互影响，但技术可以解决一切问题部署架构，千万不要失败在“最后一公里”，这部分你也需要重点关注。.........

接下来，我给你提炼一下今天内容的要点。持续交付的价值不仅仅局限干简单地提高产品交付的效率，它还通过统一标准，规范流程，工具化、自动化等等方式，影响着整个研发生命周期。持续交付最终的使命是打破一切影响研发的“阻碍墙”，为软件研发工作本身赋能。无论你是持续交付的老朋友还是新朋友，无论你在公司担任管理工作还是普通的研发人员，持续交付都会对你的工作产生积极的作用。https。.........