一、DevOps概念
基本概念
在如今互联网的格局下，抢占市场变得尤为重要，因此敏捷开发越来越被大家所推崇。于是，慢慢的有了DevOps这个概念，含义就是开发-运维一体化，能够理顺开发和运维之间相互配合关系的任何事物。
DevOps是一组过程、部署及开发系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
整体的软件开发流程包括：
PLAN：开发团队根据客户的目标制定开发计划
CODE：根据PLAN开始编码过程，需要将不同版本的代码存储在一个库中。
BUILD：编码完成后，需要将代码构建并且运行。
TEST：成功构建项目后，需要测试代码是否存在BUG或错误。
DEPLOY：代码经过手动测试和自动化测试后，认定代码已经准备好部署并且交给运维团队。
OPERATE：运维团队将代码部署到生产环境中。
MONITOR：项目部署上线后，需要持续的监控产品。
INTEGRATE：然后将监控阶段收到的反馈发送回PLAN阶段，整体反复的流程就是DevOps的核心，即持续集成、持续部署。
总的来说就是：
Code阶段（编码）：Git+GitLab
Build阶段（构建）：Maven或Gradle
Operate（运行）：Docker
Integrate（集成）：Jenkins
CI/CD(持续集成)：操作Jenkins，编写对应脚本文件
Code review（代码质量检测）：Jenkins集成Sonar Qube
自定义镜像：Harbor
Jenkins流水线操作
WebHook：通知操作，如：钉钉机器人通知
K8S编排：更加方便我们管理容器
二、为什么会出现DevOps？
容器化技术的发展，微服务架构的发展，直接促进了DevOps的迅速发展
敏态需求的增加，即探索性工作的增加软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求，近些年创新型的应用不断涌现，在这些应用的研发过程中多采用小步快跑、快速试错的方式，这些探索性工作要求运维能够具备一天发布多次的能力，需要企业完成由稳态到敏态的转变。
软件开发活动在企业经营活动中占比的不断增加业务发展对软件的依赖由轻度依赖、中度依赖发展到目前的重度依赖。
企业存在对消除浪费的需求
软件开发活动在企业中的位置越来越重要，而像企业经营活动一样，软件开发活动中也存在着许多的浪费，企业管理上必然存在着 「识别并消除浪费」 的需求。
软件开发中的浪费包括不必要和必要的浪费，不必要的浪费有：无人使用的功能、软件bug、等待测试、等待审批等；必要的浪费包括：工作项移交、测试、项目管理等。
三、DevOps的优势
DevOps 的主要优势在于，自动化流程可以比人员更快，更可靠地执行重复操作。对于组织而言，让开发人员或其他人员整天构建和部署代码既不可行，也无济于事。使这些重复性任务自动化可以使开发人员腾出精力去做自己最擅长的工作 ~ 修改代码。
这样做是允许在几分钟之内构建和部署代码，这仅受组织选择管理其DevOps管道的方式的限制。这意味着从开发功能或错误修正到向最终用户提供更好的体验之间的时间可以大大缩短，从而使用户更加满意。
它还创建了更好的反馈循环。新功能越早交付给用户，组织就越早可以收集反馈和指标并深入了解用户对其产品的喜好。这使组织保持敏捷并为创新提供了更好的环境。
四、DevOps生命周期
DevOps生命周期主要包括产品（策划、研发、运营、推出）、项目（立项、执行、完工），而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程，要以产品的视角来看待，真正进行交付的时候，也要以产品为维度进行组织的设立。
DevOps 的核心是一组工具和实践，可帮助组织更可靠，更快地构建，测试和部署软件。DevOps 使组织能够比具有传统开发和发布周期的组织更快地发展和交付其产品，从而可以提供竞争优势。与其每天两周或更长时间发布一次版本，不如每天向用户交付新功能，并且可以在数小时内部署错误修正，所有这些都遵循相同的可重复自动化流程。
五、DevOps三大原则
1、流动原则
加速从开发、运维到交付给客户的流程；
坚持少做，产品开始开发时采用 MVP 原则，产品迭代时要适时做减法；
持续分解问题，大的变更或需求拆解为一系列小的变更，快速解决；
工作可视化，采用 Sprint 看板将工作可视化；
控制任务数量，减少前置时间，降低测试人员的等待时间；
减少交接次数，减少不必要的沟通和等待；
持续识别和改善约束点，提高搭建环境、需求文档、QA、开发、运维的生产力；
消除价值流中的困境和浪费；
2、反馈原则
建设安全可靠的工作体系；
在复杂系统中安全地工作；
及时发现问题；
在源头保障质量；
为内部客户优化工作；
3、持续学习与实验原则
采用科学的工作方式，将对组织的改进和创新作为工作的一部分。
建立学习型组织和安全文化；
将日常工作的改进制度化；
把局部发现转化为全局优化；
在日常工作中注入弹性模式；
领导层强化学习文化；
六、快速实现DevOps
开发人员完成了为其小部件的新功能编写代码。他们将代码提交到功能分支，该功能分支在其开发计算机上启动了一些轻量级测试，检查是否存在任何代码样式问题，同时还扫描具有新公开的安全漏洞的软件包。开发人员提交拉取请求以将其代码合并到代码存储库中，该代码存储库向团队聊天发送通知。
团队中的另一位开发人员检查了代码更改，在发现代码中没有问题之后，批准了请求请求。该代码会自动合并到开发分支中，从而开始构建过程。构建服务器将克隆 developer分支，安装所有软件包依赖项并构建窗口小部件。生成服务器会运行单元测试和集成测试，以确保新功能不会在小部件的其他部分引起任何退步。
每个测试都通过了，构建成功。根据代码库中定义的最佳实践配置，将在云中自动配置一个新容器，并部署小部件。
此时，组织有两个选择。他们可以选择将更新后的窗口小部件自动发布到生产环境中，并使所有用户或选择接收最新功能的部分用户可以使用该功能。自动部署到生产中称为连续部署（CD）。
或者，组织可以选择仅将功能发布到用户验收测试（UAT）环境中，然后根据预定义的时间表手动批准将发布发布到生产中。在管道中添加手动审批流程通常称为“持续交付”（CD的另一种形式）。
无论是否涉及手动步骤，一旦将小部件成功部署到生产中，都将执行附加的自动化测试。其他工具收集有关性能和用户行为的指标，这些指标将提供给IT运营和开发团队，以提供实时反馈，突出显示潜在的错误并帮助塑造新功能。
对于基本的 DevOps 管道，这是一个相当典型的过程，但具体细节取决于组织。
一些组织倾向于在生产环境中快速部署，将新功能隐藏在功能标记后面，以允许向用户群分阶段发布。其他人则更喜欢使用更传统的开发，测试和生产环境结构，在此结构中，功能被批量部署并在部署到生产之前通过多个手动门缓慢发布。
DevOps 可以根据组织或项目的特定需求进行定制。
该过程趋于发展，添加其他测试以生成更安全的应用程序，或找到优化管道以加快构建速度并减少人工干预的方法。
