重新认识 DevOps

Posted 2021-04-16 Study4为爱而学

什么是 DevOps

---

DevOps  是集合人、流程和产品 (工具) 三个面向，并能持续交付价值给我们的终端客户。  DevOps本身并非是一个工具或是软件，并无法直接安装它。 当然，DevOps不仅仅是自动化或是做到infrastructure as Code，DevOps 是团队可以遵循整个产品开发到交互的过程，最终，交付产品价值给我们的客户

要推进 DevOps 到组织或是行为中，可以使用 OODA 模式，来清楚定义组织对于 DevOps 的基本架设。 何谓OODA，OODA分别为观察(observe)、定位 (orient) 、判断 (decide) 和作为 (act) 。 此概念缘起于一开始的设计是要让战斗机飞行员不要被击落，它也是思考如何领先竞争者的好方法。 现在也常被用来阐述商业行为和学习过程。 这种模式适合需要在人与人之间合作努力的地方，增加整体的敏捷性

快速交付循环

---

在 DevOps 其中一个核心思维，就是缩短发布产品到客户的周期。 下图，为缓慢交付和快速交付的差异性

从缓慢地交付过程中，可以轻易的看出来，很多时候，我们必须等待很长的时间，才能进行开发，这时候要更改的程序代码或是布署流程，会是相当多的，当每个周期都必须经过异动大量代码或是流程，将容易造成错误的事情发生。 大多数的公司和团队，会认为只要把交付时间延长，或是延迟上线的时间，就可以为自己找到更多测试时间和更完整的整合性测试，并可以确保到100%都没有问题，或是认为这样才是更完整后， 才进行交付，甚至，要到达需求稳定不在变化时候，才是最安全的交付时间

但事实并非如此，随者交付时间的延长，要修复或是还原在线发生的错误，这将会是非常的困难，每个交付版本差异性过，将会导致难以找到问题发生的原因和位置。 造成维运成本增加或是许多功能同时发生异常。 让我们认为我们要花大量时间进行全面测试和大量交付需求的同时，也会花更多时间在后续布署和确保系统稳定的成本与时间

若是进行小批量的快速交付周期，在这个周期中，非常频繁的布署，但每次布署版本间的差异是较小的，变化也是较小的，将可以确保对于在线系统的影响层面较小，且同时，可以做较明确的测试。 藉由快速交付，快速得到反馈，才可以快速向我们的客户学习

DevOps 循环周期

---

在过去十几年来， Agile 的软件开发模式，在软件开发的圈子中，快速的普及与被推广。 敏捷的过程加快了软件开发的流程和让布署的节奏加快。 然后，传统IT中，维运团队开始不断加快发布的节奏，而原本为维运团队的流程虽然是可靠的，但是还不够敏捷。 开发与维运团队就开始会发生错误。 也因此透过DevOps，从开始创建、交付到最后监控，团队内都可以紧密合作，透过持续性的发布来提高整体的质量

DevOps 实践和习惯

---

在 Sam Guckenheimer 中提到了，要进行 DevOps ，团队必须实践下面七种流程

§  Configuration management

§  Release management

§  Continuous integration

§  Continuous deployment

§  Infrastructure as Code

§  Test automation

§  Application performance monitoring

后面也会针对这七个做简单的描述，以及具备下面七个习惯

§  Team autonomy and enterprise alignment

§  Rigorous management of technical debt

§  Focus on flow of customer value

§  Hypothesis-driven development

§  Evidence gathered in production

§  Live-site culture

§  Manage infrastructure as a flexible resource

Build 和 Release 的管道

---

概念上 DevOps 是需要建构自动化建置和发布。 理论上，发布的管道是决定如何将软件交付到用户的流程，所以，把交付的流程具体化就是Release pipeline。 而在这管道之间，会有发生许多种情境像是建置代码、环境配置、交互测试以及到最后确认所有程序代码都是OK的。 正常来说一个Release pipeline策略会需要涵盖Service、DB、  Web和行动装置软件，甚至包括下面这些流程

§  Binary package consumption

§  Continuous integration builds

§  Package publishing

§  Automated testing

§  Continuous delivery

行动化 APP 的布署是会和一般软件布署是不相同的，且如何从 Mobile App 去取得客户反馈信息也会和一般应用系统有所不一样

Binary package consumption

透过 Package 管理，管理那些可被重复使用且被信赖的组件。 像是我们常常使用Nuget一样，当使用这些Package时候，随着它们不断被更新，你也可以不断让自己应用程序持续更新，这些  Package组件，不因该直接被储存在你的版本控制中，而是要储存在Package Managemnet里面，藉由 Feeds 方式来取得

Continuous integration builds

持续整合建置，是程序代码被签入到版控中就要被触发建置。 因该被快速完成建置，其中还必须包括自动化测试

Package publishing

对于 Package 的发布，要使用版本号，且是建置和发布相同，这些信息因该是要被公开

Automated testing

测试尽可能包含单元测试、整合测试、 UI 测试、效能测试和负载平衡测试，这些测试要能在不被中断情况下完成

Continuous delivery

当自动化建置完成后，就立即自动被触发。 这个过程中会取得要发布的应用程序，并将要发布过去的环境，优先配置好其目标环境的相关设定，并自动化部署到该环境中

Study4 Love