最近重新学习了一遍该课程，虽然课程中并不包含具体的技术细节，但是几乎涵盖了大多数持续交付中的场景和思想。不得不说团队规模越大，持续交付系统越复杂。想更深入的学习相关的技术细节，不知道有没有合适的课程推荐？

一直觉得持续交付是很神秘的，通过这门课程对持续交付有了一定的理解，剩下的就是不断的实践了。

老师也要注意身体啊！从课程里收获到的三条金句共勉： “个人再强放在一个低效的环境下，也无力可施。” ”避免失败的最好办法就是经常失败。” ”越痛苦的事，越要经常做。”

前携程工员，在携程时一直关注我司的发布系统，个人感觉15年后的新发布系统是我在携程期间见到的我司做的比较好的几个系统之一。 到新公司后，搭建CI/CD及相关系统时就凭着在携程用过的发布系统的印像，没有体系和理论支持，一个个点逐步建设，在这个过程中正好您在极客时间上开专栏，通过专栏补上了缺失的体系和理论，感谢您的布道和知识传播。 最后如方便想咨询一下，携程开源的[Tars](https://github.com/ctripcorp/tars)，是否还会继续进行维护？

老师您好，今天学完了整个课程，收益颇丰，目前公司正在推荐持续交付，目前遇到两个问题想请教下老师。 背景：基于SpringCloud的微服务+容器化的持续交付实践 工具链：禅道，gitlab，Jenkins+SonarQube，Docker+Harbor，K8s 问题： 1、CD过程，目前想的是基于K8s的REST API封装一套基本部署中间件API，禅道调用Jenkins（Jenkins作为中转是为了后期可以解耦），Jenkins再通过API请求封装的中间件API实现部署。不知道这种方式是否有问题？ 2、代码分支策略的问题，基本就是选用特性分支开发的模式，为了保证交付镜像的一致性（测试+预发布+生产）。如果镜像正在测试过程中，master有新的特性合并，已经产生新的版本。这时候我正在测试阶段镜像该如何处理呢？ 期待老师的解答！

一口气看完了，不错，很多地方值得实践

老师 看来是真的搞过持续集成啊 痛点说的太正确了

非常赞的分享

非常需要这篇文章的经验，感谢！

嗯，终于等到第一篇。 我在一家初创公司做中层技术管理，面临项目交付业务压力大、项目交付速度要求高的困境，希望利用持续交付能有所建树