应用DevOps建设实践

OpsAny数字化研发平台，支持创建端到端的CI/CD流水线，由以下平台组成：

• 应用平台：以应用为核心的管理平台，集成CMDB、监控、DevOps功能。
• 项目管理：以项目为核心的管理平台，完成需求、任务、缺陷、迭代等管理（待上线）
• 代码仓库：以Git为核心的代码仓库管理，支持集成Gitlab。
• 流水线：从代码仓库获取代码进行CI/CD编排，支持集成Jenkins。
• 制品仓库：支持不同语言的制品的管理，支持集成Nexus。
• 持续部署：支持自定义部署编排，支持集成StackStrom。

建设流程

建设流程如下：

• 0.根据安装文档完成各类工具的集成工作。
• 1.【项目管理】创建项目，设置工作项类型，进行需求、迭代、任务分配。（待上线）
• 2.【应用平台】创建应用分组和应用。
• 3.【代码仓库】创建代码仓库，设置合理的分支管理策略，提交代码。
• 4.【流水线】创建持续集成流水线，获取代码，运行相关测试，生成可部署的制品，上传到制品仓库。
• 5.【制品仓库】创建制品仓库，接收流水线执行上传的制品。
• 6.【持续部署】从制品仓库获取制品，自动化部署到目标主机。

在进行以上建设时，我们提供了两个维度的展示和操作方法：

• 以平台为核心：我们有独立的代码仓库、流水线、制品仓库、持续部署平台，方便对应的管理员进行功能维度的管理工作。
• 以应用为核心：应用平台已经集成了DevOps各个独立平台的功能，你可以在应用平台，进入到应用中，来管理该应用的代码仓库、流水线、制品仓库和持续部署。

建议给开发工程师、测试工程师提供应用平台的权限，让他们以应用的维度进行日常操作。提醒用户，流水线、持续部署均可以和工单进行集成，实现基于工单流程的流水线自动执行和自动化部署，目前在工作台的API接口中已经内置了对应的接口。

概念介绍

OpsAny根据业界的最佳实践，对以下概念进行定义：

• 应用分组：应用分组是应用的集合，可以代表业务（电商、社交）、产品线、应用集等。
• 应用：应用是我通常理解的应用系统，例如OA系统、ERP系统、CRM系统、OpsAny等。某些场合也称之为项目、平台等。
• 服务：服务是应用的实体，一个应用最少有一个服务（单体应用），针对于复杂的应用通常有多个服务组成，例如OpsAny就有数十个服务组成。某些场合也称之为模块等。
• 进程组/工作负载：一个服务对应一个进程或者一个进程组，例如Nginx服务的多个进程就构成一个Nginx进程组。在Kubernetes模式下，进程组就是指工作负载。
• 进程/容器：泛指操作系统上的进程。在Kubernetes模式下，进程指Pod中的容器，容器是最小管理单位，容器中的进程没有管理的必要性。

案例：项目案例DevOps实践

本案例通过istio社区提供的Bookinfo项目，完成端到端的操作演示。

• Gitee地址： https://gitee.com/unixhot/bookinfo.git

0.案例项目介绍

Bookinfo应用模仿在线书店的一个分类，显示一本书的信息。 页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。

Bookinfo 应用分为四个单独的微服务：

• productpage：这个微服务使用Python编写，会调用 details 和 reviews 两个微服务，用来生成页面。
• details：这个微服务使用Ruby编写，其中包含了书籍的信息。
• reviews：这个微服务使用Java编写，其中中包含了书籍相关的评论。它还会调用 ratings 微服务。
• ratings：这个微服务使用NodeJS编写，其中中包含了由书籍评价组成的评级信息。

其中reviews 微服务有 3 个版本： - v1 版本不会调用 ratings 服务。 - v2 版本会调用 ratings 服务，并使用 1 到 5 个黑色星形图标来显示评分信息。 - v3 版本会调用 ratings 服务，并使用 1 到 5 个红色星形图标来显示评分信息。

下图展示了这个应用的端到端架构，这个项目本来是用来展示istio的相关功能，由于是由不同的语言组成的微服务，也同样适用于DevOps项目演示。

1.项目管理实践

OpsAny数字化研发平台提供瀑布式、敏捷开发相融合的项目开发模型。

（待完善）

2.代码仓库实践

对于一个研发团队来说，已经不需要在纠结是选择SVN还是Git，因为Git已经是默认选择，最主要的是选择一个合适的代码分支管理逻辑。注意没有最好的分支模型，只有适合当前项目团队的分支模型，甚至一个研发部门内部的不同项目或者产品线也可以选择不同的分支模型，不过需要尽量采用一致的版本管理策略和发布策略。

使用前请先到应用平台创建应用，代码仓库可以和应用系统进行关联。

代码分支模型

Git Flow

Git flow是最早诞生、并得到广泛采用的一种工作流程，同时也是相对比较复杂的分支管理模式，Git Flow有以下几种分支：

• Master分支（长期分支）：Master分支作为唯一一个正式对外发布的分支，是所有分支里最稳定的。这是因为，只有经过了严格审核和测试，并且在当前发布计划里的特性，才会被合并到master分支。当某个版本发布的时候，我们通常还会为master分支加上带有相应版本号的tag。

• Develop分支（长期分支）：Develop分支是根据master分支创建出来的，它作为一种集成分支(Integration Branch)，是专门用来集成开发完成的各种特性的。Develop分支通常具有更加详细和完整的提交历史，包括一些很细节的提交记录。而master分支则因为是面向版本发布的，所以它的提交历史会略去这些细节，显得比较精简。

