各种网站末班,amh wordpress,如何做贷款网站,免费做网站公司ydwzjsCI/CD是什么 CI/CD#xff08;Continuous Intergration/Continuous Delpoy#xff09;#xff0c;即持续集成/持续部署#xff0c;或称为持续集成/持续交付#xff0c;作为一套面向开发和运维团队的解决方案#xff0c;CI/CD 主要解决集成新代码和向用户频繁交付应用的问…CI/CD是什么 CI/CDContinuous Intergration/Continuous Delpoy即持续集成/持续部署或称为持续集成/持续交付作为一套面向开发和运维团队的解决方案CI/CD 主要解决集成新代码和向用户频繁交付应用的问题。更直接地说就是可以解放开发人员的双手将时间和精力专注于代码本身。 传统的前端部署往往都要经历本地代码更新 本地打包项目 清空服务器相应目录 上传项目包至相应目录几个阶段这些都是机械重复的步骤并且手动操作非常容易出错。对于这一过程我们往往可以通过CI/CD 方式进行优化。 从前端的角度看CICD的流程中涉及 CI代码push到托管平台之后的lint测试、单元测试 CD将build后的项目丢到远端 Nginx 的静态资源目录下
自动化部署的好处 按照传统方式 时间成本高手动部署占用开发时间。 沟通效率低开发与测试间沟通频繁且易出错。 错误风险高人为操作易导致配置错误等问题。 难以追踪缺乏统一的日志记录和追踪。 灵活性差难以快速响应紧急部署需求。 使用自动化部署 节省时间自动完成部署流程提升开发效率。 提高沟通效率实时共享部署状态减少沟通成本。 减少错误降低人为错误提高部署稳定性。 增强代码质量集成代码检查确保代码质量。 提高灵活性快速响应代码变更和紧急部署。 增强可追溯性记录详细日志便于问题追踪。 支持CI/CD加速产品迭代和交付。
构建/部署 说的简单点就是先利用 webpack 或者 gulp 这类的工具把工程打包然后把打包得到的文件放在服务器上某个托管静态资源的 Web 容器里像 Java 就可以放在 Tomcat不过现在流行用 Nginx 托管静态资源。有了 Web 容器前端打包的那些文件比如index.html, main.js等等就可以被访问到了。
手动档 1、本地执行 npm run build构建项目
2、使用 FileZilla 或其他支持 sftp 的软件上传打包后的项目当然也有其他方式
3、修改 Nginx 的 nginx.conf 文件配置项目的访问路径 手动部署操作起来很简单但缺点也很明显每次构建完都要人为地进行部署的动作一方面减少了实际敲代码的时间另一方面人工操作免不了会有疏忽出错的时候。
半自动挡 1、本地配置好脚本
2、使用 package.json 中配置的命令执行
3、等待自动打包上传流程结束 虽然这样的操作也很方便且不易出错但每次都要等待代码打包上传完了才能下机还是挺浪费时间的。
自动挡 随着工程化的发展和工具链的成熟项目部署不再像以前简单粗暴。前端代码的健壮性、可靠性越来越被重视项目发布前往往需要 代码约束 和 代码测试 校验通过后服务器拉取最新的代码进行 build 和 nginx 配置后才算完成整个部署的过程。 1、代码扫描 npm run lint检查代码是否规范
2、npm run unit进行单元测试
3、git push提交更改到远端仓库
4、登录服务器git pull拉取最新代码
5、npm run build构建项目
6、配置 nginx 访问路径
6、配置 nginx 访问路径 这个阶段我们借助一些工具能够减少代码不规范或隐藏bug的问题。 但所有的操作还是得一行一行命令去敲项目真正的部署也还是需要手动去操作服务器。也可以将上面的操作细节都集成到一个 shell 脚本里通知执行 shell 也能减少很多重复的工作。
CI/CD 做了什么 一个版本发布的过程主要分为以下几个步骤 代码合并测试环境或生产环境都有独立的分支等所有待发版的代码都合并到对应分支后就可以考虑发版了。 打包或者叫构建。以生产环境部署为例我们切到生产环境分支并 pull 最新代码后就可以开始打包步骤了。这一步主要是通过一些 bundler 完成的比如 webpack。而打包命令一般都是定义在package.json的scripts中了比如定义的命令是build:prod那么只要运行npm run build:prod就行了。 部署把打包得到的文件放在 web 容器中而 web 容器通常在 Linux 服务器上这涉及到远程传输文件这个时候我们一般要借助 shell 脚本或者 xftp。 而 CI/CD 做的事情就是用自动化技术接管流程。 核心工具
GitLab Runner GitLab Runner是配合GitLab CI/CD完成工作的核心程序出于性能考虑GitLab Runner应该与Gitlab部署在不同的服务器上Gitlab在单独的仓库服务器上GitLab Runner在部署web应用的服务器上。GitLab Runner在与GitLab关联后可以在服务器上完成诸如项目拉取、文件打包、资源复制等各种命令操作。
Git web服务器上需要安装Git来进行远程仓库的获取工作。
Node 用于在web服务器上完成打包工作。
NPM or Yarn or pnpm 用于在web服务器上完成依赖下载等工作用yarn,pnpm亦可。 Gitlab CI/CD是如何工作的 从 GitLab 8.0 开始GitLab CI 就已经集成在 GitLab 中我们只要在项目中添加一个 .gitlab-ci.yml 文件然后添加一个 Runner即可进行持续集成。 而且随着 GitLab 的升级GitLab CI 变得越来越强大。
Pipeline Pipeline 是 CI/CD 的最上层组件它翻译过来是管道也可理解为流水线每一个符合.gitlab-ci.yml触发规则的 CI/CD 任务都会产生一个 Pipeline。这个概念有点像工厂中的车间流水线我们知道车间中有很多条流水线不同的流水线可能会处理同一类型的生产任务也可能处理不同类型的生产任务。当一条流水线空闲的时候就有可能会被用来安排执行其他的生产任务。而 Gitlab 的 Pipeline 虽然没有空闲的概念一个 Pipeline 执行结束后也不会被复用但是会将资源让出来给其他的 Pipeline所以和车间流水线也有异曲同工之妙。 一次 Pipeline 其实相当于一次构建任务里面可以包含多个流程如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。我们的任何提交或者 Merge Request 的合并都可以触发 Pipeline。 不同 push/merge 所触发的 CI 流程不会互相影响也就是说你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断它们是互不影响的。这一个特点方便让测试同学根据不同版本进行测试。 Stages Stages 表示构建阶段其实就是上面提到的流程。我们可以在一次 Pipeline 中定义多个 Stages每个Stage可以完成不同的任务。一个 Pipeline 有若干个stage每个 stage 上有至少一个 Job。Stages 有下面的特点 所有 Stages 会按照顺序运行即当一个 Stage 完成后下一个 Stage 才会开始 只有当所有 Stages 完成后该构建任务 (Pipeline) 才会成功 如果任何一个 Stage 失败那么后面的 Stages 不会执行该构建任务 (Pipeline) 失败 Jobs Jobs 表示构建工作就是某个 Stage 里面执行的工作。Job是pipeline的任务节点它构成了pipeline的基本单元。我们可以在 Stages 里面定义多个 Jobs每个Job都会配置一个stage属性表示这个Job所处的阶段。Jobs 有以下特点 相同 Stage 中的 Jobs 会并行执行 相同 Stage 中的 Jobs 都执行成功时该 Stage 才会成功 如果任何一个 Job 失败那么该 Stage 失败即该构建任务 (Pipeline) 失败 Runner 有了流水线还必须有辛勤的工人进行生产作业Runner 在 Gitlab Pipeline 中就扮演着工人角色根据我们下达的指令进行作业。 它是脚本执行的承载者.gitlab-ci.yml 的 script 部分的运行就是由 Runner 来负责的。GitLab-CI 浏览过项目里的 .gitlab-ci.yml 文件之后根据里面的规则分配到各个 Runner 来运行相应的脚本 script。这些脚本有的是测试项目用的有的是部署用的。 Runner的类型 在 Gitlab 中Runner 有很多种分为 Shared Runner, Group Runner, Specific Runner。 Shared Runner 是所有项目都可以使用的可以理解为机动人员他可能会在工厂的各个流水线机动作业随时支援在整个 Gitlab 应用中可以服务于各个 Project。使用受运行时间的限制。 Specific Runner 只服务于指定的项目也就是 Project 级别别的项目咱都不去。使用完全自由。 Group Runner 就比较好理解了他只在这个组上班别的组他是不会去的。在 Gitlab 中我们是可以建立不同的 Group 的比如前端一个 Group后端一个 Group甚至前端里面还可以分 N 个 Group。所以Group Runner 只服务于指定的 Group。 注册Runner 工人是要持证上岗的同样Runner 有一个注册的过程就相当于在工厂中入职登记的意思。具体见 Registering Runners。只有合法注册的 Runner才有资格执行 Pipeline。
.gitlab-ci.yml 流水线和工人都安排好之后就必须制定车间生产规章制度了一条流水线到底怎么干活总要有个规矩。而.gitlab-ci.yml文件就是用来制定规则的它是流水线执行的流程文件Runner 会据此完成规定的一系列流程保存并推送至 gitlab 后即可自动开始构建部署构建中可在 gitlab CI/CD 面板查看构建进程。 .gitlab-ci.yml 是在 git 项目的根目录下的一个文件记录了一系列的阶段和执行规则。GitLab-CI 在 push 后会解析它根据里面的内容调用 Runner 来运行。简单来讲就是当我们 push 了本地代码到 Remote 上(这里就是 gitlab.com)然后 Gitlab就通知服务器即 Gitlab-Runner 来运行构建任务。然后跑测试用例测试用例通过了就 build 出相应的环境的代码自动部署到不同的环境服务器上面去。 配置好 Runner 后我们要做的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了可以控制 CI 流程的不同阶段例如install/检查/编译/部署服务器gitlab 平台会扫描.gitlab-ci.yml文件并据此处理ci流程。 当我们添加了 .gitlab-ci.yml 文件后每次提交代码或合并 MR 都会自动运行构建任务了。 CI 流程在每次 push/merge 之后触发每当 push/merge 一次gitlab-ci 都会检查项目下有没有 .gitlab-ci.yml 文件如果有它会执行里面编写的脚本并完整地走一遍从 intall eslint检查 编译 部署服务器 的流程。 变量 Variables Gitlab 通过 Variables 为 CI/CD 提供了更多配置化的能力方便我们快速取得一些关键信息用来做流程决策。上述示例中的$CI_COMMIT_REF_NAME和$CI_PROJECT_DIR就是 Gitlab 的预定义变量。 除了预定义变量我们也可以自行定义一些环境变量比如服务器 ip用户名等等这样就免去了在配置文件中明文列出私密信息的风险另一方面也方便后期快速调整配置避免直接修改.gitlab-ci.yml。 授信问题 在不同主机间通过scp传输文件需要建立信任关系在 CI/CD 中最好选择免密方式其基本原理就是把 ssh公钥 交给对方。 在 GitLab 的 CI/CD 流程中使用 scp 或任何基于 SSH 的命令来在不同的主机之间传输文件时需要建立一种安全的免密登录方式。这通常通过 SSH 密钥认证来实现即将一个 SSH 公钥添加到远程服务器的 ~/.ssh/authorized_keys 文件中这样持有相应私钥的用户就可以无密码登录该服务器了。
使用Gitlab实现多项目CICD
背景 有一个 monorepo 微前端项目需要一次构建3个项目放在根目录下的packages文件夹下分别是rdm、rdm-old、rdm-new在测试分支打包分别生成自己的 dist/test正式服则是 dist/prod正式服构建到 A 服务器的 rdm、rdm-old、rdm-new 文件夹测试服到 B 服务器的 rdm、rdm-old、rdm-new 文件夹。现在我们希望在一次CI/CD流程中构建并部署多个子应用rdm, rdm-new, rdm-old同时这些应用需要被部署到不同服务器上的不同的 FTP 目录。 用直观的方式呈现如下图 方案 为了实现这个需求我们可以在.gitlab-ci.yml文件中设置一个共同的构建阶段然后针对不同的环境测试服和正式服和不同的子应用设置不同的部署阶段。 # 定义CI/CD的阶段
stages: - build # 构建阶段 - deploy # 部署阶段 # 定义一些全局变量用于SSH连接和部署
variables: SSH_USER: 用户名 SSH_PASSWORD: 用户密码 SSH_OPTIONS: -o StrictHostKeyCheckingno # 定义一个模板用于SSH部署
.deploy_template: deploy_template stage: deploy script: - echo Deploying to $TARGET_SERVER in $DEPLOY_PATH - sshpass -p $SSH_PASSWORD ssh $SSH_USER$TARGET_SERVER mkdir -p $DEPLOY_PATH - sshpass -p $SSH_PASSWORD scp -r $SSH_OPTIONS ./dist/$DEPLOY_TYPE/* $SSH_USER$TARGET_SERVER:$DEPLOY_PATH # RDM 构建和部署
rdm-build: stage: build script: # 构建脚本- cd packages/rdm - pnpm install - pnpm run build:$CI_COMMIT_REF_NAME # 假设你有一个脚本来根据分支构建到不同的目录 - | # 使用管道符来在单行中写多条命令,如果是主分支,将dist目录重命名为dist/prod if [ $CI_COMMIT_REF_NAME main ]; then mv dist dist/prod else mv dist dist/test fi artifacts: # 指定要保留的构建产物 paths: - packages/rdm/dist/prod/ # 如果需要包含主分支的产出 - packages/rdm/dist/test/ # 如果需要包含非主分支的产出 rdm-deploy-prod: : *deploy_template variables: # 覆盖模板中的变量 TARGET_SERVER: 正式服-服务器 A 地址 DEPLOY_PATH: /rdm # 部署路径 DEPLOY_TYPE: prod # 部署类型only: # 仅当提交到prod分支时运行- prod rdm-deploy-test: : *deploy_template variables: TARGET_SERVER: 测试服-服务器 B 地址 DEPLOY_PATH: /rdm DEPLOY_TYPE: test except: - main # RDM-OLD
rdm-old-build: stage: build script: - cd packages/rdm-old - pnpm install - pnpm run build:$CI_COMMIT_REF_NAME # 假设你有一个脚本来根据分支构建到不同的目录 - | # 使用管道符来在单行中写多条命令 if [ $CI_COMMIT_REF_NAME main ]; then mv dist dist/prod else mv dist dist/test fi artifacts: paths: - packages/rdm-old/dist/prod/ # 如果需要包含主分支的产出 - packages/rdm-old/dist/test/ # 如果需要包含非主分支的产出 rdm-old-deploy-prod: : *deploy_template variables: TARGET_SERVER: 正式服-服务器 A 地址 DEPLOY_PATH: /rdm-old DEPLOY_TYPE: prod only: - prod rdm-old-deploy-test: : *deploy_template variables: TARGET_SERVER: 测试服-服务器 B 地址 DEPLOY_PATH: /rdm-old DEPLOY_TYPE: test except: - main # RDM-NEW
rdm-new-build: stage: build script: - cd packages/rdm-new - pnpm install - pnpm run build:$CI_COMMIT_REF_NAME # 假设这个脚本会根据分支名称构建到不同的目录但实际上它不会改变dist的目录名 - | # 使用管道符来在单行中写多条命令 if [ $CI_COMMIT_REF_NAME main ]; then mv dist dist/prod else mv dist dist/test fi artifacts: paths: - packages/rdm-new/dist/prod/ # 如果需要包含主分支的产出 - packages/rdm-new/dist/test/ # 如果需要包含非主分支的产出 rdm-new-deploy-prod: : *deploy_template variables: TARGET_SERVER: 正式服-服务器 A 地址 DEPLOY_PATH: /rdm-new DEPLOY_TYPE: prod only: - prod rdm-new-deploy-test: : *deploy_template variables: TARGET_SERVER: 测试服-服务器 B 地址 DEPLOY_PATH: /rdm-new DEPLOY_TYPE: test except: - main 参考资料 Tutorial: Create and run your first GitLab CI/CD pipeline | GitLab 前端自动化部署借助Gitlab CI/CD实现 - 掘金 (juejin.cn) 前端的gitlab的ci初尝试 - 掘金 (juejin.cn) 花半天时间轻松打造前端CI/CD工作流 - 掘金 (juejin.cn)
文章转载自： http://www.morning.mnqg.cn.gov.cn.mnqg.cn http://www.morning.tlbdy.cn.gov.cn.tlbdy.cn http://www.morning.trfrl.cn.gov.cn.trfrl.cn http://www.morning.csznh.cn.gov.cn.csznh.cn http://www.morning.ggtgl.cn.gov.cn.ggtgl.cn http://www.morning.khxwp.cn.gov.cn.khxwp.cn http://www.morning.srndk.cn.gov.cn.srndk.cn http://www.morning.mqss.cn.gov.cn.mqss.cn http://www.morning.nqbs.cn.gov.cn.nqbs.cn http://www.morning.rbmm.cn.gov.cn.rbmm.cn http://www.morning.kwwkm.cn.gov.cn.kwwkm.cn http://www.morning.sfgzx.cn.gov.cn.sfgzx.cn http://www.morning.zpzys.cn.gov.cn.zpzys.cn http://www.morning.xinyishufa.cn.gov.cn.xinyishufa.cn http://www.morning.zhmgcreativeeducation.cn.gov.cn.zhmgcreativeeducation.cn http://www.morning.qgdsd.cn.gov.cn.qgdsd.cn http://www.morning.gxwyr.cn.gov.cn.gxwyr.cn http://www.morning.rjhts.cn.gov.cn.rjhts.cn http://www.morning.lqytk.cn.gov.cn.lqytk.cn http://www.morning.fdmtr.cn.gov.cn.fdmtr.cn http://www.morning.jtdrz.cn.gov.cn.jtdrz.cn http://www.morning.txysr.cn.gov.cn.txysr.cn http://www.morning.zymgs.cn.gov.cn.zymgs.cn http://www.morning.fbbpj.cn.gov.cn.fbbpj.cn http://www.morning.khfk.cn.gov.cn.khfk.cn http://www.morning.rqxch.cn.gov.cn.rqxch.cn http://www.morning.fthcn.cn.gov.cn.fthcn.cn http://www.morning.qfwfj.cn.gov.cn.qfwfj.cn http://www.morning.drfcj.cn.gov.cn.drfcj.cn http://www.morning.bdtpd.cn.gov.cn.bdtpd.cn http://www.morning.qnbgh.cn.gov.cn.qnbgh.cn http://www.morning.gfrtg.com.gov.cn.gfrtg.com http://www.morning.wkmrl.cn.gov.cn.wkmrl.cn http://www.morning.bbjw.cn.gov.cn.bbjw.cn http://www.morning.wdhzk.cn.gov.cn.wdhzk.cn http://www.morning.msfqt.cn.gov.cn.msfqt.cn http://www.morning.zxzgr.cn.gov.cn.zxzgr.cn http://www.morning.dhtdl.cn.gov.cn.dhtdl.cn http://www.morning.sskhm.cn.gov.cn.sskhm.cn http://www.morning.pmdlk.cn.gov.cn.pmdlk.cn http://www.morning.rnzwh.cn.gov.cn.rnzwh.cn http://www.morning.xdpjs.cn.gov.cn.xdpjs.cn http://www.morning.nqwz.cn.gov.cn.nqwz.cn http://www.morning.jnvivi.com.gov.cn.jnvivi.com http://www.morning.pclgj.cn.gov.cn.pclgj.cn http://www.morning.ndynz.cn.gov.cn.ndynz.cn http://www.morning.jhxtm.cn.gov.cn.jhxtm.cn http://www.morning.mfrb.cn.gov.cn.mfrb.cn http://www.morning.bdkhl.cn.gov.cn.bdkhl.cn http://www.morning.rwtlj.cn.gov.cn.rwtlj.cn http://www.morning.ptwzy.cn.gov.cn.ptwzy.cn http://www.morning.zycll.cn.gov.cn.zycll.cn http://www.morning.bpmfr.cn.gov.cn.bpmfr.cn http://www.morning.fycjx.cn.gov.cn.fycjx.cn http://www.morning.dbjyb.cn.gov.cn.dbjyb.cn http://www.morning.dbfp.cn.gov.cn.dbfp.cn http://www.morning.kfcfq.cn.gov.cn.kfcfq.cn http://www.morning.dpppx.cn.gov.cn.dpppx.cn http://www.morning.kuaijili.cn.gov.cn.kuaijili.cn http://www.morning.ryglh.cn.gov.cn.ryglh.cn http://www.morning.xjmyq.com.gov.cn.xjmyq.com http://www.morning.hncrc.cn.gov.cn.hncrc.cn http://www.morning.nmqdk.cn.gov.cn.nmqdk.cn http://www.morning.wmmjw.cn.gov.cn.wmmjw.cn http://www.morning.nspzy.cn.gov.cn.nspzy.cn http://www.morning.xyyplp.cn.gov.cn.xyyplp.cn http://www.morning.qgfy.cn.gov.cn.qgfy.cn http://www.morning.lmfmd.cn.gov.cn.lmfmd.cn http://www.morning.hytfz.cn.gov.cn.hytfz.cn http://www.morning.nnhrp.cn.gov.cn.nnhrp.cn http://www.morning.drspc.cn.gov.cn.drspc.cn http://www.morning.nnjq.cn.gov.cn.nnjq.cn http://www.morning.tmnyj.cn.gov.cn.tmnyj.cn http://www.morning.mbprq.cn.gov.cn.mbprq.cn http://www.morning.cbpmq.cn.gov.cn.cbpmq.cn http://www.morning.flxgx.cn.gov.cn.flxgx.cn http://www.morning.xqgh.cn.gov.cn.xqgh.cn http://www.morning.rwdbz.cn.gov.cn.rwdbz.cn http://www.morning.qxwwg.cn.gov.cn.qxwwg.cn http://www.morning.mbpzw.cn.gov.cn.mbpzw.cn
