在注册Runner时候这里输入了tag,这里指的是runner的标签,可以设置多个  ,分别用 ,号分割 .gitlab-ci.yml文件中 stages: - pull - package - build - restart - clean pull: stage: pull script: - cd /usr/local/xiangmu/weixin - git pull git@git.lug.ustc.edu.cn:complete/weixin.git package: stage:

以Spring boot项目为例.传统方式是本地生成jar包,FTP上传服务器,重启服务:如果是内网测试服,也可以在服务器上安装git,在服务器上编译打包.但这都需要人为干预,于是CI/CD就出现了. CI:Continuous Integration(持续集成).自动构建和测试每次提交的代码,以确保所引入的更改符合所有测试.准则和代码合规性标准. CD:Continuous Delivery(持续交付)和Continuous Deployment(持续部署).基于CI,前者侧重于交付给客户或质

GitlabCI实践 GitLabCI/CD基础概念 为什么要做CI/CD? GitLab CI/CD简介 GitLabCI VS Jenkins 安装部署GitLab服务 GitLabRunner实践 GitlabRunner简介 GitLabRunner安装 GitLabRunner注册 GitLabRunner命令 运行测试流水线任务 GitLabPipeline语法 pipeline syntax 1 pipeline syntax 2 pipeline syntax 3 pipelin

引言 看过前文的博友可能注意到我是把 部署dll文件拷贝到生产机器,之后在生产机器上使用docker-compose即时创建镜像, 并没有完成CI/CD, 只是在原来传统部署方式下 将部署文件容器化. 经过长时间实操验证,终于完成基于Gitlab的CI/CD实践,本次实践的坑位很多, 实操的过程尽量接近 最佳实践(不做hack, 不做骚操作),记录下来也方便自己加深理解. 第一部分: Gitlab CI/CD 原理 和 Gitlab Runner 安装(这里使用shell执行器) 第二部分: G

Gitlab-Runner自动构建服务器搭建2 注册Runner 上一节我们创建了自己的gitlab-runner镜像,并使用docker-compose up -d --build命令运行了一个名为gitlab-runner-compose的容器: 1.执行register命令注册runner; docker exec -it gitlab-runner-compose gitlab-runner-andy register 2.输入你自己项目仓库所在gitlab实例的URL: Please

Gitlab-Runner自动构建服务器搭建1 这里讲到的gitlab仓库指的是https://gitlab.com/,自建gitlab仓库也基本相同. 项目的构建打包过程相对比较消耗系统性能,所以gitlab将这部分任务都交给了gitlab-runner来做,因为gitlab-runner可以部署到不同的机器上.这样在构建的时候就不会影响gitlab服务器的性能.而gitlab ci仅用来管理项目的构建状态等轻量工作. gitlab仓库提供了两种Runner自动构建的方案:一种是Specifi

0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 一.前言 在之前的文章中写过k8s+Jenkins+GitLab-自动化部署asp.net core项目 的topic,这次讲解一下gitlab-ci的CI/CD,说实话,自动化部署是在是非常的舒服,而且gitlab-ci很适合中小项目的部署,大项目推荐使用k8s. 阅读目录: 1.gitlab-ci及gitlab-runner说明 2.部署环境介绍 3.安装gitlab和gitlab-runner 4.asp.net cor

