持续交付的读书笔记

这是一篇关于持续集成的一些读书笔记，内容可能有些散乱，但是希望能尽可能保持内容的完整性。

关于迭代开发

读书笔记的开头写迭代开发而不是关于持续交付，是因为迭代开发是持续交付的最基本的条件，很多公司都声称自己做的是迭代开发，但实际上完全不是那么回事。迭代过程的最基本要求可以用如下几个规则来表述。

• 软件应该一直处于可工作状态，因为每次签入代码时，都回自动运行自动化测试套件，包括单元测试，组件测试以及端到端的验收测试。

• 每次迭代都能将软件部署到一个类生产环境中，并向用户演示（这样可以确保整个过程不但是迭代式的，而且是增量的）。

*迭代长度不超过两周。

使用迭代过程的理由有如下几个。

*如果按照业务价值来排功能优先级，你会发现，远在项目结束之前，软件就已经生效了。当然，即使我们已经完成了一些功能，也经常有一些很好的理由不发布新软件。但是，使用新功能的兴奋替代对项目成功的担忧，更能鼓舞士气，难道不是吗？

• 可以从客户或者出资人那里得到关于软件的反馈，比如什么需求被满足了，什么需求还需澄清或者修改。这也意味着，正在开发的功能的确是有价值的。可在项目开始时，没有人知道，他们真正要的是什么。

• 只有客户签收(sign off)后，需求才算真正完成了。定期给客户做软件演示是跟踪进度唯一的可靠方式。

• 保持软件随时可工作（因为你不得不做演示），这会让团队更有纪律性，以避免集成阶段时间太长，破坏原有功能的重构和失去焦点及方向感。

• 可能最重要的是，强调每次迭代结束后都能得到可部署到生产环境的代码。在软件项目中，这唯一真正有用的过程度量项，也只有迭代方法能提供这种方式。