• Feature分支（短期分支）：Feature分支是根据develop分支创建出来的，Gitflow工作流里的每个新特性都有自己的feature分支，这一点和特性分支工作流是一样的。这些分支除了在开发人员的本地存在以外，也可以被推送到共享的远程Git库，作为工作备份，以及与其他人协同工作的基础。当特性开发结束以后，这些分支上的工作会被合并到develop分支。但feature分支从来不会直接和master分支打交道。

• Release分支（短期分支）：Release分支是专门用于版本发布的分支，当积累了足够多的已完成特性，或者预定的系统发布周期临近的时候，我们就会从develop分支创建出一个release分支，专门用来做和当前版本发布有关的工作。Release分支一旦开出来以后，就不允许再有新的特性被加入到这个分支了，只有bug修复或者文档编辑之类的工作才允许进入该分支。

• Hotfix分支（短期分支）：Hotfix分支是从master分支创建得到的补丁修订的分支，其目的是为了给运行在生产环境中的系统快速提供补丁，同时确保不会给正在其他上分支进行的工作造成影响。当hotfix分支上的工作完成以后，可以合并到master分支和develop分支，以及当前的release分支。如果有版本的更新，也可以为master分支打上相应的tag。

GitHub Flow

• Master分支（长期分支）：根据项目需求，从master创建新分支，不区分功能分支或补丁分支。新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。当Pull Request被接受，就会合并进master。

GitLab Flow

Gitlab flow 是 Git flow 与 Github flow 的综合。

Git Feature flow

Truncate Based

代码版本管理

3.流水线实践

OpsAny数字化研发平台中的流水线平台提供CI/CD的流程编排，产品本身的功能并不是学习的重点，重点是实施人员如何根据当前应用的情况和团队的情况，进行合理的流水线设计。和代码分支一样，没有所谓的最好的流水线设计策略，只有更适合当前项目实际情况的流水线。因为我在实践中看到很多所谓的不符合最佳实践的流水线设计，都运行的很好，并给企业带来了很大的效率提升，不过有一些原则还是要遵守，违反这些原则，大概率会导致一些问题：

• 制品只构建一次：流水线结束构建出来的制品，在整个CI/CD周期只能构建一次，不允许构建一个部署包，部署到测试环境，准备生产发布时，又重新构建一个新的制品包。
• 代码和配置要分离： 你不能将配置文件打包到部署的制品包中去，需要实现代码和配置的分离，你可以单独管理配置文件，也可以使用配置中心例如Nacos、Configmap、Secret等。
• 相同的方法或脚本部署所有环境： 你必须相同的部署方法或者脚本部署所有环境，例如集成测试、预发布、生产环境，不允许不同环境采用不同的部署方法。
• 流水线能自动触发就不要手工： 以自动化为荣，以手工操作为耻，请尽可能采用自动化的方式进行发布。

使用前请先到应用平台创建应用，流水线必须隶属于一个应用系统。

流水线设计

流水线的设计是一个复杂的知识，通常需要用一个书籍的大的章节来叙述，这里直接列出，OpsAny实际项目中比较常见的流水线的设计案例，通常是分阶段来进行设计，每个应用根据阶段的不同，设置多条流水线。

• 提交阶段流水线
• 目标：每次提交都可以自动触发进行单元测试、编译、质量扫描等，帮助开发人员及时发现代码质量问题。
• 触发条件：开发人员Push到代码仓库的develop分支，自动触发该阶段执行。

• 步骤：

  • 拉取代码
  • 代码编译
  • 单元测试
  • 质量扫描

• 集成测试阶段流水线

• 目标：将代码打包构建，并自动化部署到测试环境，运行自动化测试，帮助开发人员进行集成阶段测试。
• 触发条件：当Master分支有Merge操作，自动触发该流水线执行。

• 步骤：

  • 拉取代码
  • 单元测试
  • 构建打包
  • 上传到制品库
  • 部署审核
  • 自动化部署测试环境
  • 自动化测试

• 部署阶段流水线

• 目标：部署代码到对应的环境上
• 触发条件：用户手工选择需要部署的环境进行触发
• 步骤：
  • 自动化部署选择的环境
  • 自动化冒烟测试

（待完善）

4.制品仓库实践

OpsAny数字化研发平台中的制品仓库提供多种语言的制品管理，制品仓库是CI/CD直接的桥梁，尤其是针对一些将CI和CD分开的场景下，例如应用系统的代码可能是委托第三方服务商进行开发，整个CI的过程是在服务商处完成，那么就要从制品仓库开始进行对接。 制品仓库接收来自于前面流水线构建的制品、用户手工上传的制品等，进行制品的存储和版本的管理，并为后续持续部署，提供制品。

制品来源： - 流水线构建：通过流水线进行制品的构建，例如War包、Docker镜像、ZIP包等，通过流水线和制品仓库的集成，自动上传到对应的制品仓库。 - 手工上传：用户在制品仓库手工上传，适用于第三方服务商开发完成后交付的制品包，或者由于网络物理隔离，需要手工上传的制品包。

使用前请先到应用平台创建应用，制品仓库必须隶属于一个应用系统。

（待完善）

5.持续部署实践

OpsAny数字化研发平台中的持续部署，只是类似于流水线的自定义编排。主要是针对部署类型进行自定义编排。

使用前请先到应用平台创建应用，持续部署流程必须隶属于一个应用系统。

（待完善）