基于GitLab的开发部署方案

2018-06-29 10:19:07 暂无评论阳光倾城解决方案 961

GitLab开发部署流程
1. 基于环境的分支模型

基于环境的发布模型

适用场景：一个开发环境、一个预生产环境和一个生产环境。

主分支master部署在开发环境上。当有人要部署到预生产时，他们会从主分支创建一个到预生产分支的合并请求。通过将预生产分支合并到生产分支来实现代码的上线。

这个工作流只有提交到下游的流，确保对后者的交付都在所有环境中进行了测试。

如果需要拣选某个提交管理的热修复代码，通常需要在某个特性分支上展开针对热修复的开发，然后通过发起一个合并请求将热修复提交合并到master分支。

如果master分支运行正常，就可以把master分支合并到下游的其他分支上。如果由于特殊情况需要做一些手工的调整才能在不同环境上正常运行（比如配置文件），可以将合并请求从特性分支发送到下游分支。

可以支持持续发布。

开发人员对受保护的分支不具备推送权限，可以发送合并请求。

PMS场景演示

开发、构建、测试、部署演进模型

*虚线表示省略多个同类过程，虚线图标表示省略多个同类。

上图表达生产环境版本为T时的场景：

1.开发团队基于T+1版贡献；

2.生产环境紧急bug修复；

3.开发环境测试通过，增量部署到测试环境。

主要涉及两部分活动：

开发团队协作；
管理员版本控制与环境部署。

管理员版本控制与环境部署包含版本控制、构建、测试与发布。

整体过程概括为：

开发计划->本地开发->合并更改到主分支->部署开发环境并测试->主分支到测试分支->部署测试环境并测试->测试分支到生产分支->部署生产环境->生产bug紧急修复->同步更新开发与测试分支->下一开发计划。

环境初始化

管理员在GitLab上创建项目：

上传项目需要进行版本控制的文件到默认的主分支master，基于master创建测试环境分支preproduce、生产环境分支produce，主分支master对应开发环境，这三个分支都要设置为受保护分支：

开发者操作

pull主分支

使用egit导入项目到eclipse工作空间：

主分支必须拉取下来，后期的开发要基于主分支创建的分支展开。

日常开发

开发者接收到安排的开发任务后，基于主分支创建恰当的分支并切换到新分支展开开发工作：

打开创建分支对话框，pull strategy有三个选项分别对应新分支的拉取策略，

Rebase方式下新分支的pull操作将以变基的形式融合取回的远程主分支最新内容；

Merge方式下新分支的pull操作将以合并的形式融合取回的远程主分支最新内容；

none方式下新分支的pull操作不执行任何更新（可以通过合并master的更新到新分支的方式间接实现同步）：

分支创建完成后，展开开发工作。可以随时提交，提交更改必须写明提交说明，如果是更改完毕想要提交的同时推送分支到远程，可以选择”Commit and Push”，操作一般如下：

gitlab返回消息通知你需要到指定的服务器上创建针对此次提交的合并请求才能真正交付代码：

代码交付

上面提到新分支或其提交推送到远程时需要登录Gitlab统计合并请求，可以通过返回的URL打开请求合并的填写页面：

关于合并请求的详细说明……

也可以拖拽的方式添加附件到下方区域，或者点击右下角”Attach a file”新增必要的附件。

然后指派该请求的处理人（Assignee）。

设置必要的信息。

最后最下面的”submit merge request”提交请求。

提交合并申请

合并申请提交完毕后，打开申请页面，可以在此页面进行相关信息的更改（下图右侧），可以添加此问题的补充注释或者发起一个话题展开讨论（左下角Comment下拉控件打开操作选择）：

发起讨论后会形成一个嵌套的阶梯状讨论区：

所有开发者都可以看到这个请求，并在讨论区发表意见。

协同开发

一个发版周期内，所有开发者会创建大量分支，为了保证远程仓主分支的有效性，开发者的合并请求应该在确定开发工作进行完毕的情况下发出。这样，开发者之间彼此代码的共享应该控制在线下进行，只有在开发者本地测试OK了才推送合并请求到远程主分支，这样保证基于环境的分支始终是可运行的，同时开发之间的交互能正常进行。开发者工作是否顺利的取决于系统模块设计的合理性依据任务分割的合理性，无论是系统设计还是任务分配应避免紧耦合现象，避开不同模块之间的强引用，可以有效提高开发效率、测试效率、发布效率以及运维效率。

一个开发周期完成后，所有分支的代码已经发布生产正常运行了，可以清除不需要的开发分支。

每个开发者都可以通过登录gitlab查看远程仓下的版本树，了解团队工作的进展节点和自己所处的节点：