1. gitlab前面已经写过了,自己去参考 https://www.cnblogs.com/yitianyouyitian/p/9214940.html 2. jenkins安装 2.1 jdk 安装 下载linux jdk-8u11-linux-x64.tar.gz 到甲骨文官网或国内镜像下载JDK(www.oracle.com) 解压: tar vxf jdk-8u11-linux-x64.tar.gz 配置环境变量: #set Maven environment vi /etc/prof

1.双击 “Git-2.9.2-64-bit.exe”文件,一路next安装git程序 2.为github帐号添加SSH keys 3.使用git clone命令从GitLab上同步代码库时,如果使用SSH链接(如:git@gitlab.com:example/example.git),但是你的SSH key没有添加到GitLab的账号设置中,系统会报下面的错误:Permission denied (publickey). fatal: Could notreadfrom remote repo

搭建jenkins+gitlab拉取代码失败,日志如下: ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from git@gitlab.bbtree.com:magw/crm_api_auto.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:862) at hudson.plugins.git.Git

1.安装gitlab 详情看:https://www.cnblogs.com/sanduzxcvbnm/p/13023373.html 安装好gitlab后,然后创建一个普通用户,编辑用户,给用户设置密码,添加本机ssh密钥到gitlab里,使用普通用户上传代码 要使用git开头的地址,不使用http开头的地址 可以先把原有的远程仓库名称修改成old_origin,然后添加这个新的远程仓库 2.安装jenkins 详情看:https://www.cnblogs.com/sanduzxcvbnm/

上一节完成了"当git客户端push代码到gitlab后,jenkins会立即去gitlab拉取代码并构建". 目的:本节完成jenkins自动构建之后,自动的将jar包部署到应用服务器并启动服务. 机器: jenkins服务器:10.211.55.4 应用服务器:10.211.55.3 一.jenkins安装publish-over-ssh 安装插件过程同前. 二.建立ssh信任(这也就是ssh的原理) 1.jenkins生成密钥对 在jenkins服务器执行 ssh-keygen

1.网络架构图如下 2.采用这种方案的原因 1.现网机器都在各个省机房内网,或者堡垒机内部.无法直接从公司总部ssh到各个现网机器 2.现网机器可以访问到公网.因此可以从公网下载制作的tar包 3.每次升级现网项目实际通过vpn远程或者堡垒机方式登录.然后手工把tar包传输到对应机器上,操作繁琐,浪费大量时间 3.方案特点描述 1.采用gitlab作为公司私有代码托管仓库,和开发约定好采用tag标签作为发布版本 2.jenkins机器有2台,一个master,一台slave.这里在jenkins

1. CI/CD 1.1 CI - 持续集成 持续集成( Continuous integration , 简称 CI )指的是,频繁地(一天多次)将代码集成到主干.持续集成的目的就是让产品可以快速迭代,同时还能保持高质量.它的核心措施是代码集成到主干之前,必须通过自动化测试.只要有一个测试用例失败,就不能集成.通过持续集成团队可以快速的从一个功能到另一个功能,简而言之,敏捷软件开发很大一部分都要归功于持续集成. 持续集成的组成要素 一个自动构建过程, 从检出代码. 编译构建. 运行测试. 结果

一.作用 使用webhooks来实现当git客户端push代码到gitlab后,jenkins会立即去gitlab拉取代码并构建. 二.步骤 1.安装插件 ruby_runtime(Hook插件依赖于该插件) Gitlab Hook Plugin 2.Jenkins全局配置 "系统管理"->"系统设置" 说明:打两个勾,制定构建的分支 3.Jenkins项目配置 项目->"配置" 说明:勾选"poll SCM",但

前言 记录 Jenkins + gitlab + maven 自动打包部署后端项目详细过程! 需求背景 不会偷懒的程序员不是好码农,传统的项目部署,有时候采用本地手动打包,再通过ssh传到服务器部署运行,这种方式对于单应用部署还算可以,不会耗费太大时间,但假如分布式项目,拆分为多个微服务部署,那么每个服务都打包部署一遍,发布上线可能会耗时非常久,Jenkins + gitlab + maven 可以实现自动打包,部署到远程服务器- 什么是gitlab? 程序员肯定都懂的,跟gayhub一样的东西

jenkins的部署 一.部署git 1)先检查系统是否已经自带了git,如果有,就卸载 $ rpm -qa | grep git && rpm -e git --nodeps 2)开始安装git所需要的依赖包 $ yum -y install curl-devel gettext-devel expat-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker 3)下载git源码包并安装 $ wget https://mirro

用时候在用Git pull命令的时候不管用,拉取不下来远程分支上的代码,是因为本地分支和远程分支没有建立关联. 处理这种问题很简单就按照提示执行命令即可:git branch --set-upstream-to=origin/fixbug-2.9.8 fixbug-2.9.8 如果想保证这种情况不出现就在建立新分支推送到远程分支上的时候加上-u参数即可 git push -u origin feature- 解决git pull 命令失效,不能从远程服务器上拉取代码问题

