在此时此刻致使前端就像是选择Vue或者React其一那种东西负责页面的渲染以及交互, 而后端类似于Node.js这一类的东西负责完成接口与数据处理, 从而极大程度提升开发效率的前后端分离成为主流开发架构的这样一种背景之下。仅仅只是随之就产生像部署区域被割裂开来、所处环境不一样、发布阶段操作流程特别繁杂、人工上十分容易出现失误等等这一系列的问题, 竟然成为研发交付过程当中的核心痛点即关键难点: 前端将资源完成打包完成之后要以手动的方式去拷贝, 接下来为后端进行单独编译然后再去部署, 针对多个各种状态的环境配置需要反复进行修改, 上线之时全体工作人员要加班花费一段时间去联合完成调用调试, 这一系列操作不仅导致迭代速度降低变慢变得拖延, 更是大幅增加线上将会出现故障的风险概率。在这些问题的解决工作当中来讲, 前端与后端一体化的CI/CD, 是起着极为关键作用的方案, 此方案能够对于前端构建、后端构建、集成测试、制品进行打包、多环境部署以及版本回滚等系列全流程予以打通, 以此达成一次代码进行提交时, 能够自动化地完从校验直至上线过程的全链路闭环情况, 切实达成具备高效、稳定、可追溯以及低风险特点的持续交付操作。在本文当中, 将会全程以企业级比较常用的作为核心工具, 从核心概念这个维度、整体架构层面、工程设计方面、流水线的实现路径、实战方面相关配置以及避坑指南方面, 总共这六大主要维度, 去完整地拆解基于CI/CD的前后端一体化CI/CD相应设计以及落地流程。而前后端一体化CI/CD正是解决这些问题的关键方案。它将前端构建、后端构建、集成测试、制品打包、多环境部署、版本回滚全流程打通实现一次代码提交自动完成从校验到上线的全链路闭环真正做到高效、稳定、可追溯、低风险的持续交付。本文将全程以企业级常用的为核心工具从核心概念、整体架构、工程设计、流水线实现、实战配置、避坑指南六大维度完整拆解基于 CI/CD的前后端一体化CI/CD设计与落地流程。一、核心概念梳理先搞懂CI/CD到底是什么有不少开发者对于CI/CD的认识仅仅停留在“自动化部署”上面, 然而实际上它是一整套完整的来进行研发交付的体系, 它被划分成为三个核心的环节, 在前后端一体化那种场景之下是需要全程进行联动的。之前后端一体化核心不一样的地方在于, 平常的CI/CD一般都是前端和后端拉开来进行操作, 而一体化的方案却是把触发时候统一起来, 把版本管理统一起来, 把制品打包统一起来, 把部署流程也统一起来, 以保证前端和后端版本完全对得上, 防止因为版本不相符而致使的线上出现的问题。二、整体架构设计一体化CI/CD全流程链路由代码仓库、CI/CD工具、构建环境、制品仓库、部署环境、监控回滚这六大模块共同构成的, 有着全流程事件驱动且勿需人工介入特点的一套完整的前后端一体化CI/CD架构, 其具体链路如下:暂时无法在豆包文档外展示此内容此套架构具备的核心优势在于, 全流程呈现自动化状态, 版本拥有唯一且可被精准控制的特性, 环境达成完全相同致的状态, 故障状况能够实现快速进行回滚的操作, 全流程存在可追溯的属性, 从而彻底告别因手动部署而产生的各种各样的痛点。三、工程结构设计适配一体化部署的目录规范工程结构, 对CI/CD流水线的复杂度来讲, 起着直接决定的作用, 在此推荐两种结构, 这两种结构, 适配前后端一体化效果, 可以供不同团队选择, 取决于不同团队规模, 具体如下:3.1 单仓库结构中小型团队首选在同一个Git仓库里放置前后端部代码, 进行统一版本管理, 实施统一流水线配置, 这适用于前后端协同紧凑、且团队规模不算大的项目, 目录结构是这样的:project-root/ ├── frontend/ # 前端项目目录Vue/React │ ├── package.json # 前端依赖构建脚本 │ ├── src/ # 前端源码 │ └── dist/ # 前端构建产物自动生成 ├── backend/ # 后端项目目录SpringBoot/Node.js │ ├── pom.xml/package.json # 后端依赖配置 │ ├── src/ # 后端源码 │ └── target/ # 后端构建产物自动生成 ├── .gitlab-ci.yml # GitLab CI/CD核心流水线配置文件 ├── Dockerfile # 多阶段构建Dockerfile └── .gitignore # Git忽略文件配置优势在于, 版本能够同步, 流水线是统一的, 部署起来便捷。劣势乃是, 仓库体积比较大, 适宜中小型项目。3.2 多仓库分离结构中大型团队推荐对于大型项目, 其分工较明确, 前后端是独立迭代的模式, 要将前端代码及后端代码分开在不同仓库进行管理, 通过 Tag 去达成流水线联动, 还需要借助 CI / CD 工具来配置联动触发的规则, 进而保证版本是对齐的。四、核心技术栈选型轻量易用企业级适配依循主流落地场景, 举荐兼顾易用性与稳定性的技术栈, 新手能够迅速得以上手, 企业能够径直实现扩容。模块推荐工具/技术用途说明代码仓库将代码进行托管, 其中内置了CI/CD流水线, 还有容器仓库, 以此实现研发交付的全闭环。CI/CD工具持续集成与持续交付, 其内置于其中无需另外进行部署, 与 执行任务相辅助配合开展工作, 是面向企业层级的最先入选的选择。在流水线编排方面, 有着相应的举措, 在任务执行环节, 有着对应的操作, 在构建调度过程中, 有着相关的安排, 依靠内置的CI/CD能力, 不需要第三方平台, 代码和流水线进行一体化管理。容器化环境封装、制品打包解决环境不一致问题制品仓库内置容器仓库存储前后端统一的镜像, 凭借其达成版本管理以及权限管控, 不用另外搭建第三方的制品仓库。前端构建Node.jsnpm/pnpm前端依赖安装、生产包构建后端构建Maven//npm后端编译、打包、单元测试质量管控//JUnit代码规范检查、漏洞扫描、单元测试五、一体化CI/CD流水线实战实现 CI/CD专属以Vue加上技术栈、单仓库作为基础, 依靠内置的CI/CD能力, 去完成全流程流水线的配置, 这是企业内部研发最为常用的落地方案之一, 不需要额外部署第三方CI平台, 达成代码、流水线、制品仓库的全闭环管理, 适配于绝大多数的前后端分离项目。5.1 核心前提准备项目依据结构予以整理, 前端代码放置于相应目录, 后端代码也放置于相应目录, 代码被托管到私有仓库, 如果不是私有仓库 , 那就是公有仓库。搭建起来并且进行注册, 推荐去选用执行者, 其环境具有很强的隔离性, 它支持跨不同平台来构建, 需要确保注册之后处于在线从而运行的状态。安装目标部署服务器, 开放对应服务端口通过配置镜像加速来提升镜像拉取速度。走进仓库后台, 于【设置】-【CI/CD】-【变量】那里去配置敏感信息, 这其中涵盖服务器IP, 还有SSH私钥, 以及仓库凭证再加数据库连接信息等, 加以杜绝因代码硬编码才致使的信息泄露。启动内置的容器仓库, 不用另外去搭建, 不像借助 Nexus, 能直接用来存储, 有关前后端一体化的镜像。分阶段编写, 实现前端分步构建, 实现后端分步构建, 最终将前端与后端整合为单一镜像, 以此简化部署流程。5.2 多阶段编写核心多阶段构建成为贯穿前后端一体化的核心要点, 首先要对前端进行独立构建, 接着再来构建后端部分, 最终将两者整合成为一个镜像, 以此种方式来削减镜像体积, 进而确保环境达成统一状态。# 阶段1前端构建Node环境 FROM node:18-alpine AS frontend-builder WORKDIR /app/frontend COPY frontend/package*.json ./ # 依赖缓存优化加速构建 RUN npm config set registry https://registry.npmmirror.com npm install COPY frontend/ . # 前端生产构建 RUN npm run build # 阶段2后端构建MavenJDK环境 FROM maven:3.9.6-openjdk-17 AS backend-builder WORKDIR /app/backend COPY backend/pom.xml . # 依赖缓存 RUN mvn dependency:go-offline COPY backend/src/ ./src # 复制前端构建产物到后端静态资源目录 COPY --fromfrontend-builder /app/frontend/dist ./src/main/resources/static # 后端打包跳过测试可根据需求开启 RUN mvn clean package -DskipTests # 阶段3最终运行镜像精简JRE环境 FROM openjdk:17-jdk-slim WORKDIR /app # 复制后端jar包 COPY --frombackend-builder /app/backend/target/*.jar app.jar # 暴露端口 EXPOSE 8080 # 启动命令 ENTRYPOINT [java, -jar, app.jar]这份达成了前后端产物全然融合的东西, 最终有一个镜像涵盖前端静态资源以及后端服务, 在部署的时候直接运行就行, 不需要单独去部署前端Nginx。5.3 CI/CD流水线配置核心脚本CI/CD不用另外去创建工作流目录, 直接于项目根目录那儿创建.-ci.yml的核心配置文件, 它会自动识别此文件进而触发流水线, 整个流程包含代码拉取、依赖安装、前后端构建、质量校验、镜像打包、远程部署, 完整脚本如下:# 定义流水线执行阶段按顺序依次运行 stages: - install # 前后端依赖安装 - build # 前后端生产构建 - test # 代码检查单元测试 - package # Docker镜像打包与推送 - deploy # 多环境自动化部署 # 全局变量复用GitLab内置变量无需手动修改 variables: DOCKER_REGISTRY: $CI_REGISTRY # GitLab容器仓库地址 IMAGE_NAME: $CI_REGISTRY_IMAGE # 镜像名称关联项目名称 IMAGE_TAG: $CI_COMMIT_SHORT_SHA # 镜像标签采用Git短提交哈希版本唯一 GIT_DEPTH: 0 # 关闭浅克隆保证代码完整 SPRING_PROFILE_TEST: test # 测试环境运行配置 SPRING_PROFILE_PROD: prod # 生产环境运行配置 # 全局缓存配置复用依赖包大幅缩短构建时间 cache: paths: - frontend/node_modules/ - backend/.m2/repository/ key: ${CI_PROJECT_ID} policy: pull-push # 前端依赖安装任务 install:frontend: stage: install image: node:18-alpine script: - cd frontend - npm config set registry https://registry.npmmirror.com - npm install --frozen-lockfile only: - main - develop # 后端依赖安装任务 install:backend: stage: install image: maven:3.9.6-openjdk-17 script: - cd backend - mvn dependency:go-offline only: - main - develop # 前后端同步构建任务 build:fullstack: stage: build image: docker:24-dind script: - cd frontend - npm run build # 前端生产打包生成dist静态资源 - cd ../backend - mvn clean package -DskipTests # 后端打包生成jar包 artifacts: paths: - frontend/dist/ - backend/target/*.jar expire_in: 3 days # 产物留存3天避免占用空间 only: - main - develop # 代码质量与单元测试任务 test:fullstack: stage: test image: maven:3.9.6-openjdk-17 script: - cd frontend - npm run lint # 前端ESLint代码规范检查 - cd ../backend - mvn clean test # 后端JUnit单元测试 allow_failure: false # 测试失败直接终止流水线禁止部署 only: - main - develop # 镜像打包推送至GitLab容器仓库 package:image: stage: package image: docker:24-dind services: - docker:24-dind script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $IMAGE_NAME:$IMAGE_TAG -t $IMAGE_NAME:latest . - docker push $IMAGE_NAME:$IMAGE_TAG - docker push $IMAGE_NAME:latest - docker system prune -af # 清理构建缓存释放空间 only: - main - develop # 自动部署至测试环境develop分支触发 deploy:test: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client docker-cli - mkdir -p ~/.ssh - echo $SSH_PRIVATE_KEY | tr -d \r ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh-keyscan $SERVER_HOST_TEST ~/.ssh/known_hosts script: - ssh $SERVER_USER$SERVER_HOST_TEST EOF docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY docker pull $IMAGE_NAME:$IMAGE_TAG docker stop fullstack-app || true docker rm fullstack-app || true docker run -d \ --name fullstack-app \ -p 8080:8080 \ --restart always \ -e SPRING_PROFILES_ACTIVE$SPRING_PROFILE_TEST \ $IMAGE_NAME:$IMAGE_TAG exit EOF only: - develop # 生产环境部署main分支触发需人工审批 deploy:prod: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client docker-cli - mkdir -p ~/.ssh - echo $SSH_PRIVATE_KEY | tr -d \r ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh-keyscan $SERVER_HOST_PROD ~/.ssh/known_hosts script: - ssh $SERVER_USER$SERVER_HOST_PROD EOF docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY docker pull $IMAGE_NAME:$IMAGE_TAG docker stop fullstack-app || true docker rm fullstack-app || true docker run -d \ --name fullstack-app \ -p 8080:8080 \ --restart always \ -e SPRING_PROFILES_ACTIVE$SPRING_PROFILE_PROD \ $IMAGE_NAME:$IMAGE_TAG exit EOF when: manual # 生产环境强制人工审批防止误发布 only: - main5.在4, CI/CD流水线脚本核心说明当中的六, 关于多环境部署与回滚机制设计的部分, 其中的6.1, 是多环境隔离方案。企业级项目当中, 要严格去区分开发环境, 与此同时, 也要严格区分测试环境, 并且, 还要严格区分预发环境, 另外, 也得严格区分生产环境, 基于CI/CD的一体化方案, 需严格遵循核心原则, 此原则为同一制品、不同配置, 依靠变量来实现环境完全隔离, 依靠变量来达成环境完全隔离。6.2 一键回滚机制核心保障依据CI/CD的方式进行版本回滚, 是不需要重新去构建代码的, 整个过程是依靠版本追溯以及有着那个能存储容器的仓库来达成的, 其操作方面极其简单, 速度又极其快速了, 这可是在故障应急的时候必须要有的一项操作呢:踏入项目的【CI/CD】板块里的【作业】页面, 寻觅到上一个稳定版本的流水线记录, 拷贝相应的镜像标签, 也就是Git短提交哈希。或是在流水线里, 重新去运行那对应版本的部署任务, 又或者是直接于目标服务器那里, 手动地去拉取该版本的镜像。将当前出现故障的容器予以停止, 让历史上稳定版本的容器启动起来, 整个过程当中不需要对代码进行修改, 也不需要再次进行打包构建。回滚程序所花费的时间, 一般情况下是不会超过1分钟的, 如此这般能够在最大程度上, 去缩减线上出现故障而产生的影响时长, 进而降低业务方面所遭受的损失。七、常见避坑指南与优化技巧高频坑点专属解决方案7.2 CI/CD进阶优化技巧八、总结与落地建议前后端一体化的CI/CD, 它可不是那种简单的脚本配置, 而是研发流程方面的标准化以及自动化的升级, 依靠着CI/CD来达成代码托管, 实现流水线执行, 有制品存储, 形成自动化部署全链路闭环, 全面解决前后端分离架构状况下, 部署出现割裂、版本产生错乱、人工操作存在风险高等核心痛点, 使得研发团队能够摆脱繁杂的手动部署工作, 进而专注于业务开发, 与此同时大幅提高发布效率以及系统稳定性。新组建的团队要先行去完成搭建以及注册的工作, 优先应当去采用执行者以此保证环境处于隔离状态, 从单一仓库加上标准的.-ci.yml脚本开始, 首先要让基础的构建、打包、部署流程能够顺利运行实施, 从而验证全链路具备可行性。依循“测试环境先行具有优势突出, 涉足生产环境务必谨慎考量”这般的准则要点, 首先实现分支自动部署针对测试环境予以推进落实, 待流程处于稳固状态之后, 接着开展配置main分支生产环境的人工审批部署相关工作, 按部就班以稳健态势推进而不出现贸然行事的情况。先开展前后端一体化方面的构建工作, 进行镜像打包操作, 实施基础多环境的部署工作, 然后逐步地去补充代码质量进行检查的能力, 补充单元实行测试的能力, 补充缓存进行优化的能力, 补充告警发出通知的能力, 进而逐步地完善流水线。竭力充分利用固有的内核能力, 所涵盖者包含CI/CD变量、现成的容器仓库、人力的审批, 以及流水线的历史追溯等等诸般, 削减跟第三方工具的依存关系, 并使得运维的复杂程度跟花费降低。从始至终, 始终坚守制品不可被改变、版本能够被追溯、自动化要优先、风险必须可控这四大原则, 以此去规范研发交付的流程, 从而杜绝因人工操作所带来的线上风险。按照本文专门设定的, 具备特性的方案去切实落地, 能够真正达成代码提交之后就自动进行构建, 构建通过那就自动开展部署, 从而塑造出具备高效特点、拥有低风险特质、有着可追溯属性的持续交付体系, 彻彻底底地摆脱手动部署所带来的繁杂琐碎以及潜在隐患, 使得前端与后端协同开展研发能够更为高效, 发布趋向于更加顺畅。刚开始的新手团队要先达成搭建以及注册, 是从单仓库加上基础的.-ci.yml脚本着手的, 先去对构建和部署的基础流程进行验证。首先进行优先落地分支的自动部署工作于测试环境状况下, 在其流程顺利运行通畅之后, 再着手去开展配置面向main分支的生产环境审批部署事宜, 需按稳扎稳打的态势推行而不做贸然激进之举。先达成前后端一体化的构建, 接着进行镜像的打包, 然后开展基础部署, 之后再一步步地去完善测试校验, 进行缓存优化, 实现多环境隔离以及构建告警机制。把内置能力充分加以利用, 这里的内置能力包含容器仓库, 包含CI变量, 还包含人工审批等等, 以此来减少对第三方工具的依赖, 进而降低运维成本。自始至终坚守着, 制品不能改变, 以及版本能够追寻来源, 还有自动操作优先这三个重要原则, 以此来确保发布的程序, 是规范且能够控制的。依据本文专门定制规划予以落实, 能够切实达成源代码提交便自动开展构建工作, 构建流程通过后便自动实施部署, 进而打造高成效、低风险的持续性交付体系, 完全告别发布阶段的加班现象, 促使前端与后端协同进行研发更为顺畅。倘若你的项目属于React与Node.js、Vue以及其他技术栈范畴, 存在需要精简流水线脚本、配置私有情形, 又或者要优化多环境审批流程的状况, 能够私信进行交流。