| 手把手构建前端CI/CD：Gitlab | 您所在的位置：网站首页 › 如何搭建gitlab服务器 › 手把手构建前端CI/CD：Gitlab |
手把手构建前端CI/CD：Gitlab
|
手把手构建前端CI/CD：Gitlab-runner入门使用
再次认识CI/CD
大家近几年可能会经常听到CI/CD这样的名词啦，我也一样，大概也知道其意思就是：持续集成与持续部署，也知道它就是让我们的前端项目部署等能够自动进行，不需要我们手动进行，我们只需要关注代码实现，但是，由于没有亲自去配置过程整个CI/CD流程，导致始终觉得没有真正去理解其到底做了哪些工作。 这里，我们再次说明一下CI/CD到底是什么，以及结合Gitlab-runner来实际体验一下整个CI/CD的整个流程。 CI（Continuous Integration）：持续集成，什么是持续集成呢？通常就是指开发人员发起一起Merge Request(MR) 请求，该请求会触发一条流水线（pipleline）来进行 构建，单元测试等步骤，只有这些步骤验证通过以后，修改的代码才会被合并。（当然也不一定只有在MR的时候才会触发，自己的开发分支代码提交以后，也可以自动触发，这些都是可以配置的），例如：前端常见的 npm install, npm run build， npm run jest等操作都属于持续集成的部分。 CD（Continuous Deployment）：持续部署，通常就是将构建好的代码部署到生产环境这一流程能够自动化实现。CI侧重的是在开发阶段对代码是否符合要求进行验证，CD侧重的是在上线阶段能够将部署自动化实现。 常见CI/CD方案目前市场有很多成熟的CI/CD方案，能够帮助我们更好的去在项目中实现CI/CD，例如： Travis CI Jenkins Gitlab CI/CD至于Travis CI 和 Jenkins 这里就暂时不额外介绍啦，大家知道它的做什么的即可，这里我们重点通过Gitlab 自带的CI/CD来实际体验一下。 在此之前，首先把涉及到的相关名词稍微说明一下，以免混淆。 Github：即一个面向开源及私有软件项目的托管平台 Gitee：中文码云，即国内Github之称。 Gitlab：一般用于在企业内搭建git私服，要自己搭环境。 Git： 是一种版本控制系统，是一个命令，是一种工具。总结： github针对企业要收费，那当然是不同意，毕竟都想节约资金，那就还能使用gitee，或者gitlab了。 但是码云虽然是免费的，而且不用自己搭环境，但是企业中把项目放在别人的服务器上，始终没有安全感。 因此，衍生出了gitlab，就是用于企业搭私服，而且还是在自己的服务器上。最后，再说一下Gitlab CI/CD相关的名词： Gitlab CI/CD： 即表示Gitlab 自带 CI/CD的能力 Gitlab-runner：是配合Gitlab CI/CD完成工作的核心程序，出于性能考虑，GitLab Runner应该与Gitlab部署在不同的服务器上（Gitlab在单独的仓库服务器上，GitLab Runner在部署web应用的服务器上）。GitLab Runner在与GitLab关联后，可以在服务器上完成诸如项目拉取、文件打包、资源复制等各种命令操作。 手把手搭建Gitlab-runner环境首先说一下大致流程： 创建前端项目，以及.gitlab-ci.yml文件 本地安装gitlab-runner，并且通过注册的方式与我们的前端项目进行关联。 然后当前端代码修改，并且提交以后，就会自动执行.gitlab-ci.yml脚本中的内容。接下来，我们一步步来实现： 创建前端项目，我们这里以vue项目为例。 vue create front-devops-demo cd front-devops-demo 复制代码创建.gitlab-ci.yml文件 stages: - init - build cache: key: ${CI_BUILD_REF_NAME} paths: - node_modules/ - dist/ init: stage: init script: - npm install build: stage: build script: - npm run build 复制代码我们之后会详细解释该文件的具体配置，此处我们只需要知道，该文件定义了init 和 build两个阶段（即stage），然后在流水线中也会创建两个对应的任务（即job）。 安装gitlab-runner 这里，我们是在mac本地试验，因此，使用homebrew安装即可（当然也可以使用docker等进行安装） brew install gitlab-runner 复制代码注册gitlab-runner，与前端仓库进行关联 // 执行注册命令 gitlab-runner register 复制代码然后就会出现一系列选项，需要我们手动输入： Enter the GitLab instance URL (for example, gitlab.com/): gitlab.com/ Enter the registration token: xxx Enter a description for the runner: test Enter tags for the runner (comma-separated): test Enter optional maintenance note for the runner: test Enter an executor: ssh, virtualbox, docker-ssh+machine, instance, parallels, shell, docker-ssh, docker+machine, kubernetes, custom, docker: shell这里，我们重点关注一下其中几项，首先是前两项，我们可以在我们的仓库中查看：前端仓库 -> Settings -> CI/CD -> Runners 注意：上面这两项是我们本地Git-runner与仓库进行关联的关键，只有这样当仓库代码提交以后，才会使用本地Git-runner执行具体的任务。 然后，第六项，也很关键，即使用什么来执行Git-runner，由于我们目前是直接在本地安装的Gitlab-runner，自然而然也是直接在本地通过shell命令来执行，因此输入shell即可。 选项全部输入完之后，点击回车，gitlab-runner register这个命令就执行成功啦，即注册完成，即本地的Gitlab-runner与我们的项目也关联成功。此时 我们再次查看前端仓库 -> Settings -> CI/CD -> Runners 可以看到 一个正在运行的runner。 本地更新代码，然后提交至远程仓库，就会自动触发CI/CD操作，我们就可以在 前端仓库 -> CI/CD -> Pipelines中查看我们当前这次的构建任务 的状态。 注意：可能有的同学默认情况下，一直处于pedding状态，这是因为默认情况下，Gitlab CI/CD 只会对打了tag的commit进行构建，而我们执行了多次commit，但是没有打tag，所以没有触发构建，我们可以按照如下配置进行勾选即可。 当我们在自己的项目中配置好.gitlab-ci.yml后，然后提交代码，就可以触发Gitlab CI， 我们可以在Gitlab -> CICD可以看到如图所示，启动的Pipeline 其中，我们可以看到流水线中有很多条构建记录，每条构建记录，都有对应的状态，构建记录ID，commit ID，以及对应的包含几个stage等。 Jobs - 任务Jobs 相当于就是我们在.gitlab-ci.yml文件中定义的具体任务，可能会有很多。 |
【本文地址】