乐趣区

关于devops:DevOps-视角的前后端分离与实战

jiezi

本文作者：CODING – 廖红坤

前言

随着微前端、微服务等技术理念和架构的蓬勃发展，咱们曾经没必要去探讨为什么要前后端拆散这种话题，前后端拆散已成为互联网我的项目开发的规范模式。前后端在各自的畛域倒退越来越纵深。

DevOps 视角的前后端拆散

明天咱们换个视角，从 DevOps 的角度来聊聊前后端拆散。

我的项目协同

DevOps 体系中蕴含了麻利开发方法论，而前后端拆散前的开发模式无奈做到麻利。开发过程中前后端强依赖，需屡次重复集成能力公布可用版本，违反了麻利开发“适应性”的特点（适应性即欢送变动）。此外，前后端串行工作的形式拉长了版本公布周期，违反了麻利开发“疾速公布小版本”的理念。

  • 前后端拆散前的合作模式：
  1. 产品经理依据需要出原型
  2. UI 出设计图
  3. 前端做 html 页面
  4. 后端将 html 页面套成 jsp 页面（前后端强依赖，后端必须要等前端的 html 做好能力套 jsp。如果过程中 html 产生变更，后端也要被迫调整，开发效率低）
  5. 集成呈现问题
  6. 前端返工
  7. 后端返工
  8. 二次集成
  9. 集成胜利
  10. 交付

  • 拆散后的合作模式：
  1. 产品经理依据需要出原型
  2. UI 出设计图
  3. 前后端约定接口、数据和参数
  4. 前后端并行开发（无强依赖，可前后端并行开发，如果需要变更，只有接口和参数不变，就不必两边都批改代码，开发效率高）
  5. 后端 API 自动化测试
  6. 前后端集成
  7. 前端页面调整
  8. 集成胜利
  9. 交付

代码治理

前后端拆散后，前后端代码离开治理，后端不须要合并前端代码，缩小代码合并抵触问题。此外，前后端拆散后，后端能够依据业务类型自在选用编程语言开发不同的组件，实现松耦合，与微服务架构不约而同。

测试治理

前后端拆散后，对应的测试也拆散了。因为后端只输入 api 接口，于是能够很不便的进行自动化测试，提前裸露问题，并且测试老本很低。而前端能够不依赖后端，本人本地 mock 数据，待前后端接口对接后，测试能够开始功能测试。

交付部署

1913 年，福特汽车开发了世界上第一条流水线，大幅提高了汽车的生产效率，每 24 秒流水线就能制作一辆汽车，实现了汽车的规模化生产，福特也因而成了美国最大的汽车制造商。

交付部署蕴含继续集成和继续部署，其外围就是流水线。从代码拆散开始，前后端就造成了两条并行的流水线，各自独立编译，构建，打包，公布。公布过程中不须要对方在场，呈现了问题各自回退。

从我的项目协同、代码治理、测试到交付部署，须要一套残缺的 DevOps 工具链撑持，比拟典型的如 Jira + GitLab + Jenkins + Nexus + Kubernetes，但这些工具之间账户体系、操作习惯互不相通，试想团队每退出一个新成员管理者都要在每个工具平台为其增加账户，新成员也要花工夫去逐个相熟。这对管理者和新人都是不必要的累赘。这样的背景下，咱们能够采纳 CODING 提供的一站式 DevOps SaaS 服务，疾速实现前后端拆散的 DevOps 最佳实际。

疾速实际 DevOps

本文以崇奉麻利开发理念的互联网团队 突突突小分队 为例，基于 CODING DevOps，以项目管理为终点，继续部署为起点演示疾速实现前后端拆散我的项目的 DevOps 最佳实际。相干人员：

  • 团队 Leader：老李
  • 运维：小胖
  • 测试：小莉
  • 后端：大熊
  • 前端：阿强

