最近在看的一本书叫《持续交付－－发布可靠软件的系统方法》，在看这本书之前，我曾在持续交付大会上当过志愿者，在这个大会上，更多被提及的都是持续集成的一些问题和难点，所以我是带着持续集成和持续交付有什么区别这个疑问在读这本书。
首先先介绍一下概念。
持续交付：频繁且有规律的发布可工作的软件。
持续集成：频繁的进行代码的集成。
虽然这本书叫《持续交付》，事实上，更多的也是在聊持续集成。但是我大概能够理解二者的区别了。我的理解是，持续集成关注的更多是在实现软件的层面上，而持续交付关注的是在向客户交付价值的层面上。对于持续交付来说，持续集成是一个基石，只有做到了持续集成，才能做到持续交付。而只有做到了持续交付，才是真正将持续集成的价值也传递出去。
书里最常提到的一句话：提前并频繁的做让你感到痛苦的事。对于开发者来说，很多时候，部署上线是一件很痛苦的事，因为部署上线很多时候是一件风险很高的事，要更新很多的功能。持续交付中提到的频繁，就是将这件大事，这些很多的功能拆小，每次上线一小点，当出现问题的时候，回滚就是一件容易的事，排查错误的范围也会变小，发布的风险也就由此降低，痛苦程度也会减弱。
这些都是很笼统的概念，这本书对于我来说就像是一本工具书，介绍了很多的方法如何从无到有的创建一个持续交付的流水线。目前我从这本书中学到的东西就是自动化，向各个环境部署代码可以自动化，验收测试可以自动化，配置各个环境可以自动化，非功能测试可以自动化，什么都可以自动化。
在读的时候难免会想到我所在项目组出现过的问题。我们曾出过这样一个问题，我们引用的第三方软件的账号组中某一个账号出了问题，这个第三方软件是一个账号出问题整个组都会被封。当时在生产环境把账号替换了，但是把其他几个环境漏掉了，结果在类生产环境跑的时候再次导致问题的发生。加上开发环境，共有四种环境，每次需要添加或者更改第三方软件配置时，都需要登录各个机子，在不同的模块目录下进行更改。人手工进行更改这种行为并不是一件可靠且可重复的事情，当出现问题的时候，无法追溯问题的发生。虽然目前这还是一个技术债，现在已经是在还的阶段，我们制定的解决方案就是只在一个地方保存这些配置，当部署发生的时候，自动将配置根据模块的不同进行分发。
目前还有一个在还的技术债是关于打包的，对于每个环境，都会打一个包，因为每个环境的配置不同。有的时候打包部署上相应的环境这一步会失败，由于某些文件或者配置的无端丢失。这个问题是在我看到书里有一段内容，讲的是在通过单元测试后进行打包，打完的这个包会在流水线上传递，一直到生产环境上线。之所以要一直传递这个包，而不是重新进行打包，是因为两次的打包的可能会有一定的偏差。而对应环境的配置就存在当前所在的环境上，通过引用即可。这样当在某一环境部署失败的时候，也可以很快速的定位到是环境还是程序的问题。这一部分的讲解当时启发了我，当我们几个开发在讨论到相关的技术债的时候，脑中自然想到的便是这个解决方案。
持续交付的内容还有很多，《持续交付》这本书也是我写读书笔记以来看的最痛苦的一本书，我看得很慢，虽然作者讲得很细，但是很多地方讲的很深，很多时候有点儿像工具书，相对来说例子要少一些，我的经验不多，能够记住的也不多，当我的经验再多一些的时候，再回来看看，大概能够感悟到更多的东西。
网友评论