前后端分离的工作流：在项目中引入持续集成

Posted 2021-04-30 易研家

前言

在前端后分离的背景下，

前端工程师的职责进一步扩大，

以往不需要关心的代码部署环节,

也开始变成工作的一部分。

传统的人工发布方式，

已经不能满足日益工程化的前端工作流。

本文分析了现有工作流的问题，

依托Git Flow 和GitLab CI，

提出了在项目中引入持续集成的方案

几个概念

传统后端主导项目(简称：传统项目)：

前端交付静态页面，后端套页面写逻辑；

前后端分离项目：

一般是SPA（Single Page Application）应用，

前端写逻辑，

后端仅提供数据接口和入口页面；

前端源码仓库：

现在一般都托管在gitlab上，

存放未经构建的前端源码；

产品仓库：

一般是后端svn/git仓库，

前端资源独立部署的项目除外；

传统项目工作流

适用于站点类项目。

这类项目通常对seo有要求。

问题分析

重度依赖后端环境（后端或运维维护），

一旦出现问题只能等；

重度依赖人工部署（后端发，没有钩子的联调环境你懂的），

沟通成本高；

通常是在联调阶段才能发现问题；

缺乏自动化测试流程；

前后端分离工作流

适用于Web App、WebView客户端或管理平台项目。

这类项目通常交互复杂度较高，对用户体验和视觉呈现有较高要求。

问题分析

重度依赖本地开发环境，

要想在不同机器搭建一模一样的环境，

需要精力和RP；

本地开发环境与生产环境有差异

（windows vs linux），

代码正确性无法保证；

依然依赖人工部署

（从后端发变成了前端发），

容易出现误操作；

缺乏自动化测试流程；

前端开发工作流

一些变化

从在产品仓库直接开发，

过渡到了拥有自己的源码库；

从依赖后端发布代码，

过渡到了我们也有了发布权限；

前端开发的复杂度越来越高，

项目渗透度越来越高；

前后端分离的趋势越来越明显；

 

但是，

构建工具的引入，

一定程度上提高了开发效率，

但远远不够。

我们maybe也许开始进入大前端时代

引入持续集成

持续集成

（ContinuousIntegration）

指的是，

频繁地（一天多次）将代码集成到主干;

持续交付

（ContinuousDelivery）

指的是，

频繁地将软件的新版本，

交付给质量团队或者用户以供评审

持续部署

（ContinuousDeployment）

是持续交付的下一步，

指的是代码通过评审以后，

自动部署到生产环境

 

为什么要引入持续集成

让我们看三个小故事

故事1

上面的故事告诉我们： 
永远不要忽视环境的差异

故事2

上面的故事告诉我们： 
人工发包有风险，

请先更新本地代码再打包

故事3

上面的故事告诉我们： 
求人不如求己，

自己动手丰衣足食

用 GitLab CI 进行持续集成

GitLab CI 是GitLab v8.0开始配套的持续集成工具

流程设计

设计原则

保证简单易执行，支持流程定制;

支持持续集成，降低人工误操作风险;

倡导DevOps;

Git分支划分

这里以Git Flow为例,

主分支

master分支（必须）：

主干分支，用于保存当前稳定版本。

建议每一个稳定版本打一个tag

dev分支（必须）：

主开发分支，

用于主功能开发、测试bug修复等。

基于master分支，最后 merge 到master分支

test分支（必须）：

提测分支，用于保存提测版本。

基于master分支，最后merge到master分支

 

其他分支

feature-*分支：

特性分支，用于特性功能开发。

基于master分支，最后 merge 到dev或master分支

hotfix-*分支：

bug修复分支，用于修复线上紧急bug。

基于master分支，最后 merge 到master分支

开发联调流程

流程图

CI干啥了

测试流程

流程图

CI在干啥

上线流程

流程图

CI干了啥

作者说：

我讲完了，