“高级篇“码头工人之了解蔡先生和DevOps (41)

　　

　　

原创文章,欢迎转载。转载请注明:转载自它人故事会,谢谢!
原文链接地址:“高级篇“码头工人之了解蔡先生和DevOps (41)

　　 　　

之前已经说了便,群,美丽都部署了,k8因为机器的问题,我没做部署,有了微服务和服务编排的基础,我们可以一起了解下蔡先生和DevOps,之前在中级篇的文章讲过,老铁一起回顾学习下。

　　 　　

　　

它的产生

　　

& lt; !——更多的在

　　

　　<李>编译失败 　　

　　

从痛苦中产生,小公司人手少。开发人员每天需要处理bug和开发任务,当到达一个阶段的时候,开发人员我说错误修复可以进行测试了,告诉QA、QA进入内网执行部署的脚本,发布到测试环境,告诉我发布失败了,告诉编译有个错,误报错的代码是其他人写的,需要喊过来其他人,看看谁的问题,很快其中一个人说是他写的忘了提交一个类了,提交代码后告诉我,我告诉QA好了可以重新发布了,起初一两次大家都忍了,后来发现粗心的老铁经常会发生这个或者那样的错误,都有人少提交类或者少提交一个配置导致内网的发布失败,于是就想了一个办法,找了个专用的服务器,每次提交代码的时候,都会触发一个webhook,将代码重新一遍,如果发现编译错误,都会编译对应的代码提交者,这就是最初的持续集成了。(老司机可能都遇见过,其实这个就是最早的持续集成)

　　李 　　

　　

　　<李> 　　

运行时异常

　　

　　

虽然之前的编译的异常解决了,但是运行时异常又凸显出来了,所以就在这个基础上增加了代码的风格检查,单元测试,覆盖率,加入阿里巴巴编码规范插件啊,这里要吐槽下,据说代码规范都是给外部人看的,内部人都不遵守,其实规范很好,遵守风格统一利于维护,不要挖坑啊老铁。

　　 　　李 　　<李> 　　

手动发布

　　

　　

新项目,要申请资源,申请端口,配置nginx。老项目也不简单,在二线城市也没运维,停止下线服务。

　　 　　李 　　<李> 　　

手动部署

　　

　　

上传代码,重启,验证,上线。其实都是重复性的工作,但是这个工作要非常的消息,万一遇见个傻叉rm射频,大家都喝西北风了。

　　 　　李 　　<李>上边的痛点优化 　　

　　

从细节慢慢的去优化,优化每个环节,为了让流程更顺畅更优雅,这也就是蔡先生它的由来。

　　李 　　

　　

了解蔡先生和DevOps

　　

　　

CI是持续集成cd是持续部署。

　　 　　

　　<李> CI李 　　

　　

　　

在传统软件中,集成基本是项目的收尾阶段,我们花费几周或者数月的时间。持续集成就是把集成提前了,搞到了开发阶段,一边开发一边集成。让构建和测试经常反复的一个过程。持续集成一般是多个开发者,为同一个产品同时编写代码。把代码放到一个源数据库的地方,然后开发人员通过一个CI服务器的工具进行构建和集成。持续集成首先要求开发者需要自测代码,分别测试各自的代码,保证他们能够正常的工作,测试也成为单元测试,当所有的代码都顺利的测试通过,就认为他们就顺利的集成到一起了。代码的表现也是之前所预计的。好处是使集成不在是一个让人头疼的事情,软件一直在编写集成。在有持续集成之前,软件的开发都是到收尾统一进行的。并不知道它要耗时多久,CI就是让我们的集成融入我们日常的工作中。

　　 　　

　　

　　<李> CD 　　

　　

　　

持续部署是建立在持续集成之上的,持续部署就是开发人员在开发和测试代码的时候,同时也在其他环境进行测试这段代码。通常将不同的环境下的部署,叫做部署流水线。我们公司的部署流水线:开发环境,测试环境,准生产环境,生产环境,根据不同的公司,不同的产品,不同的团队而变化,所有的代码会经过前一个测试,才会进入下一个流水线中。通过这种方式,开发人员提交代码后,都是自动的完成的。这个过程叫持续部署。

“高级篇“码头工人之了解蔡先生和DevOps (41)