|
|
|
|
|
# 持续交付专栏特别放送 | 高效学习指南
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是王潇俊。
|
|
|
|
|
|
|
|
|
|
|
|
“持续交付36讲”专栏，全部的正文部分已经更新完毕了。这里，我总结了一份【高效学习指南】，希望交付给你的是：我在创作这个专栏前后的想法变化，以及怎么才能从这个专栏中收获更多。
|
|
|
|
|
|
|
|
|
|
|
|
而不管你是刚刚订阅这个专栏，还是已经学完了全部专栏文章，亦或是只看了其中几篇而未能继续坚持下去，我都相信这篇【高效学习指南】，可以帮你更上一个台阶。
|
|
|
|
|
|
|
|
|
|
|
|
## 关于持续交付的知识图谱
|
|
|
|
|
|
|
|
|
|
|
|
更新完了37篇正文，我也曾想结合自己的经验，希望可以梳理出一个关于持续交付的知识图谱，帮助你了解持续交付的知识边界。但，我思索再三，几次提笔又放下，最终还是放弃了。因为，我真的无法界定这个知识图谱的边界，持续交付涉及到的内容实在是太多了。
|
|
|
|
|
|
|
|
|
|
|
|
如果我说Java是一种技术，你应该不会反对吧？而我说数据结构也是一种技术，算法也是，架构也是，你照样不会反对吧？
|
|
|
|
|
|
|
|
|
|
|
|
如果我又说与产品相关的内容，更像是一种管理，是对技术成果的一种管理，这看起来也没什么问题，对吧？
|
|
|
|
|
|
|
|
|
|
|
|
那么，我们口中谈论的“持续交付”到底是什么呢？技术？管理？流程？方案？经验？还是实践？
|
|
|
|
|
|
|
|
|
|
|
|
持续交付好像和这些都沾边，是不是？但，肯定也不是说涉及到了这些内容的方方面面。所以，我决定不再归纳这个专栏的知识图谱了。
|
|
|
|
|
|
|
|
|
|
|
|
但是，我相信上面的这些问题，却给了你也给了我，第一个也是最重要的一个学习持续交付的建议，即：
|
|
|
|
|
|
|
|
|
|
|
|
**在学习前，你首先要确定自己的学习目的，是想了解别人的经验，还是要掌握普适的流程，又或是要学习其中的个别技术。**
|
|
|
|
|
|
|
|
|
|
|
|
我始终相信，只有确认了目的地，才能找到所谓的“捷径”。否则，“持续交付”在你我的眼中，终是“一锅大杂烩”，而实施起来就是毫无头绪。
|
|
|
|
|
|
|
|
|
|
|
|
## 关于理论与实践
|
|
|
|
|
|
|
|
|
|
|
|
其实关于“理论与实践”，也是一个需要辩证看待的问题。到底是先掌握理论，还是应该先去实践，这同样是个见仁见智的问题吧。
|
|
|
|
|
|
|
|
|
|
|
|
就像有些读者，在专栏里面留言说“缺少干货和实践”。对这个问题，我不置可否。因为，我始终认为先理解持续交付的基础知识，再动手搭建一套自己的系统，是个水到渠成的事儿。所以，我就把整个持续交付体系的搭建，放在了专栏最后的“实践案例”系列中。
|
|
|
|
|
|
|
|
|
|
|
|
所以，如果你觉得有必要的话，也可以先看最后“实践案例”的系列文章，然后在搭建持续交付体系过程中遇到具体问题时，再去前面的基础文章中寻找答案。或许，这种方式对你来说会更有感觉。
|
|
|
|
|
|
|
|
|
|
|
|
但是，我并不太提倡这种做法。就像你在学习Java时，一定是先看到“类是对对象的抽象”这种拗口、抽象的定义一样，搭建一套持续交付体系，也需要先去理解一些技术本质的内容。所以，**在我看来，先看懂理论，再结合着实践回顾，才是最理想的学习方式，才会事半功倍。**
|
|
|
|
|
|
|
|
|
|
|
|
另外，你可能会纠结于，我到底应该先学会使用基础工具，还是应该先去掌握解决问题的思路。那么，在我看来，工具也好，实现也罢，随着你的成长和技术发展，最终都不会成为问题的核心，就好像Docker一出现就瞬间解决了以往的很多技术难题一样。
|
|
|
|
|
|
|
|
|
|
|
|
所以，解决问题的思路和方法，才是我最想分享给你的。因为，即使这些思路、方法过时了，你也能从中领悟到它们的来龙去脉，以及为什么会演变出新的思路、方法。这，就是温故而知新。
|
|
|
|
|
|
|
|
|
|
|
|
## 关于小团队与大团队
|
|
|
|
|
|
|
|
|
|
|
|
或许，你也像大多数人一样，一直在纠结一个事情，小团队和持续交付的关系。
|
|
|
|
|
|
|
|
|
|
|
|
其实在我看来，持续交付体系的建立和团队的大小没什么直接关系。但是，持续交付ROI却与团队大小有直接关系。
|
|
|
|
|
|
|
|
|
|
|
|
我最近也离开携程创业了，目前技术团队只有5个人，主要产品是基于微信小程序。微信小程序的发布也有一套审核流程，所以我针对这个过程，借用了一些Hook的能力，做了CD。但是，最近也有一家上千人的大厂，询问我关于持续交付的问题。他们的问题是，团队连续搞了很长时间，最后却连基本工具也没顺利搭建起来。
|
|
|
|
|
|
|
|
|
|
|
|
所以说，团队大小并不会限制你的持续交付能力，你也无需再纠结于自己的团队大小而无法实施持续交付的问题了。
|
|
|
|
|
|
|
|
|
|
|
|
但从另一方面来看，任何技术、流程和工具，在大团队中的收益一定会比小团队要好。其实，这是必然的，因为受益的群体大了嘛，而且能切实地解决更多复杂问题，更明显地提高协作效率。而这些，又恰恰是一个大型研发团队最需要解决的问题。
|
|
|
|
|
|
|
|
|
|
|
|
所以，大团队对持续交付的关注度要远远高于小团队。
|
|
|
|
|
|
|
|
|
|
|
|
## 推荐一些参考资料
|
|
|
|
|
|
|
|
|
|
|
|
有不少的读者，希望我推荐一些持续交付方面的参考资料。因此，我稍作整理，把我觉得最最值得推荐的参考资料列在了这里：
|
|
|
|
|
|
|
|
|
|
|
|
1. 《持续交付：发布可靠软件的系统方法》，是一本必读书籍。
|
|
|
|
|
|
|
|
|
|
|
|
2. 《凤凰项目》，以小说的方式介绍了一些持续交付和DevOps的理念，非常有趣。
|
|
|
|
|
|
|
|
|
|
|
|
3. 官方文档。这里我有一个建议，就是在学习和运用开源系统和工具时，要先通读官方文档。这些文档都是作者心血和智慧的结晶，从中你定可以收获颇丰。所以，我建议你能把阅读官方文档形成一个习惯。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里，我再啰嗦一句，**持续交付体系中涉及到很多开源软件，如果你想做好持续交付，那就一定要去理解它们，而不只是使用它们。**
|
|
|
|
|
|
|
|
|
|
|
|
## 我讲的不一定都是对的
|
|
|
|
|
|
|
|
|
|
|
|
最后，关于持续交付，我还有一个非常重要的建议，要分享给你：我们通常在网络上看到的与持续交付相关的分享，都是经验与实践。
|
|
|
|
|
|
|
|
|
|
|
|
那么，我们就需要认清这么一个现实，既然是经验与实践，那就很可能要受到当时情况和条件的限制：这个经验与实践，也许在当时是最优的，但未必现在还是最优的；也许在此处能正常工作，但换一处未必能行。
|
|
|
|
|
|
|
|
|
|
|
|
但是，你也不要因此而悲观。虽然我不能告诉你怎样做一定是对的，但是我分享了怎样做一定是错误的。这些一定错的部分，也可以说是我们进行持续交付的一条底线吧。
|
|
|
|
|
|
|
|
|
|
|
|
而且，如果你有机会可以修正和弥补那些不那么正确或不那么适用的部分，将可以使你自己的持续交付过程变得更好。
|
|
|
|
|
|
|
|
|
|
|
|
所以，最后，我希望我的专栏能给你带来不同的思考。思考出你自己的观点和解决方案，并付诸实施，这才是最棒的。
|
|
|
|
|
|
|
