『高级篇』docker之了解CICD和DevOps(41)

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

它的产生


* 编译失败

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

  • 运行时异常

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

  • 手动发布

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

  • 手动部署

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

  • 上边的痛点优化

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

了解CICD和DevOps

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

  • CI

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

  • CD

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

  • DevOps

更好的去优化开发,运维,测试的流程。使开发和运维通过高度自动化的工具,来使得的软件发布和构建更加的快捷频繁可靠。Devops其实是CICD思想的延伸,如果没有CICD其实DevOps就是空中楼阁,没有一点意义,CICD为基础优化开发和运维测试的所有环节。DevOps包含的东西很多,落地方案也是五花八门。

PS:CICD和DevOps有了进一步的认识,下次开始针对CICD做个环境跑跑实践一下。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『高级篇』docker之了解CICD和DevOps(41)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注