DevOps
DevOps的介绍，要清楚DevOps的出现到底是为了解决什么问题的。
首先想清楚DevOps解决的问题是什么，就要先清楚一个事情：一个软件的整个开发周期会经历哪些过程：
首先整个软件的开发，要通过不同的团队去进行配合才可以把它研发出来
其中几个核心的一个团队：
-
开发团队，它根据一些需求把需求通过代码去实现
开发计划由开发团队从头开始设计和整体系统的构建。需要系统不停的迭代更新。
-
运维团队，它要把开发团队编写好的代码部署到生产环境中
运维团队将开发团队的Code进行测试后部署上线。希望系统稳定安全运行。
这两个团队是很核心的团队，但是他们的目标却是完全不一样的。
开发团队：要根据用户的反馈以及产品需求，不停的去迭代代码，不停的去增加功能或者减少一些功能，不停的更新，甚至可能变得越来越不稳定（架构层面问题）。 在开发团队指定好计划并完成coding后，需要提供到运维团队。
运维团队：是更希望将开发团队编写好的代码，部署到生产环境上之后， 它可以更稳定更安全的去运行。 运维团队向开发团队反馈需要修复的BUG以及一些需要返工的任务。
看似两个目标完全不同的团队， 但是他们却要开发一个软件，这就造成了一些问题：当开发团队制定好计划并且编写代码之后，要交给运维团队。 那么运维团队要把在开发环境中编写好的代码去部署到测试环境 、预生产环境、生产环境或者各种各样的环境，其中可能还会涉及到测试人员的测试。这时开发团队需要经常等待运维团队的反馈。而在这样的一个时间周期里面，开发团队只能做一个事那就是等着，等着运维团队和测试团队给开发反馈出现的一些问题和bug，然后开发团队才能再次来修复这样的一个bug，可是这样就意味着一个完整的项目需要一个更长的周期才可以开发出最终代码， 迭代的成本高。因为毕竟不是一个部门，沟通也是需要一定成本的。
面对这个问题，之前的一种解决方案是：
开发团队先负责项目A，当开发完整个项目A之后的话，在A交给测试和运维团队期间，开发团队再去整体迁移到项目B，去写项目B。当项目B写完之后，再回过头来去修复项目A中出现的一些问题。
但是基于现在的互联网现状，更推崇敏捷式开发，这样就导致项目的迭代速度更快，但是由于开发团队与运维团队的沟通问题，会导致新版本上线的时间成本很高。这又违背的敏捷式开发的最初的目的。
在现在的敏捷开发中，当想到了一个业务方向，要最快的把核心功能做出来并且发布到线上，而这种形式的话，是开发团队是不能在同一个项目中停下来的，必须运维或者测试一有问题，开发团队便需要立刻去处理，如果还是要开发团队等带运维团队的反馈的话，就无法实现敏捷式开发。
而devops的目的就是为了解决咱们这两个团队之间沟通的一个问题，让软件开发的生命周期可以变得更加流畅。
那么如果让开发团队和运维团队整合到成一个团队，协同应对一套软件？这就被称为DevOps。
devops是什么
在字面的意思的话，就是两个单词
- development（开发）
- operations（运维）
虽然字面意思只涉及到了开发团队和运维团队，其实QA测试团队也是参与其中的。毕竟一个软件想部署到线上之前是要经过大量的测试的。
DevOps的形状符号：
这表明DevOps是一个不断提高效率并且持续不断工作的过程。
那这个符号是数学的无穷大的符号。那么在整个这个里面，它代表的意思是它一直在运行。那么它运行的操作到底是什么
开发团队要制定一个计划，整个软件要怎么去开发好。当制定好这个开发计划和周期之后，就要开始去编写代码了。当编写好的代码之后，可能通过maven和gradle
把整个软件给它构建起来，变成一个可运行的软件。然后测试团队就要对这个软件进行一系列的测试（包括开发者自测）了。
当测试通过之后，那这个软件就要交给运维团队去把他部署到生产环境或是预生产或测试环境。那么当运维团队把它部署成功之后，运维团队还要去监控当前这个运行的软件。
那比如说一次整个流程走完之后，把第一批核心功能发布上去了，但是后面的话，软件可能需要额外增加一些功能，那么需要再次制定开发计划，再次编写代码，再次构建，再次测试，然后再交给运营团队部署到线上之后，要再次监控
那么整个流程只要软件不停的在更新，那么这个流程就是不停的在工作的。
那像这种工作繁琐但是是重复的那就可以通过一些方式把它变成自动化的
如此一来就可以让开发团队和运维团队沟通的成本降得很低。只要开发团队写完代码好，一键构建，一键测试，一键部署，一键监控。完全不需要去关注里面的一些实现的细节，开发团队只需要专注整个业务流程就可以了，而运维团队也只需要做好他的监控就可以。这就是DevOps诞生的原因，帮助解决这种迭代式开发时出现的一些问题。
