研发流程 ======== 研发流程都会遵循下面这几个原则:: 1. 发布效率高 研发流程应该能提高发布效率，减少发布时间和人工介入的工作量 2. 发布质量高 研发流程应该能够提高发布质量，确保发布出去的代码是经过充分测试的，并且完全避免人为因素造成的故障 3. 迭代速度快 整个研发流程要能支持快速迭代，产品迭代速度越快，意味着产品的竞争力越强，在互联网时代越能把握先机 4. 明确性 整个研发流程中角色的职责、使用的工具、方法和流程都应该是明确的，这可以增强流程的可执行性 5. 流程合理 研发流程最终是供产品、开发、测试、运维等人员使用的， 所以整个流程设计不能是反人类的，要能够被各类参与人员接受并执行 6. 柔性扩展 研发流程应该是柔性且可扩展的，能够灵活变通，并适应各类场景 7. 输入输出 研发流程中的每个阶段都应该有明确的输入和输出 这些输入和输出标志着上一个阶段的完成，下一个阶段的开始 标准的研发流程 -------------- 把研发流程分为六个阶段:: 1. 需求阶段 产出物: 一个通过评审的详细的需求文档 2. 设计阶段 技术方案和实现都要经过认真讨论，并获得一致通过， 否则后面因为技术方案设计不当，需要返工，你要承担大部分责任 产出物: 一系列的设计文档，这些文档会指导后面的整个研发流程 3. 开发阶段 开发阶段又可以分为 “开发” 和 “构建” 两部分 提高效率的两种方法: a. 将开发阶段的步骤通过 Makefile 实现集中管理 b. 将构建阶段的步骤通过 CI/CD 平台实现自动化 产出物: 满足需求的源代码、开发文档，以及编译后的归档文件 4. 测试阶段 产出物: 满足产品需求、达到发布条件的源代码，以及编译后的归档文件 5. 发布阶段 编写一些自动化的测试用例，在服务发布到现网之后，对现网服务做一次比较充分的回归测试 产出物: 正式上线的软件 6. 运营阶段 主要分为产品运营和运维两个部分 .. figure:: https://img.zhaoweiguo.com/knowledge/images/soft-engineerings/standard-devflow1.png 开发阶段的常见步骤 应用生命周期管理 ---------------- .. note:: 【定义】采用一些好的工具或方法在应用的整个生命周期中对应用进行管理，以提高应用的研发效率和质量 从两个维度来理解应用生命周期管理技术:: 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 变得可行。 .. figure:: https://img.zhaoweiguo.com/knowledge/images/soft-engineerings/standard-devflow4.png DevOps（Development 和 Operations 的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序 / 软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。这 3 个部门的相互协作，可以提高软件质量、快速发布软件。 .. note:: 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 .. figure:: https://img.zhaoweiguo.com/knowledge/images/soft-engineerings/standard-devflow2.png ChatOps 的工作流程 使用 ChatOps 可以带来以下几点好处:: 1. 友好、便捷 所有的操作均在同一个聊天界面中，通过 @机器人以聊天的方式发送命令 免去了打开不同系统，执行不同操作的繁琐操作，方式更加友好和便捷 2. 信息透明 在同一个聊天界面中的所有同事都能够看到其他同事发送的命令，以及命令执行的结果 可以消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅 3. 移动友好 可以在移动端向机器人发送命令、执行任务，让移动办公变为可能 4. DevOps 文化打造 通过与机器人对话，可以降低项目开发中，各参与人员的理解和使用成本，从而使 DevOps 更容易落地和推广 3. GitOps ^^^^^^^^^ .. note:: GitOps 是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构（YAML）和应用程序存放在 Git 版本库中。将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request），并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。 .. note:: 通过 Git 这样的工具，开发人员可以将精力聚焦在功能开发，而不是软件运维上，以此提高软件的开发效率和迭代速度。 使用 GitOps 可以带来很多优点，其中最核心的是:: 当使用 Git 变更代码时，GitOps 可以自动将这些变更应用到程序的基础架构上 因为整个流程都是自动化的，所以部署时间更短 又因为 Git 代码是可追溯的，所以我们部署的应用也能够稳定且可重现地回滚 从概念和流程上来理解 GitOps，它有 3 个关键概念:: 1. 声明性容器编排: 通过 Kubernetes YAML 格式的资源定义文件，来定义如何部署应用 2. 不可变基础设施: 基础设施中的每个组件都可以自动的部署，组件在部署完成后，不能发生变更 如果需要变更，则需要重新部署一个新的组件 例如，Kubernetes 中的 Pod 就是一个不可变基础设施 3. 连续同步: 不断地查看 Git 存储库，将任何状态更改反映到 Kubernetes 集群中 .. figure:: https://img.zhaoweiguo.com/knowledge/images/soft-engineerings/standard-devflow3.png 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 ^^^^^^^^ .. note:: 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 可以将部署和运维自动化做到极致 在团队有人力的情况下，值得探索。