tips:jenkins通过配置,将之前编译.打包.上传.部署到Tomcat中的过程交由jenkins,jenkins通过指定的代码地址url,将代码拉取到其jenkins的安装位置,进行编译.打包和发布到容器中 jenkins环境 :代码clone(Git).代码编译(Maven).代码运行(Tomcat)的基本环境.公司专门服务配置的环境(redis,mysql数据库,zk,缓存,以及各种服务的配置) 目前我们公司就是这样整体的一个流程,我必须在这里记录下 步骤: 1.git拉取代码,跑公司

从gitlab地址进入进行操作 1.登录GitLab(账号密码由company统一提供,如果是自己操作的话,就需要先注册) 2.登录gitlab后对已创建好的项目进行分支创建(此处默认项目已创建好,如果为创建项目可点击右上角create project) 创建项目: 点击进入: 在master分支创建自己提交代码的分支,我命名为ddtm 3.创建后进入sourcetree(默认已安装,未安装的需要安装好) 1)操作检出代码 2)需要查看他人代码时需要合并master至想要的分支(ddtm) 3)

构建触发器,实现当gitlab有push动作时候,jenkins自动拉代码. 拉取gitlab代码库: jenkins安装git插件 配置gitlab服务器和jenkins服务器身份互信 jenkins服务器生成一对rsa key. 复制公钥到gitlab web dashboard添加 在jenkins Credentials里添加private key. 接下去创建project 拉取到了本地: /var/lib/jenkins/workspace 安装两个插件 Gitlab Hook Pl

工作需要在windows7下使用git分布式版本控制系统,需要同时可以在git命令行模式或TortoiseGit拉取代码而不需要每次输入密码. 这时候需要同时安装git和TortoiseGit. git使用命令ssh-keygen -C “邮箱地址” -t rsa产生的密钥在TortoiseGit中不能用.TortoiseGit 使用扩展名为ppk的密钥,而不是ssh-keygen生成的rsa密钥. 使用git通常都是在服务端添加上你本地生成的无设置密码的密钥即可,密钥一般在安装git后生成在C

参照: jenkins 从git拉取代码-简明扼要 https://www.cnblogs.com/jwentest/p/7065783.html 持续集成①安装部署jenkins从git获取代码-超详细,但是我现在没有耐心看完呀 https://www.cnblogs.com/reblue520/p/7130914.html 快速验证想法: 1. 去到源码管理栏,选中Git: 2. 使用http协议去获取代码 Repository URL填写http的git地址,此时未选择相应的Credent

现有混合云平台的场景下,即有线下和线上的环境,又有测试与正式的场景,而且结合了Docker,导致打包内容有所区分,且服务的发布流程复杂起来,手工打包需要在编译阶段就要根据环境到处更改配置,因此纯手工发布增加了实施的难度,需要一个统一的适应各种环境部署的方案. 基于微服务的发布流程 手动/自动构建 -> Jenkins 调度 K8S API ->动态生成 Jenkins Slave pod -> Slave pod 拉取 Git 代码/编译/打包镜像 ->推送到镜像仓库 Harbor

项目进行微服化改造后系统发布就变得愈为重要,因为持续集成导致部署变得越来越频繁,人工部署带来的一些问题日渐凸显,大家可能都有被系统部署线问题困扰过的经历. 本篇我们将会使用Jenkins+Gitlab来实现程序的持续集成和自动化发布. 1.新建项目提交到GitLab 首先需要有一个GitLab仓库,这个注册一下就可以,具体流程就不写了. 通过GitLab新建一个项目(Project):(没有的话可以使用我这个来测试:https://git.lug.ustc.edu.cn/Deepmountain

前期安装文档:https://www.cnblogs.com/lq-93/p/11828626.html Harbor的作用:     开发提交代码至gitlab容器中,Jenkins拉取代码构建镜像上传到Harbor中,然后docker主机从Harbor中拉取镜像,并根据指令运行容器. 一.安装: 1.下载安装包:wget https://github.com/vmware/harbor/releases/download/v1.1.2/harbor-online-installer-v1.1

本文很长很长,但是句句干货,点赞关注收藏后有惊喜在文末等你 现有混合云平台的场景下,即有线下和线上的环境,又有测试与正式的场景,而且结合了Docker,导致打包内容有所区分,且服务的发布流程复杂起来,手工打包需要在编译阶段就要根据环境到处更改配置,因此纯手工发布增加了实施的难度,需要一个统一的适应各种环境部署的方案. 基于微服务的发布流程 手动/自动构建 -> Jenkins 调度 K8S API ->动态生成 Jenkins Slave pod -> Slave pod 拉取 Git