DevOps之必知必会

1 背景

1.1 软件行业应用现代化转型：

应用现代化的优势：

可扩展性
成本管理/优化
安全性和合规性

新形势下企业面对多重挑战：

交付频率高，研发周期短。
跨地域协作多，部署分布复杂。
可靠性与安全要求高。

企业需要持续精益化的响应能力

易变性：volatility
不确定性：uncertainty
复杂性：complexity
模糊性：ambiguity

2 什么是敏捷

敏捷软件开发（Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

2.1 价值观

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

2.2 敏捷常用的工程方法

Scrum、看板方法、自定义混合模式是最受企业欢迎的前三种敏捷开发方法.

3 DevOps概述

DevOps，即Development and Operations，是一组过程、方法与系统的统称，用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps的出现是由于软件行业日益清晰的认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。DevOps可看作开发、运维和质量保障（QA）三者的交集。
DevOps运动源自于提高IT服务交付敏捷性的需要，早期出现在许多大型公有云服务提供商中，并被其认可。支撑DevOps的理念基础是敏捷宣言，它强调人（和文化），致力于改善开发和运维团队之间的协作。从生命周期的角度来看，DevOps的实施者也试图更好的利用技术，尤其是自动化工具，来支撑越来越多的可编程的动态的基础设施。

3.1 DevOps的技术实践

在思维和流程改变的同时，想要充分落地DevOps，当然离不开软件和平台的支持。目前支持DevOps的软件很多了。

3.1.1 DevOps的涉及的四大相关平台

项目管理：如，jira，禅道
代码托管：如，Gitlab，SVN
持续交付，如，Jenkins，Gitlab
运维平台:如，腾讯蓝鲸，Spug等。
整个Devops平台的托管，如华为云的CodeArts，阿里云的云效。

3.1.2 包文件

包文件通常不放在源码库中管理，而是使用专门的包文件仓库（repository）进行存储，并配合包文件依赖管理工具（Maven、npm、Ivy等）进行使用。包文件仓库可以大致分为本地仓库、私服仓库、中央仓库三种。

3.2 持续集成、持续交付和持续部署 CICD

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题
具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

3.2.1 持续集成（Continuous Integration）

持续集成（CI）是一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次——这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快的检测出集成错误。

3.2.2 持续交付（Continuous Delivery）

持续交付（CD）是从构建环境到生产环境的构建、测试、配置和部署的过程。
持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

3.2.3 持续部署(CD-Continuous Deployment)

持续部署是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。

3.2.4 基础设施即代码（Infrastructure as Code）

作为代码的基础设施（IaC）是描述性模型中的基础设施（网络、虚拟机、负载平衡器和连接拓扑）的管理，使用与DevOps团队用于源代码相同的版本。与同一源代码生成相同二进制文件的原则一样，IaC模型在每次应用时都会生成相同的环境。

4 CICD流程

开发人员不断的进行代码提交到本地，再提交到运程的代码仓库服务器
Jenkins作为持续集成工具，使用Git工具到Git仓库拉取代码到集成服务器，代码测试与审查，再配合JDK，Maven，Go等软件完成代码编译，测试，打包等工作，在这个过程中每一步如果出错，都需要重新再执行一次整个流程。
Jenkins把生成的软件jar或war包等分发到测试服务器或者生产服务器，测试人员或用户就可以访问应用。

4.1 Kubernetes 环境的 CICD

5 版本管理

5.1 Git重要特性

在本地就可以完成提交,因此不需要网络,提交完成后,可以有网络环境时,再同步到远程仓库服务器
优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
支持离线工作。
缺点：
不符合常规思维。
学习周期相对而言比较长。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

5.2 Gitlab的优势

开源免费，搭建简单、维护成本较低、可适用于中小型公司内部项目使用。
权限管理功能强大灵活，能实现代码对部分人可见，确保项目的安全性。
支持离线提交，基于git实现,可以不在实时依赖网络环境进行代码提交。

6 常见的软件部署模式

6.1 蓝绿部署

蓝绿部署指的是不停止老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。但本方式成本较高,一般小公司较少使用。
蓝绿色部署是一种部署策略，利用两种相同的环境，即"蓝色"（又名预发布）环境和"绿色"（又名生产）环境，具有不同版本的应用程序或服务。质量保证和用户接受度测试通常在承载新版本或更改的蓝色环境中进行。一旦蓝色环境中测试并接受新的变化，用户流量就会从绿色环境转变为蓝色环境。然后，一旦部署成功，您可以切换到新环境。
蓝绿部署适用的场景：
1、不停止老版本，额外部署一套新版本，等测试确认新版本正常后，才将用户请求切换至新版本，如果有问题，切换回老版本
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。

6.2 金丝雀（灰度）发布 Canary Deployment

金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布例如：2%、25%、75%、100%）进行更新)的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。因此，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
金丝雀/灰度发布部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
3、经常与A/B测试一起使用，用于测试选择多种方案。

6.3 滚动发布（更新）

滚动发布故名思议，就是逐步升级服务中的节点
滚动发布是指每次只升级一个或多个服务实例，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

红色：正在更新的实例
蓝色：更新完成并加入集群的实例
绿色：正在运行的实例
滚动发布过程

先升级1个服务实例，主要做部署验证；
每次升级1个服务实例，自动从LB上摘掉，升级成功后自动加入集群
事先需要有自动更新策略，分为若干次，每次数量/百分比可配置
回滚是发布的逆过程，先从LB摘掉新版本，再升级老版本，这个过程一般时间比较长
自动化要求高

6.4 A/B测试

A/B测试即同时对外提供两个APP运行环境，这和蓝绿部署的同时只有一个版本在线是不同的

A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等

蓝绿部署和A/B测试是不同的,蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚，即蓝绿部署是同一时间只有一套正式环境在线，而A/B测试是两套正式环境同时在线，一般用于多个产品竟争时使用。