2.1.12. 研发流程¶
研发流程都会遵循下面这几个原则:
1. 发布效率高
研发流程应该能提高发布效率，减少发布时间和人工介入的工作量
2. 发布质量高
研发流程应该能够提高发布质量，确保发布出去的代码是经过充分测试的，并且完全避免人为因素造成的故障
3. 迭代速度快
整个研发流程要能支持快速迭代，产品迭代速度越快，意味着产品的竞争力越强，在互联网时代越能把握先机
4. 明确性
整个研发流程中角色的职责、使用的工具、方法和流程都应该是明确的，这可以增强流程的可执行性
5. 流程合理
研发流程最终是供产品、开发、测试、运维等人员使用的，
所以整个流程设计不能是反人类的，要能够被各类参与人员接受并执行
6. 柔性扩展
研发流程应该是柔性且可扩展的，能够灵活变通，并适应各类场景
7. 输入输出
研发流程中的每个阶段都应该有明确的输入和输出
这些输入和输出标志着上一个阶段的完成，下一个阶段的开始
标准的研发流程¶
把研发流程分为六个阶段:
1. 需求阶段
产出物: 一个通过评审的详细的需求文档
2. 设计阶段
技术方案和实现都要经过认真讨论，并获得一致通过，
否则后面因为技术方案设计不当，需要返工，你要承担大部分责任
产出物: 一系列的设计文档，这些文档会指导后面的整个研发流程
3. 开发阶段
开发阶段又可以分为 “开发” 和 “构建” 两部分
提高效率的两种方法:
a. 将开发阶段的步骤通过 Makefile 实现集中管理
b. 将构建阶段的步骤通过 CI/CD 平台实现自动化
产出物: 满足需求的源代码、开发文档，以及编译后的归档文件
4. 测试阶段
产出物: 满足产品需求、达到发布条件的源代码，以及编译后的归档文件
5. 发布阶段
编写一些自动化的测试用例，在服务发布到现网之后，对现网服务做一次比较充分的回归测试
产出物: 正式上线的软件
6. 运营阶段
主要分为产品运营和运维两个部分
开发阶段的常见步骤¶
应用生命周期管理¶
备注
【定义】采用一些好的工具或方法在应用的整个生命周期中对应用进行管理，以提高应用的研发效率和质量
从两个维度来理解应用生命周期管理技术:
1. 演进维度
应用生命周期，最开始主要是通过研发模式来管理的，
按时间线先后出现了瀑布模式、迭代模式、敏捷模式。
接着，为了解决研发模式中的一些痛点出现了另一种管理技术，也就是 CI/CD 技术。
随着 CI/CD 技术的成熟，又催生了另一种更高级的管理技术 DevOps。
2. 管理技术的类别
应用生命周期管理技术可以分为两类:
a. 研发模式，用来确保整个研发流程是高效的
b. DevOps，主要通过协调各个部门之间的合作，来提高软件的发布效率和质量
DevOps 中又包含了很多种技术，主要包括 CI/CD 和多种 Ops，例如 AIOps、ChatOps、GitOps、NoOps 等
其中，CI/CD 技术提高了软件的发布效率和质量，而 Ops 技术则提高了软件的运维和运营效率。
1. 研发模式专注于开发过程
2. DevOps 技术里的 CI/CD 专注于流程
3. Ops 则专注于实战
研发模式¶
研发模式主要有三种，演进顺序:
瀑布模式 -> 迭代模式 -> 敏捷模式
瀑布模式:
优点:
最大的优点是简单
缺点:
1. 只有在项目研发的最后阶段才会交付给客户。交付后，如果客户发现问题，变更就会非常困难，代价很大
2. 研发周期比较长，很难适应互联网时代对产品快速迭代的诉求
迭代模式:
研发任务被切分为一系列轮次，每一个轮次都是一个迭代，每一次迭代都是一个从设计到实现的完整过程。
它不要求每一个阶段的任务都做到最完美，而是先把主要功能搭建起来，然后再通过客户的反馈信息不断完善。
迭代开发可以帮助产品改进和把控进度，它的灵活性极大地提升了适应需求变化的能力，克服了高风险、难变更、复用性低的特点
敏捷模式:
敏捷模式把一个大的需求分成多个、可分阶段完成的小迭代，每个迭代交付的都是一个可使用的软件。
在开发过程中，软件要一直处于可使用状态。
敏捷模式中具有代表性的开发模式，是 Scrum 开发模型。
在敏捷模式中，我们会把一个大的需求拆分成很多小的迭代，
这意味着开发过程中会有很多个开发、构建、测试、发布和部署的流程。
这种高频度的操作会给研发、运维和测试人员带来很大的工作量，降低了工作效率。
为了解决这个问题，CI/CD 技术诞生了。
CI/CD¶
CI/CD 包含了 3 个核心概念:
CI: Continuous Integration，持续集成
CD: Continuous Delivery，持续交付
CD: Continuous Deployment，持续部署
DevOps¶
要实现 DevOps，需要一些工具或者流程的支持，CI/CD 可以很好地支持 DevOps 这种软件开发模式，如果没有 CI/CD 自动化的工具和流程，DevOps 就是没有意义的，CI/CD 使得 DevOps 变得可行。
DevOps（Development 和 Operations 的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序 / 软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。这 3 个部门的相互协作，可以提高软件质量、快速发布软件。¶
备注
DevOps 是一组过程、方法和系统的统称，而 CI/CD 只是一种软件构建和发布的技术。CI/CD 技术的成熟，加速了 DevOps 这种应用生命周期管理技术的成熟和落地。
DevOps 技术之前一直有，但是落地不好，因为没有一个好的工具来实现 DevOps 的理念。但是随着容器、CI/CD 技术的诞生和成熟，DevOps 变得更加容易落地。也就是说，这几年越来越多的人采用 DevOps 手段来提高研发效能。 随着技术的发展，目前已经诞生了很多 Ops 手段，来实现运维和运营的高度自动化。
DevOps 中的四个 Ops 手段:
1. AIOps
2. ChatOps
3. GitOps
4. NoOps
1. AIOps¶
2016 年，Gartner 提出利用 AI 技术的新一代 IT 运维，即 AIOps（智能运维）
通过 AI 手段，来智能化地运维 IT 系统。
AIOps 通过搜集海量的运维数据，并利用机器学习算法，智能地定位并修复故障。
特点:
故障告警更加灵敏、准确，一些常见的故障，可以自动修复，无须运维人员介入
2. ChatOps¶
聊着天就把事情给办了:
在一个聊天工具中，发送一条命令给 ChatBot 机器人，然后 ChatBot 会执行预定义的操作。
这些操作可以是执行某个工具、调用某个接口等，并返回执行结果。
优势:
利用 ChatBot 机器人让团队成员和各项辅助工具连接在一起，以沟通驱动的方式完成工作。
ChatOps 可以解决人与人、人与工具、工具与工具之间的信息孤岛，从而提高协作体验和工作效率
业界流行的机器人可供选择，常用的有:
Hubot、Lita、Errbot、StackStorm
ChatOps 的工作流程¶
使用 ChatOps 可以带来以下几点好处:
1. 友好、便捷
所有的操作均在同一个聊天界面中，通过 @机器人以聊天的方式发送命令
免去了打开不同系统，执行不同操作的繁琐操作，方式更加友好和便捷
2. 信息透明
在同一个聊天界面中的所有同事都能够看到其他同事发送的命令，以及命令执行的结果
可以消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅
3. 移动友好
可以在移动端向机器人发送命令、执行任务，让移动办公变为可能
4. DevOps 文化打造
通过与机器人对话，可以降低项目开发中，各参与人员的理解和使用成本，从而使 DevOps 更容易落地和推广
3. GitOps¶
备注
GitOps 是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构（YAML）和应用程序存放在 Git 版本库中。将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request），并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。
备注
通过 Git 这样的工具，开发人员可以将精力聚焦在功能开发，而不是软件运维上，以此提高软件的开发效率和迭代速度。
使用 GitOps 可以带来很多优点，其中最核心的是:
当使用 Git 变更代码时，GitOps 可以自动将这些变更应用到程序的基础架构上
因为整个流程都是自动化的，所以部署时间更短
又因为 Git 代码是可追溯的，所以我们部署的应用也能够稳定且可重现地回滚
从概念和流程上来理解 GitOps，它有 3 个关键概念:
1. 声明性容器编排:
通过 Kubernetes YAML 格式的资源定义文件，来定义如何部署应用
2. 不可变基础设施:
基础设施中的每个组件都可以自动的部署，组件在部署完成后，不能发生变更
如果需要变更，则需要重新部署一个新的组件
例如，Kubernetes 中的 Pod 就是一个不可变基础设施
3. 连续同步:
不断地查看 Git 存储库，将任何状态更改反映到 Kubernetes 集群中
GitOps 的工作流程¶
GitOps 的工作流程:
1. 开发人员开发完代码后推送到 Git 仓库
触发 CI 流程，CI 流程通过编译构建出 Docker 镜像，并将镜像 push 到 Docker 镜像仓库中。
Push 动作会触发一个 push 事件，通过 webhook 的形式通知到 Config Updater 服务，
Config Updater 服务会从 webhook 请求中获取最新 push 的镜像名，
并更新 Git 仓库中的 Kubernetes YAML 文件。
2. GitOps 的 Deploy Operator 服务
检测到 YAML 文件的变动，会重新从 Git 仓库中提取变更的文件，并将镜像部署到 Kubernetes 集群中
Config Updater 和 Deploy Operator 两个组件需要开发人员设计开发
4. NoOps¶
备注
NoOps 即无运维，完全自动化的运维。在 NoOps 中不再需要开发人员、运营运维人员的协同，把微服务、低代码、无服务全都结合了起来，开发者在软件生命周期中只需要聚焦业务开发即可，所有的维护都交由云厂商来完成。
毫无疑问，NoOps 是运维的终极形态，它像 DevOps 一样，更多的是一种理念，需要很多的技术和手段来支撑。当前整个运维技术的发展，也是朝着 NoOps 的方向去演进的，例如 GitOps、AIOps 可以使我们尽可能减少运维，Serverless 技术甚至可以使我们免运维。相信未来 NoOps 会像现在的 Serverless 一样，成为一种流行的、可落地的理念。
如何选择合适的应用生命周期管理技术¶
在实际开发中，可以从这么几个方面考虑:
1. 根据团队、项目选择一个合适的研发模式
如果项目比较大，需求变更频繁、要求快速迭代，建议选择敏捷开发模式
敏捷开发模式，也是很多大公司选择的研发模式，在互联网时代很受欢迎
2. 要建立自己的 CI/CD 流程
任何变更代码在合并到 master 分支时，一定要通过 CI/CD 的流程的验证
在 CI/CD 流程中设置质量红线，确保合并代码的质量
3. 除了建立 CI/CD 系统，建议将 ChatOps 带入工作中
尽可能地将可以自动化的工作实现自动化，并通过 ChatOps 来触发自动化流程
随着企业微信、钉钉等企业聊天软件成熟和发展，ChatOps 变得流行和完善
4. GitOps、AIOps 可以将部署和运维自动化做到极致
在团队有人力的情况下，值得探索。