作者回复: 哈哈,这个场景过于真实了,但是我理解常见的语言都提供了命令行方式,这个更IDE好像关系不大,当然,一个小技巧就是打开IDE的调试模式,让他打印后面的日志信息,里面应该会有调用的命令信息。当然也不排除有些场景是依赖于IDE的,这个还得具体分析,谢谢!
作者回复: 开源工具的图谱网上应该有很多,我也不是每个工具都使用过,所以建议还是贵精不贵多,可以先把几个环节的典型工具跑通并真正运用起来,再根据需要评估新的工具,如果你对具体哪个方面,或者解决那些问题的工具感兴趣,欢迎给我留言,看看能否给你一些有针对性的推荐哈!
作者回复: 你好,后面会有专门一讲来介绍CI持续集成的内容,其实从工具层面来说,现在的解决方案都比较成熟,通过关联版本控制系统和持续集成系统就可以实现每次集成的自动化任务。在这个过程中,有几个点需要特别关注:
1. 测试能力的集成,如果CI环境中缺乏测试能力,那么就无法做到持续开发的稳定性
2. 质量门禁的集成,如果没有设定质量门禁,那么持续集成中发现的问题就不会在第一时间解决
3. 通知机制的集成,需要建立一种有效的通知机制,比如即时通讯软件来告知CI结果
当然,工具,集成这些方面的因素,更重要的是培养团队的习惯,这也是落地CI最大的挑战。
至于亚马逊的CICD实践,我这边了解不多,但核心几个方面,强大的内部工具支持,应用架构充分解耦,全功能团队和研发自运维。
作者回复: 你好,你提到的DevOps IT Application Manager的具体职责是什么呢,说实话只从Title很难看出具体的职责,所以不太好随意对比哈,其实我理解DevOps工程师很多都是偏向SRE工程师,还是以运维为核心的岗位职责,只不过拓展了DevOps的能力而已。
作者回复: 你好,我也特别认同less is more的理念,如无必要,勿增实体。学习的三重境界就是学过,讲过和实践过,咱们只是第一步,加油!
作者回复: 非常好的补充,我也给你一个建议,那就是输出式学习,因为输入式学习我们可以偷懒,没听到也无所谓,不练习也没人管,但输出式学习,你的每一句话都有很多人在听着,全世界都可能知道你说的不对,这对一个人的促进力会更强哈。
作者回复: 这个问题说实话让我很纠结,要看你对于培训的心里预期,我只能说如果想在短短几天内就精通DevOps是不切实际的,培训更多的是快速提升下线,而对于一种实践来说,输出式学习往往更加有效哈。
作者回复: 你好,抱歉很晚回复,沟通是一门艺术,还是要看沟通的目的性是什么,我个人觉得,如果想更进一步,能清楚表达意思并带动一群人跟你一起干就很有必要的,毕竟到了一定程度的话,不可能一个人把所有事情都做了。我最近特别喜欢学习的三重境界,学过,讲过和实践过,尽量不要只停留在第一级哈,更多的的分享和实践才是王道!
作者回复: 你好,我传到了网盘上供参考
链接:https://pan.baidu.com/s/1N5ELmiAdOr8sud6mkFgYuA 密码:v2vd
作者回复: 你好,我认为DevOps会对组织中的每个角色都会带来影响,而所谓的实践也同样是分布在各个环节内的。既然DevOps的目标在于软件交付效率,那么效率这个事情就可以分为个人和小组两个维度。从小组维度来说,可以率先尝试和引入一些比较好的效率提升实践,即便是基于开源平台也能起到不错的效果。比如像你提到的CICD,如果开发团队可以开始尝试持续集成,并在团队内部一起讨论分支策略的优化空间。而测试团队则可以将一部分测试能力自动化后,同持续集成进行整合。也就是说在自己的部门内部开展改进工作。另外从个人维度来说,使用工具改善日常工作效率,发现上下游协作中的瓶颈点,提升自身的交付质量,并且尝试理解上下游部门的工作内容和过程,拓展上下游的知识能力,这些都有助于个人和小组成为团队DevOps的种子。当然如果真正想推行DevOps,依靠个人的力量还是很难做到的,建议先从个人和小组的能力提升做起来吧。
作者回复: 你好,我之前看过一个挺有意思的漫画,发给你参考下,不知道你们公司是否有开始使用k8s,我觉得能在实际应用中了解是最好的哈。不一定是在大规模生产中使用,比如我们之前把编译构建集群放在了k8s里面,然后再一点点的把流水线引入进来,也是一种循序渐进的过程。链接如下: https://mp.weixin.qq.com/s/JKQrxlPkpgI4IJNi6yONCw
作者回复: 你好,Jenkins方面的书籍说实话一直比较少,我之前翻译过一本Jenkins2权威指南,应该是目前业界比较权威的书籍了,你可以看下。关于操作系统和网络协议,如果你不是要求特别精神的话,我个人认为单纯了解的层面,鸟哥的书就足够啦。
作者回复: 你好,你觉得将元数据纳入版本控制的难点具体在什么地方呢,我刚好在这方面有很多积累,可以提出你的问题,我帮你一起分析一下哈。