结束语 | 越痛苦的事，越要经常做

王潇俊



该思维导图由 AI 生成，仅供参考

专栏终于写完了，痛苦的三个月终于结束了，我也终于可以长舒一口气了。
其实按理来说，写技术专栏，特别是你自己比较熟悉的领域，应该不至于那么辛苦。但就是这么巧，答应极客时间开始写专栏后不到一个月，我就作为技术合伙人加入了一个创业团队。每天要忙的事情真得好多，我再也不能随性地规划自己的时间了。
现在，我大概看了下我上传音频稿的时间，基本都在夜里 23 点以后。其中还有 20 篇，是在 24 点以后。也因此，导致我老婆曾经一度以为我创业的内容，是做夜间直播。
虽然，这个写作和录音的过程很痛苦（真的很痛苦，现在是凌晨 1 点 45 分，我在写结束语），但我最终坚持下来了，并因此收获了快乐与成长。而这些快乐与成长，都是源于尚未谋面的“你”。
我一直都在关注你给我的留言，并努力地去解答您提出的问题。当然，对于你对专栏的吐槽与不解，我也都历历在目。这些都时刻鞭策着我，要更多地分享自己的所知、所感和所悟，要能真正帮到你。
在这个专栏里，我和你一起分享了，持续交付的理念、概念、经验和实践，涉及到了持续交付中最重要和最核心的知识点。我还通过一个具体的系统搭建案例，手把手地带你搭建了一套持续交付系统。相信你也能从中获得一些你所期望的知识吧。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

这篇文章以“越痛苦的事，越要经常做”为题，作者分享了在持续交付领域的痛苦经历和成长体会。作者在专栏写作过程中遇到了种种困难，如需花费大量时间在夜间进行录音和写作，需要比架构师、开发人员、QA团队、运营人员和产品经理都更懂得多，以及需要承受压力和委屈等。然而，作者认为越痛苦的事情越要经常做，因为通过经历这些痛苦，可以锻炼自己成为“牛人”，并且建议读者在持续交付领域也要多去体验这些痛苦，以便事业顺利发展。作者还分享了在写作专栏过程中得到编辑的陪伴和帮助，表达了愿意成为读者的“教练”，并鼓励读者在持续交付的道路上继续努力。文章内容简洁明了，突出了持续交付领域的技术特点和成长经历，为读者提供了有益的启示。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《持续交付 36 讲》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(25)

最新
精选

webmin
前携程工员，在携程时一直关注我司的发布系统，个人感觉15年后的新发布系统是我在携程期间见到的我司做的比较好的几个系统之一。到新公司后，搭建CI/CD及相关系统时就凭着在携程用过的发布系统的印像，没有体系和理论支持，一个个点逐步建设，在这个过程中正好您在极客时间上开专栏，通过专栏补上了缺失的体系和理论，感谢您的布道和知识传播。最后如方便想咨询一下，携程开源的[Tars](https://github.com/ctripcorp/tars)，是否还会继续进行维护？
作者回复: 应该还是在维护的，不过没有什么特别新功能了，所以以修复bug为主
2018-10-05

5
洪少
最近有个疑惑，从版本控制和部署两个维度看，应用变更的部署和对应的数据库变更的部署，有没有必要拆分。换个表述是，一个需求产生应用和数据库表结构的变更，表结构的变更要不要单独的版本控制，对应也有独立的部署发布任务。是否有相关优秀实践。谢谢
作者回复: 确实是建议拆分两个版本的，解耦即带来复杂度上升，也会对治理带来好处，看具体情况吧
2018-12-26

3
roger
如果团队喜欢使用svn，还能愉快的和gitlab一样持续交付吗
作者回复: 当然也是可以的，只是部分特性不能支持而已
2018-11-19
2

zw
您好，请问:我们目前使用的是gitolite这个轻量级的工具，如果搭建这个持续平台，请帮忙评估一下，是否需要更换到gitlab这个上面来，谢谢!
作者回复: 主要还是看有没有二次开发的需求和对系统的熟悉程度，未必需要换的
2018-10-23


张健
老师，幸苦了～希望常回来看看
2018-10-04

7
Raymond吕
老师也要注意身体啊！从课程里收获到的三条金句共勉： “个人再强放在一个低效的环境下，也无力可施。” ”避免失败的最好办法就是经常失败。” ”越痛苦的事，越要经常做。”
2020-04-13

2
765
老师您好，今天学完了整个课程，收益颇丰，目前公司正在推荐持续交付，目前遇到两个问题想请教下老师。背景：基于SpringCloud的微服务+容器化的持续交付实践工具链：禅道，gitlab，Jenkins+SonarQube，Docker+Harbor，K8s 问题： 1、CD过程，目前想的是基于K8s的REST API封装一套基本部署中间件API，禅道调用Jenkins（Jenkins作为中转是为了后期可以解耦），Jenkins再通过API请求封装的中间件API实现部署。不知道这种方式是否有问题？ 2、代码分支策略的问题，基本就是选用特性分支开发的模式，为了保证交付镜像的一致性（测试+预发布+生产）。如果镜像正在测试过程中，master有新的特性合并，已经产生新的版本。这时候我正在测试阶段镜像该如何处理呢？期待老师的解答！
2019-04-01

2
猩猩
最近重新学习了一遍该课程，虽然课程中并不包含具体的技术细节，但是几乎涵盖了大多数持续交付中的场景和思想。不得不说团队规模越大，持续交付系统越复杂。想更深入的学习相关的技术细节，不知道有没有合适的课程推荐？
2021-07-19

1
luffy
一直觉得持续交付是很神秘的，通过这门课程对持续交付有了一定的理解，剩下的就是不断的实践了。
2019-05-06

1
夜空中最亮的星
最后一篇是亮点
2018-11-09

1

收起评论