长话短说,今天分享我为前后端分离项目搭建Gitlab CI/CD流程的一些额外经验. Before Gitlab-ci是Gitlab提供的CI/CD特性,结合Gitlab简单友好的配置界面,能愉悦的在Gitlab界面查看管道执行流程,并自然流畅的推动敏捷开发流程. Gitlab-CI/CD的核心是搭建Gitlab Runner.编写.gitlab-ci.yaml文件. 详细示例请参考:Gitlab CI/CD+ASP.NETCore. 本次前后端两个项目使用同一个Gitlab Runner(sh

转载:Gitlab-CI使用及.gitlab-ci.yml配置入门一篇就够了 - 简书 (jianshu.com) 一. Gitlab-CI/CD使用场景 首先,公司使用Gitlab作为工作仓库进行代码发布及版本控制,Gitlab内置了CI/CD的工具,这些工具可以用于代码提交的同时完成镜像构建.自动化测试.自动化部署等连续的工作: CI: Continuous Integration(持续集成) CD: Continuous Delivery(连续交付) CD: Continuous Depl

0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 一.微服务选型 在做微服务架构的技术选型的时候,我们以“无侵入”和“社区活跃”为主要的考量点,将来升级为原子服务架构.量子服务架构的时候.甚至恢复成单体架构的时候,代价最小.因此软件开发只需要组装,不再需要从头开发. 选型也可以参考一下张队长的文章:微软MVP张善友告诉你,微服务选型要注意这些地方 二.微服务架构是什么? 按照我的理解介绍一下微服务架构是什么吧. 每一个微服务都是一个零件,并使用这些零件组装出不同的形状.微服务

人过35,被年轻人卷走了一大半,还停留在这个行业的,不是在创业,就是在创业的路上. 创业很难,刚开始没钱没人,啥都要自己干,一个字累.好处是地基是自己搭的,心里有底.不过博主最近健忘的毛病愈发严重了,趁还清醒纪录点滴. PaaS 博主做的是物联网项目,目前涉及到的通信协议有lora.4G/Cat1.BLE,传输协议有MQTT.HTTP.TCP私有协议.大致草图如下: 一般来说,MQTT能满足大部分业务需求,但在某些场景比如文件下发/自定义分包拼包时处理起来比较复杂,这时使用HTTP更合适,但对于

写在前面 记录一下,一个自动化开发部署项目的构建过程与简单使用,实现真正的DevOps gitlab安装 步骤一:安装依赖 yum -y install git gcc glibc-static telnet yum -y install curl policycoreutils-python openssh-server systemctl enable sshd systemctl start sshd yum -y install postfix ystemctl enable postf

初衷:今天公司的前端和测试人员吵起来了.原因是测试埋怨前端人员把Bug的状态更改为已解决,结果代码根本没提交,而前端人员埋怨测试测的太频繁了,需要打几个环境的包不方便.又要改东西又要频繁打包费时间.凡正各有各的理由,就是不想办法解决问题. 哎,没办法,为了解决这种问题,我打算看看Gitlab的CI集成,如果能弄上这个那么开发只管提代码就行了,会自动构建环境. 我这也是现学现卖,今天照着官网和查资料,刚把基本的流程跑通,中间还是费了点时间的,这里记录下 gitlab ci/cd快速入门 按照官网上

目录 GitLab CI流水线配置文件.gitlab-ci.yml详解 实验环境 GitLab CI介绍 .gitlab-ci.yml 配置参数 参数详解 script image services before_script after_script stages stage only 和 except only 和 except 高级用法 only:refs/except:refs only:kubernetes/except:kubernetes only:variables/except

SonarQube是管理代码质量一个开放平台,可以快速的定位代码中潜在的或者明显的错误. docker安装 1.拉取 postgres:docker pull postgres:10 2.拉取sonarqube:docker pull sonarqube:7.9.1-community 3.启动postgres:docker run -d -p 5431:5432 -e POSTGRES_PASSWORD=1 --name postgres postgres:10 4.进入postgres创建数

Starting with the 11g Release 1 (11.1), when gathering statistics, you have the option to automatically publish the statistics at the end of the gather operation (default behavior), or to have the new statistics saved as pending. Saving the new stati

持续集成环境是一个非常重要的工具,在分工合作的项目中有着举足轻重的作用.公司最近要用Gitlab,需要配套的持续集成环境.研究了官方的文档,感觉官方的文档不是很明了.各种修改过后终于成功了.为了大家安装时不再重蹈覆辙,特写这篇博客.博客内容大部分都是官方文档的内容,我仅仅是在一些容易失误的地方做了写解释.官方文档可能会不时更新.但这些注意的点应该变化不是很大.官方安装文档网址:https://github.com/gitlabhq/gitlab-ci/wiki  进入后点击相应的版本. Requ

一.环境准备 首先需要有一台 GitLab 服务器,然后需要有个项目:这里示例项目以 Spring Boot 项目为例,然后最好有一台专门用来 Build 的机器,实际生产中如果 Build 任务不频繁可适当用一些业务机器进行 Build:本文示例所有组件将采用 Docker 启动, GitLab HA 等不在本文阐述范围内 Docker Version : 1.13.1 GitLab Version : 10.1.4-ce.0 GitLab Runner Version : 10.1.0 Gi

最近在加强持续集成,遇到一个场景需要通过 gitlab-ci 环境变量(Settings -> Settings -> CI/CD -> Variables )在持续集成时向 ASP.NET Core 应用传递配置. 在 appsettings.json 中的配置是这样的 { "ossClient": { "accessKeyId": "", "accessKeySecret": "" }

时至今日,越来越多的工程团队开始实行敏捷开发,借以推动更短.更快的发布周期.而代码库的增长与更高的生产构建频率,也带动持续集成与持续部署/交付工具快速兴起.如果您有意提升发布频率,或者是不太清楚哪些工具能够帮助您达成这一目标——别担心.在今天的文章中,我们将探讨一系列最流行的CI / CD工具,并对其特性作出剖析. 什么是CI / CD?其意义何在? 在深入研究CI / CD自动化工具之前,我们首先需要了解其基本概念.正如我们所提到的,持续集成和持续部署通常与敏捷开发环境齐头并进.在这类环境中,