持续交付

解到了一本叫《Head First 设计模式》的书，才重新把 GoF 的书看了一遍，发现其实也没有想象中的难。

1. 接着在我完成了某个功能之后，那么我可能继续学习某个理论，用于支撑我的下

一步计划。

1. 在那之后，我觉得这一步可能也不是那么难，因为已经有了前面的基础。如果在

一步失败的时候，那么我们可能会继续寻找某些可靠的方案，又或者是理论支撑。

5.。。。

1. 直到有一天，我们来到了一个瓶颈的前面，现有的方案已经不满足我们的需求。对

于这个问题，我们可能已经没有一个更好的解决方案。于是，我们可能就需要创建一个轮子，只是在这时，我们不知道怎样去造轮子。

1. 于是我们开始学习造轮子。
2. ….

只有当我们保持一个学习的过程，才会让我们在这一步步的计划中不会退缩，也不能退缩。

持续交付

交付管道的建立和自动化是持续交付的基础

持续集成

更关注代码质量。持续集成是为了确保随着需求变化而变化的代码，在实现功能的同时，质量不受影响。因此，在每一次构建后会运行单元测试，保证代码级的质量。单

元测试会针对每一个特定的输入去判断和观察输出的结果，而单元测试的粒度则用来平衡持续集成的质量和速度。

1

持续集成的核心价值在于：

1. 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少

重复过程以节省时间、费用和工作量；

1. 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任

何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；

基于 Jenkins 快速搭建持续集成环境