2018-10-04老师，幸苦了～希望常回来看看 6
2018-10-05前携程工员，在携程时一直关注我司的发布系统，个人感觉15年后的新发布系统是我在携程期间见到的我司做的比较好的几个系统之一。
到新公司后，搭建CI/CD及相关系统时就凭着在携程用过的发布系统的印像，没有体系和理论支持，一个个点逐步建设，在这个过程中正好您在极客时间上开专栏，通过专栏补上了缺失的体系和理论，感谢您的布道和知识传播。
最后如方便想咨询一下，携程开源的[Tars](https://github.com/ctripcorp/tars)，是否还会继续进行维护？作者回复: 应该还是在维护的，不过没有什么特别新功能了，所以以修复bug为主
4
2019-04-01老师您好，今天学完了整个课程，收益颇丰，目前公司正在推荐持续交付，目前遇到两个问题想请教下老师。
背景：基于SpringCloud的微服务+容器化的持续交付实践
工具链：禅道，gitlab，Jenkins+SonarQube，Docker+Harbor，K8s
问题：
1、CD过程，目前想的是基于K8s的REST API封装一套基本部署中间件API，禅道调用Jenkins（Jenkins作为中转是为了后期可以解耦），Jenkins再通过API请求封装的中间件API实现部署。不知道这种方式是否有问题？
2、代码分支策略的问题，基本就是选用特性分支开发的模式，为了保证交付镜像的一致性（测试+预发布+生产）。如果镜像正在测试过程中，master有新的特性合并，已经产生新的版本。这时候我正在测试阶段镜像该如何处理呢？
期待老师的解答！展开 1
2018-12-26最近有个疑惑，从版本控制和部署两个维度看，应用变更的部署和对应的数据库变更的部署，有没有必要拆分。
换个表述是，一个需求产生应用和数据库表结构的变更，表结构的变更要不要单独的版本控制，对应也有独立的部署发布任务。是否有相关优秀实践。谢谢作者回复: 确实是建议拆分两个版本的，解耦即带来复杂度上升，也会对治理带来好处，看具体情况吧
1
2018-10-19多谢老师，祝好 1
2019-12-16一口气看完了，不错，很多地方值得实践
2019-05-15目前团队人员好少，很多多东西缓慢推进。㊗️老师创业顺利！
2019-05-06一直觉得持续交付是很神秘的，通过这门课程对持续交付有了一定的理解，剩下的就是不断的实践了。
2019-03-26感谢王老师的精彩课程，期望更多好作品！
2019-03-21感谢老师！
2019-03-07王老师，请教一下您，我们目前搭建了平台，出于门户化的目的，想定制改造登录改造成门户，不太好入手，特请教一下您，谢谢！
2018-11-19如果团队喜欢使用svn，还能愉快的和gitlab一样持续交付吗作者回复: 当然也是可以的，只是部分特性不能支持而已
2018-11-09最后一篇是亮点- 2018-10-23您好，请问:我们目前使用的是gitolite这个轻量级的工具，如果搭建这个持续平台，请帮忙评估一下，是否需要更换到gitlab这个上面来，谢谢!
作者回复: 主要还是看有没有二次开发的需求和对系统的熟悉程度，未必需要换的
2018-10-18不容易啊- 2018-10-16老师，您好，我们特别想做一个devops的团队，不知道在哪边能有一个分享的圈子了？不知道老师有什么资源推荐嘛？方便后续学习进步
- 2018-10-05老师 看来是真的搞过持续集成啊 痛点说的太正确了
2018-10-05前面还没看，就看到了结束语，辛苦！看来做持续交付是不是要技术很强呢？需要哪些技术准备？持续交付是不是可迭代的，演进式的推进呢？先把该问题留着，看看前面的文章内容有没有答案。
2018-10-05谢谢老师这段时间的付出，收获满满。