技术栈：

  • 后端（Python + Flask）：https://linrp.coding.net/p/fr…
  • 前端（React）：https://linrp.coding.net/p/fr…
  • 运维（Docker + Kubernetes）：https://linrp.coding.net/p/k8…

前提筹备

  • 应用腾讯云 TKE 创立一个 Kubernetes 集群：https://cloud.tencent.com/doc…

创立我的项目和代码仓库

2020 年 10 月 26 日早上 11:00 整，突突突小分队 Leader 老李在周会上召开了新我的项目启动大会，因为是新我的项目，老李引进了 CODING DevOps 产品，目标是将 DevOps 理念和工作流贯彻到团队理论工作中，标准团队的开发、测试和运维流程，并进一步晋升产品公布效率。散会前老李当场创立两个我的项目别离为 front-backend-cd 和 k8s-yaml，并示意给大家一天的工夫理解 CODING DevOps 产品。

突突突小分队 成员之间配合曾经有相当的默契，在理解了 CODING DevOps 产品后，第二天（10 月 27 日）各自开始了井井有条的工作：

  • 后端大熊在我的项目 front-backend-cd 中创立后端代码仓库 flask-backend
  • 前端阿强在我的项目 front-backend-cd 中创立前端代码仓库 react-frontend
  • 运维小胖在我的项目 k8s-yaml 中创立代码仓库 k8s-yaml
  • 测试小莉整顿测试用例，依据 Leader 老李提供的接口文档编写后端 API 自动化测试代码

将 k8s-yaml 作为独立我的项目保护的起因是除了 front-backend-cd 我的项目，k8s-yaml 也治理着其余我的项目的 Kubernetes yaml 文件，独自建库的目除了不便对 yaml 文件做版本控制，也便于开发和运维职责明显，开发不须要关注太多的运维基础设施（Kubernetes），次要精力放在编码、编译和构建镜像。

继续集成

代码仓库初始化后，后端大熊和前端阿强开始了欢快的编码，同时在实现第一次代码提交前，Leader 老李曾经为团队搭建好继续集成，并别离交由大熊和阿强保护。在上班前大熊和阿强实现了脚手架代码，提交了代码合并申请（MR，Merge Request）。

仔细的前端阿强发现合并申请详情页正运行一个叫 合并状态查看 的工作，求教 Leader 老李后得悉是合并申请触发的主动构建打算，其作用是： 主动构建源分支与指标分支合并后的后果，可能尽可能早地发现集成中的谬误。如果合并状态查看失败，评审者不必过早染指代码 review 流程，开发者能够自行查看代码。

合并状态查看 处点击 详情 可查看构建打算的执行详情：

果然，第一次合并状态查看失败，前端阿强依据构建日志，发现了一个低级的字符拼写错误，在心田深深的对本人鄙视一番后，立刻修复，再次提交合并申请。

前后端代码经 Leader 老李 review 合并到 release 后，会触发相应的构建打算，其终点都是代码检出，起点是将镜像推送到制品库。

继续部署

在后端大熊、前端阿强忙得热气腾腾的同时，运维小胖也没有闲着，老李将小胖增加到团队的【运维】用户组，并授予【运维】用户组部署设置权限，小胖跟着 CODING 继续部署的文档开始一步步配置。

增加云账号

作为云原生的后行团队，突突突小分队 很早就采纳腾讯云 TKE 作为生产环境，于是运维小胖增加了 TKE 类型的云账号。

配置利用和部署流程

增加完云账号后，运维小胖依据应用疏导跳转到 CODING 部署控制台，别离创立了利用 flaskBackend 和 reactFrontend。

接着配置部署流程，运维小胖将 k8s-yaml 我的项目中的 manifest 文件以及制品库中的 docker 镜像配置为部署流程制品，并在 Kubernetes 资源部署阶段（Deploy（Manifest）-Deployment）援用。

如图只有以 release- 为前缀的 docker 镜像才会胜利匹配为公布制品

