前端持续集成和持续部署简介

电玩女神 2022-11-29 03:09 254阅读 0赞

**传统开发的坑：**

*  BUG总是在最后才发现
 *  越到项目后期，加班越严重
 *  交付无法保障
 *  变更频繁导致效率低下
 *  无效的等待多， 用户满足度低

**持续集成解决的问题：**

*  提高质量
 *  效率迭代
 *  便捷部署
 *  快速交付， 便于管理

环境准备：  
Linux服务器  
VSCode + 插件Dockerfile

## 1. 概念 ##

**持续集成**（Continuous Integration）简称CI:  
核心概念：零散的汇聚起来，将所有开发者工作副本每天多次合并到主干的做法, 团队成员一般每人每天至少集成一次, 也可以多次. 持续集成强调开发人员提交了新代码之后, 立刻进行构建, 测试, 根据测试结果, 可以确定新代码和原有代码能否正确集成在一起

**持续交付**（Continuous Delivery）简称CD:  
完成 CI 中构建及单元测试和集成测试的自动化流程后, 持续交付可自动将已验证的代码发布到存储库, 为了实现高效的持续交付流程, 务必要确保 CI 已内置于开发管道. 持续交付的目标是拥有一个可随时部署到生产环境的代码库  
在持续交付中, 每个阶段(从代码更改的合并, 到生产就绪型构建版本的交付) 都涉及测试自动化和代码自动发布. 流程结束时, 运维团队可以快速将应用部署到生产环境中.

**持续部署**（Continuous Development）简称CD:  
对于一个成熟的 CI/CD 管道来说, 最后阶段是持续部署. 是在持续交付的基础上, 把部署到生产环境的过程自动化.

## 2. 持续集成组成要素 ##

一个最小化的持续集成系统需要包含以下几个要素:

1.  版本管理系统 github, gitlab, stash 等
2.  构建脚本&工具: 每个项目都需要有构建脚本来实现对整个项目的自动化构建, 比如 java 的项目可使用 gradle 作为构建工具, 通过构建工具实现对编译, 静态扫描, 运行测试, 样式检查, 打包, 发布等活动串起来, 可通过命令行自动执行
3.  CI 服务器: 可以检测项目中的代码变动, 并及时通过构建机器运行构建脚本, 并将集成结果通过某种方式反馈给团队成员

## 3. 应用场景 ##

*  打包平台  
    常见的打包, Java 应用(Gradle/Maven), Nodejs 前端应用(npm/yarn)  
    移动端打包 IOS/Android
 *  测试平台  
    接口测试  
    自动化  
    单元性能
 *  自动部署  
    FTP  
    Shell  
    Tomcat/Docker  
    K8s/Rancher/Cluster
 *  持续集成  
    git  
    Jenkins/TravisCI/CircleCI  
    Docker

## 4. 工作流 ##

1.  **传统的工作流**  
    传统的瀑布式  
    人员: 开发, 项目经理, 测试  
    **主要流程:**  
    项目开始划分好模块, 分配模块给对应人员  
    开发人员开发好一个模块就进行单元测试  
    等所有模块都开发完成之后, 项目经理对所有代码进行集成  
    集成后的项目部署到测试服务器, 交由测试人员进行集中测试  
    测试过程中出现 BUG 把问题记录到列表  
    分配 BUG 给相应人修改  
    修改完成, 再次对项目进行集中测试, 并部署到测试服务器  
    测试人员在下一次的集成测试中进行回归测试  
    通过之后部署到生产环境中  
    测试不通过, 则重复上述"分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试" 工作
    
    **带来的问题:**
    
    1.  重复性劳动, 无效等待增多
    2.  很晚才发现缺陷, 且难以修复
    3.  品质低
    4.  项目缺少可见性

--------------------

1.  **常见的工作流**  
    DevOps  
    该系统的各个组成部分是按如下顺序来发挥作用的:
    
     *  开发者检入代码到源代码仓库
     *  CI系统会为每一个项目创建一个单独的工作区, 当预设或请求一次新的构建时, 它将把源代码仓库的源码存放到对应的工作区
     *  CI系统会在对应的工作区内执行的构建过程
     *  (配置如果存在). 构建完成后, CI系统会在一个新的构件中执行定义的一套测试. 完成后触发通知(Email, RSS等)给相关责任人
     *  (配置如果存在) 如果构建成功, 这个构件会被打包并转移到一个部署目标(比如应用服务器)或存储为软件仓库中的一个新版本, 软件仓库可以是CI系统的一部分, 也可以是一个外部的仓库, 诸如一个文件服务器或者像Java.net, SourceForge之类的网站
     *  CI系统通常会根据请求发起相应的操作, 诸如即时构建, 生成报告, 或者检索一些构建好的构件

--------------------

## 5. Travis CI使用简介 ##

1.  简单的使用步骤  
    github授权及面板  
    获取gihub的Tokens  
    配置项目.travis.yml  
    Node项目  
    Script脚本  
    部署到github pages  
    钩子用法