第一版本的SDK，简单起见我们采用Forking Workflow，SDK只有一个repo以及一个branch：master。后续版本再考虑将Gitflow Worflow加入到版本管理里面来。实际应用过程中不推荐采用Forking Workflow，特别是多人团队，频繁提交的情况下，再者Forking Workflow不够自动化，Developer需要掌握一定的知识之后才能熟练应用。至于版本管理
一、准备首先 需要两台服务器（这里为了下面方便理解，我们约定这两台服务器地址、名称和系统） 1、gitlab 服务器 服务器A(地址10.10.10.7)（内存大于4g不然会一直死）（ CentOS Linux 7 (Core)） 2、springboot服务部署服务器 服务器B（地址10.10.10.8）（ CentOS Linux 7 (Core)）二、配置gitlab服务器这个比较简单，或者
相信大多数人写代码都了解过github这个代码托管的地方，然而访问会是如此让人蛋疼，那个小圆圈转了一遍又一遍，令人难以接受。相信也有很多人，用hexo或者其他的方式搭建过个人的博客，使用github-page，别人访问你的博客也是慢的流口水，并且仅仅支持本地编译以及部署。 一、前期准备工作首先，注册一个七牛云账号（用过七牛云的同学可以忽略）；一个静态博客（当然你也可以用类似的方式搭建动态的博客，因
在传统服务器上我们对项目的部署步骤比较繁琐，需要经历编译、打包、上传、启动，这里使用Gitee提供的流水线部署进行简化此过程。一、创建流水线很好理解，流水线式的工作，这个步骤结束了进行下一个步骤。在我们的gitee仓库中，点击流水线，如下： 点击之后如下图： 这里主要说明一下这两个地方：触发事件：Push事件，当我们填写了某个分支之后，在提交代码push到填写的这个分支的时候就会自动触发流水线，这
使用极狐GitLab Webhook 触发 Pipeline，打通工作消息通知关于 A 和 B 同学的烦恼，可以使用 Webhook 触发 Pipeline，打通工作消息通知 的功能来解决。众所周知，极狐(GitLab) 采用远程办公工作模式，必然有许多需要协同处理的工作，这些工作当然是采用极狐GitLab 自带的 issue 提交到协同方。关于需要 SRE
1.前言Hello，各位小伙伴大家好。?在上一篇文章【Docker+Jenkins+Gitee自动化部署maven项目】中，咱们详细介绍了如何自动化部署maven项目，如果说你的项目仅仅为maven项目，那么这种部署方式是很契合的，如果我们想要支持更多类型的项目，这种方式就显得有点捉襟见肘了。于是乎，Pipeline流水线任务闪亮登场。如下图所示：Pipeline流水线任务可以让我们定制整个任务的
Docker+Jenkins+Gitee+springBoot实现自动化流水线实战(二)前言本文接着上一篇 Docker+Jenkins+Gitee+springBoot实现自动化流水线实战(一)继续交流.本次新增分布式部署+多模块部署+maven私服等提示：以下是本篇文章正文内容，下面案例可供参考1. 安装maven私服:nexus私服搭建 参考:2.Jenkins所使用的maven配置建议自己
使用 Git 版本控制，是对使用它之前的所有版本控制方式的一种改进。然而，很多组织最终以太过混乱或过于复杂的流程来结束。这个问题对于刚从其他版本控制系统转过来的组织来说特别突出。在本文中我们会列出 GitLab 工作流 的11条规则，以帮助简化、整理工作流程。这些规则最主要的益处是(或我们希望是) 它能够简化流程并且产生一个更高效和更清楚的成果。我们认为总会有可改善的空间，并且每一次改
使用 Git 版本控制，是对使用它之前的所有版本控制方式的一种改进。然而，很多组织最终以太过混乱或过于复杂的流程来结束。这个问题对于刚从其他版本控制系统转过来的组织来说特别突出。在本文中我们会列出 GitLab 工作流 的11条规则，以帮助简化、整理工作流程。这些规则最主要的益处是(或我们希望是) 它能够简化流程并且产生一个更高效和更清楚的成果。我们认为总会有可改善的空间，并且每一次改善都是草案。
# 利用GitLab流水线部署Java应用程序
在软件开发过程中，部署是一个不可或缺的环节。而利用GitLab的流水线功能可以帮助我们实现自动化部署，提高部署效率和减少人为错误。本文将介绍如何使用GitLab流水线部署Java应用程序，以及如何编写相关的流水线配置文件。
## 什么是GitLab流水线
GitLab流水线是一个持续集成和持续交付（CI/CD）工具，它可以帮助我们自动化构建、测
Gitflow工作流简介Gitflow工作流通过为功能开发、发布准备和项目维护分配独立的分支，让发布迭代过程更流畅。Gitflow工作流定义了一个围绕项目发布的严格分支模型，它会相对复杂一点，但提供了用于一个健壮的用于管理大型项目的框架，非常适合用来管理大型项目的发布和维护。 贯穿整个开发周期，master和develop分支是一直存在的，master分支可以被视为稳定的分支， 而develop分
参考文档：https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#%E4%B8%80%E8%AF%91%E5%BA%8F最近公司代码从svn 迁移到gitlab；虽然成功搭建了gitlab 服务，但是成功的应用到开发上还是出现了很多问题，找了几篇git 文章，优化提出了新的工作流方式，特此笔记，下文中大部分文字与图
目录GitLab CI流水线配置文件.gitlab-ci.yml详解实验环境GitLab CI介绍.gitlab-ci.yml参数详解scriptimageservicesbefore_scriptafter_scriptstagesstageonly 和 exceptonly 和 exceptonly:refs/except:refsonly:kubern
服务器规划 192.168.190.100 Master etcd 192.168.190.101 Node1 192.168.190.102 Node2 192.168.190.103 Gitlab runnner 192.168.190.104 Harbor一、搭建k8s集群K8s集群创建secret （用于连接harbor镜像仓库）二、搭建gitlab1.搭建gitlabyum lo
Gitlab自动触发流水线我们希望版本管理工具和持续集成工具联动起来，如提交代码时，自动触发集成工具的进行代码监测，检测成功后集成工具再通知版本管理工具进行下一步操作。Jenkins会为当前代码库生成一个订阅地址，绑定到Gitlab。而Jenkins想调用Gitlab想调用Gitlab的API则需要其凭证信息。所以我们配置自动触发流水线最关键两步是把凭证添加到Jenkins上，再将订阅地址绑定到G
Gitlab CI/CD 流水线配置参考.gitlab-ci.yml文件定义了流水线的结构和顺序，并确定：使用GitLab Runner执行什么。遇到特定条件时要做出哪些决定。例如，当进程成功或失败时。不可用的jobs名称每个作业必须具有唯一的名称，但有一些保留的关键字不能用作作业名称：imageservicesstagestypesbefore_scriptafter_scriptvariabl
创建流水线-3.完善工作1.选择Jenkins Agent 选择Jenkins Agent，基于maven:3.3.9-jdk-8-alpine镜像配置Pod模板。2.配置GitLab的Webhook 在GitLab中配置webhook，将提供的代码推送到GitLab触发构建，完成后访问部署的应用。配置Webhook首先要配置出口请求，在配置webhook，如下所示。 注：如上创建的流水线并不能使
1. 常用命令（1）git clone xx.git 首先从git项目xx.gitclone项目到本地（2）clone之后，使用命令行项目进入项目所在文件夹，此时一般在master分支下，为了不影响主分支代码，进行新建分支：git checkout -b yourBranchName（3）在新建分支下修改代码，修改完之后依次执行git add . ； git commit -m "your not
实践gitflow结合git flow，使用gitlab作为远端仓库管理，在实际的项目中是一种可行的方式，而且这种方式对与复杂大型的项目有较好的适应方式。git flowgit flow源于Vincent Driessen在2010年提出的一个分支模型： 主要特点两个长期分支git flow中有两个长期的分支，一直不会被删除，这两个分支是develop和master。分支生命期作用说明master
开篇Git 三大特色，分支，暂存区，工作流，今天终于要写到 WorkFlow 了，我彷佛已经看到胜利的曙光，走起。何谓工作流WorkFlow 的字面意思，工作流，即工作流程。在分支篇里，有说过这样的话：因为有分支的存在，才构成了多工作流的特色。事实的确如此，因为项目开发中，多人协作，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起，而且真实项目中涉及到很多问题，例如版本迭代，版
