防止断更 请务必加首发微信:1716143665
关闭
讲堂
客户端下载
兑换中心
企业版
渠道合作
推荐作者

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

2018-10-04 王潇俊(加微信:642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。)
持续交付36讲
进入课程

讲述:王潇俊(加微信:642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。)

时长07:08大小3.27M

专栏终于写完了,痛苦的三个月终于结束了,我也终于可以长舒一口气了。

其实按理来说,写技术专栏,特别是你自己比较熟悉的领域,应该不至于那么辛苦。但就是这么巧,答应极客时间开始写专栏后不到一个月,我就作为技术合伙人加入了一个创业团队。每天要忙的事情真得好多,我再也不能随性地规划自己的时间了。

现在,我大概看了下我上传音频稿的时间,基本都在夜里 23 点以后。其中还有 20 篇,是在 24 点以后。也因此,导致我老婆曾经一度以为我创业的内容,是做夜间直播。

虽然,这个写作和录音的过程很痛苦(真的很痛苦,现在是凌晨 1 点 45 分,我在写结束语),但我最终坚持下来了,并因此收获了快乐与成长。而这些快乐与成长,都是源于尚未谋面的“你”。

我一直都在关注你给我的留言,并努力地去解答您提出的问题。当然,对于你对专栏的吐槽与不解,我也都历历在目。这些都时刻鞭策着我,要更多地分享自己的所知、所感和所悟,要能真正帮到你。

在这个专栏里,我和你一起分享了,持续交付的理念、概念、经验和实践,涉及到了持续交付中最重要和最核心的知识点。我还通过一个具体的系统搭建案例,手把手地带你搭建了一套持续交付系统。相信你也能从中获得一些你所期望的知识吧。

说到“结束”,我还想再和你分享一下我在“持续交付”生涯中,经历的那些“痛苦”,让“你”也和我一同感受一下这些“痛”。所谓,有福同享有难同当嘛。

所以,今天我决定多和你透露一些做持续交付的“痛苦”,让你也感同身受一下。

第一痛,要比架构师懂得多

其实这个问题,我在专栏里也反复提到过。你要做持续交付,并且要做好的话,那就得比任何其他的技术人员懂得多。否则,你怎么搭建一套为他们服务的系统呢。

而且,从整个专栏里你也看到了,搭建持续交付系统的过程,充斥着各种与中间件、系统、网络相关的内容;还要迎合业务架构的设计去考虑适配。这,都会倒逼你去学习和了解各种架构知识、业务知识、开发知识等等。

所以,在携程的研发坊间流传着这样一个说法:如果你发现有技术问题解决不了,也不知道找谁解决,那你可以去找系统研发部(在携程,我们负责持续交付系统的工程师,归属于这个部门)那帮人,他们一定能帮到你。

对此,你是不是感觉非常“痛苦”呢?

第二痛,要比开发人员动作快

我一直都很佩服搞互联网开发的这帮工程师们,他们的开发动作实在是太快了。临近中午出需求,下午就上线再平常不过了。

但是呢,他们会用同样的速度标准来要求你。你不是要搞持续交付吗?不是要我遵循规则和流程吗?那么好,请你把速度提到和我们一样,绝不能因为你的持续交付而降速。

是啊,这是多么朴素的要求。但对持续交付来说,又是多么痛的领悟。这不仅要求你要具备过硬的系统设计能力,更对你的开发能力提出了同样的高要求。

第三痛,要比 QA 团队眼睛尖

QA 团队是持续交付系统非常重要的用户之一,而且他们也往往把持续交付系统看成是自己最重要的生产工具之一。所以,QA 团队会用超高的质量标准来要求你的持续交付系统。

这也可以理解,毕竟一旦用上了你的持续交付系统,就等于控制了他们的生产线,要是有问题,第一个倒霉的就是他们。

说到眼尖的另一个重要原因是,任何系统不可能一蹴而就。开发一个系统,总要有先有后,总要经历一定的时间。而持续交付,讲究的又是端到端的完整性,所以你一定要眼尖地去发现最重要的问题,并逐一解决掉,才能持续推进。否则,就你那几个人的小团队,非得忙死不可。

第四痛,要比运营人员“心脏大”

说到要心脏大,无非就是两方面:顶得住压力、受得住委屈。

既然是交付系统,自然是和运维团队一样,要对线上生产环境做动作的。常在河边走哪有不湿鞋的,搞出个一两次生产故障是再平常不过的事情了。而且,有时候做持续交付,你连合适的测试环境都没有,只能硬着头皮上生产环境做测试。此时,你一定要顶住压力,要有信心。怕出错,就别干这一行!

另一方面,你一定要能受得住委屈。“你说你一个依赖错误造成的编译不通过,为什么你自己不能解决,反而来问我是不是编译系统有问题呢?”。做持续交付,你真的得天天应付这种问题。

反过来,业务开发团队庆祝绩效突破的时候,却好像从来不会说到持续交付系统的功劳。

So,心脏不够强大,如何实施持续交付?

第五痛,要比产品经理还会“吹”

做持续交付,真的要足够会包装自己。因为你要推广你的系统、要找到你的种子用户;你要讲道理、讲技术、做演示,讲 PPT。这些技能,真的是缺一不可。

(现在是凌晨 2 点 25 分,我大概花了 40 分钟,已经洋洋洒洒地和你吐了这么多苦水了,是不是挺能“吹”的)。

越痛苦的事,越要经常做