在人工确认阶段，运维小胖将本人设置为确认人，并将测试小莉退出告诉人列表。

测试小莉也会接管到人工确认告诉，尽管没有权限进行确认操作，但能够对公布过程 review，以升高公布故障率。

将利用与我的项目关联

配置部署流程的过程中，因为对 CODING 部署控制台不够相熟，一些小过错让运维小胖有点焦躁，但这些繁琐的步骤不过是第一次麻烦点，接下来将利用与我的项目关联后，公布过程就能够交给开发同学提交了，想到这儿小胖露出邪魅的微笑。

版本公布

新我的项目启动的第三天（10 月 28 日），测试小莉下班第一件事是查看后端 API 自动化测试报告，中午饭点前前后端实现接口联调，下午小莉在测试环境上实现了功能测试。是时候开始激动人心的 Staging（预公布）公布了。

Staging 尽管不是最终的生产环境，但在 DevOps 实际中其代码、制品、利用配置等跟生产环境都是保持一致的，除了意外状况，Staging 公布验证无误后，就能够随时公布到生产坏境。

老李新建了一个版本公布，命名为 release-20200428.1（相应地创立了同名的 tag），示意 2020 年 10 月 28 日的第一次公布：

此 tag 会触发 CI 构建，在 Jenkinsfile 中获取此 tag 的名称并利用到 docker 镜像。

在我的项目内提交公布

后端大熊和前端阿强在我的项目内提交公布单，抉择部署流程执行必须的制品（docker 镜像抉择最新的版本 release-20200428.1）。

人工确认

部署流程执行到 人工确认 阶段，Leader 老李和运维小胖收到了人工确认告诉，小胖点击部署详情跳转到公布单详情页，确认制品信息无误后点击 继续执行。

2 分 43 秒后，公布胜利！

查看公布信息

在【基础设施】->【集群】中查看公布胜利的 Deployment 信息，可看到镜像版本与代码版本统一，如果生产环境呈现故障，可疾速追踪到对应的代码版本，进行修复工作。

测试小莉早已在运维小胖的提醒下本地配置了 hosts，关上浏览器输出 http://react-frontend.com 即可查看公布内容。这样的版本必定是不能公布到线上的，不过作为前后端拆散的 DevOps 最佳实际 Demo，它胜利的实现了使命。

结语

突突突小分队 胜利在五一劳动节前公布了第一个小版本，这次公布过程中，大家都感觉比以前舒心多了。

  • 后端大熊和前端阿强不须要本人写 k8s manifest，能够将工夫和精力专一在业务代码；
  • 而运维小胖也不必像以前和女朋友约会时，还放心开发请本人在测试环境拉取更新镜像，当初他们能够实现自助公布，小胖想如果当前 CODING 开发了 APP，关上手机即可一键实现人工确认操作，那小日子不要太爽；
  • Leader 老李则示意对 CODING DevOps 是相见恨晚呐，早些年手工停服、ftp 上传代码、手工启服的骚操作一去不复返了。

本文波及的最佳实际要点

  • 前后端代码仓库拆散：如本文中的 flask-backend 和 react-frontend
  • 开发和运维职责拆散：运维配置云账号、利用和部署流程，开发提交公布单
  • 从代码治理到制品公布，保持一致的版本规定，生产环境发现故障时可及时追溯相应的代码版本
  • Docker 作为交付规范，保障开发、测试、生产环境依赖统一
  • 运维人员应用独立的 Git 仓库治理 yaml 文件，不便对 yaml 文件做版本控制，开发不须要关怀云基础设施

DevOps 泳道图

参考资料

1、前端开发的历史和趋势：https://github.com/ruanyf/jst…

2、DevOps 的分与合：https://cloud.tencent.com/dev…

3、《凤凰我的项目：一个 IT 运维的传奇故事》：https://book.douban.com/subje…

4、《DevOps 实际指南》：https://book.douban.com/subje…

点击立刻体验高效云上研发工作流

退出移动版