『高级篇』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做个环境跑跑实践一下。

已是最新文章