其实,讲了这么多,你都明白,我是在讲反话。要是上面这五点你都“痛”到了,那你一定也很会痛并快乐着。因为,经历过了这些痛,你真的就将自己锤炼为了别人眼里的“牛人”。

那么,最后留一句持续集成的经典名言给你:越痛苦的事,越要经常做

这句话的出处是,在没有“持续集成”概念之前,每次项目集成都很痛苦,而持续集成就是经常“痛苦”地去做这件事,最后把这个过程变得不那么痛苦了。

同样地,上面那些“痛”,我也建议你多去体验。那么,当真正遇到这些问题了,你也就不会那么痛了,你的持续交付事业也就很顺利了。

最后,还有一点要分享给你,痛苦的事情要经常做,但没必要一直自己做,你完全可以找个“教练”陪伴你。就像我在写作专栏这个“痛苦”的过程中,一直有极客时间编辑的陪伴、鼓励和帮助。而我,也很乐于做你的“教练”。

最后,虽然专栏结束了,但你依旧可以继续留言找到我,我会一直陪伴在你“持续交付”的道路上。


© 加微信:642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。
上一篇
持续交付专栏特别放送 | 高效学习指南
 写留言

1716143665 拼课微信(18)

  • 张健
    2018-10-04
    5
    老师,幸苦了~希望常回来看看
    展开
  • webmin
    2018-10-05
    3
    前携程工员,在携程时一直关注我司的发布系统,个人感觉15年后的新发布系统是我在携程期间见到的我司做的比较好的几个系统之一。
    到新公司后,搭建CI/CD及相关系统时就凭着在携程用过的发布系统的印像,没有体系和理论支持,一个个点逐步建设,在这个过程中正好您在极客时间上开专栏,通过专栏补上了缺失的体系和理论,感谢您的布道和知识传播。

    最后如方便想咨询一下,携程开源的[Tars](https://github.com/ctripcorp/tars),是否还会继续进行维护?
    展开

    作者回复: 应该还是在维护的,不过没有什么特别新功能了,所以以修复bug为主

  • 小狼
    2018-10-19
    1
    多谢老师,祝好
    展开
  • Roway
    2019-05-15
    目前团队人员好少,很多多东西缓慢推进。㊗️老师创业顺利!
    展开
  • luffy
    2019-05-06
    一直觉得持续交付是很神秘的,通过这门课程对持续交付有了一定的理解,剩下的就是不断的实践了。
  • 765
    2019-04-01
    老师您好,今天学完了整个课程,收益颇丰,目前公司正在推荐持续交付,目前遇到两个问题想请教下老师。
    背景:基于SpringCloud的微服务+容器化的持续交付实践
    工具链:禅道,gitlab,Jenkins+SonarQube,Docker+Harbor,K8s
    问题:
    1、CD过程,目前想的是基于K8s的REST API封装一套基本部署中间件API,禅道调用Jenkins(Jenkins作为中转是为了后期可以解耦),Jenkins再通过API请求封装的中间件API实现部署。不知道这种方式是否有问题?
    2、代码分支策略的问题,基本就是选用特性分支开发的模式,为了保证交付镜像的一致性(测试+预发布+生产)。如果镜像正在测试过程中,master有新的特性合并,已经产生新的版本。这时候我正在测试阶段镜像该如何处理呢?

    期待老师的解答!
    展开
  • Michael Y...
    2019-03-26
    感谢王老师的精彩课程,期望更多好作品!
    展开
  • breezeQia...
    2019-03-21
    感谢老师!
    展开
  • zw
    2019-03-07
    王老师,请教一下您,我们目前搭建了平台,出于门户化的目的,想定制改造登录改造成门户,不太好入手,特请教一下您,谢谢!
  • 洪少
    2018-12-26
    最近有个疑惑,从版本控制和部署两个维度看,应用变更的部署和对应的数据库变更的部署,有没有必要拆分。
      换个表述是,一个需求产生应用和数据库表结构的变更,表结构的变更要不要单独的版本控制,对应也有独立的部署发布任务。是否有相关优秀实践。谢谢

    作者回复: 确实是建议拆分两个版本的,解耦即带来复杂度上升,也会对治理带来好处,看具体情况吧

  • roger
    2018-11-19
    如果团队喜欢使用svn,还能愉快的和gitlab一样持续交付吗
    展开

    作者回复: 当然也是可以的,只是部分特性不能支持而已

  • 夜空中最亮...
    2018-11-09
    最后一篇是亮点
    展开
  • zw
    2018-10-23
    您好,请问:我们目前使用的是gitolite这个轻量级的工具,如果搭建这个持续平台,请帮忙评估一下,是否需要更换到gitlab这个上面来,谢谢!

    作者回复: 主要还是看有没有二次开发的需求和对系统的熟悉程度,未必需要换的

  • 手持酱油,...
    2018-10-18
    不容易啊
    展开
  • digimonste...
    2018-10-16
    老师,您好,我们特别想做一个devops的团队,不知道在哪边能有一个分享的圈子了?不知道老师有什么资源推荐嘛?方便后续学习进步
  • xiaozhou
    2018-10-05
    老师 看来是真的搞过持续集成啊 痛点说的太正确了
    展开
  • enjoylear...
    2018-10-05
    前面还没看,就看到了结束语,辛苦!看来做持续交付是不是要技术很强呢?需要哪些技术准备?持续交付是不是可迭代的,演进式的推进呢?先把该问题留着,看看前面的文章内容有没有答案。
    展开
  • emilymeng
    2018-10-05
    谢谢老师这段时间的付出,收获满满。
    展开