持续集成 Gitlab-CI 【Maven】【部署至服务器】

最新推荐文章于 2024-01-26 10:36:39 发布

宣之于口

最新推荐文章于 2024-01-26 10:36:39 发布

阅读量1w

点赞数 5

分类专栏：杂文-教程

本文链接：https://blog.csdn.net/loy_184548/article/details/82113956

版权

本文介绍了Gitlab-CI的持续集成概念，包括版本控制、集成服务器的重要性。详细阐述了Gitlab的注册Gitlab-runner步骤，并解析了.gitlab-ci.yml文件在构建过程中的作用。通过示例展示了如何使用Gitlab-CI进行Maven项目构建，并将打包后的应用部署到服务器。

摘要由CSDN通过智能技术生成

持续集成 Gitlab-CI

概念定义

原则

业界普遍认同的持续集成的原则包括：

需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 git、svn 等；
开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；
需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；
必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。

组成

一个自动构建过程，包括自动编译、分发、部署和测试等。
一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
一个持续集成服务器。

Gitlab

gitlab-ci作为gitlab提供的一个持续集成的套件，完美和gitlab进行集成。

1. 注册 Gitlab-runner

在 Gitlab 项目的 Setting–CI/CD-Runners settings 中我们可以对我们项目使用 Gitlab-runner 进行设置。
这里写图片描述
GitLab 中提供了两种 Runner 的类型，图 3 这个界面可以在 GitLab 项目设置页中找到的，一个是特定的 Specific Runner，另一个是共享的 Shared Runner 。特定的 Runner 只能供部分项目使用，而共享的 Runner 是所有GitLab 中的项目都可以使用的。而这两种类型的 Runner 的注册方式都是一样。

MAC下安装：

# Download
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64