這篇文章是站在Architect立場粗井，把基本的開發(fā)流程走完。
為什么
為什么要用GitLab刨裆？
當(dāng)前方式：Git + Gerrit + Jekins告唆，編寫代碼和自動化測試是分開的，為什么要分開簇秒？因?yàn)閐eveloper 和 tester 都是有門檻的鱼喉，全棧工程師畢竟是少數(shù)，即使都懂，相關(guān)配置也要知道扛禽，意味著需要處理的信息量變大了锋边。
GitLab默認(rèn)把原始功能代碼和自動化測試的代碼集成在一起，對于開發(fā)人員來說编曼，不需要單獨(dú)學(xué)習(xí)怎么去完成自動化測試豆巨，只需要把自己手工測試的步驟寫進(jìn)一個script就可以了，大幅度降低了學(xué)習(xí)成本掐场。
是什么
GitLab 是一個基于 git 的倉庫管理程序往扔，也是一個方便軟件開發(fā)的強(qiáng)大完整應(yīng)用。
簡單的理解：它是GitHub 的企業(yè)版刻肄。GitLab = Git repo + Git Web UI + Gerrit review + Jenkins + Jira + Confluence瓤球。
它具備競爭優(yōu)勢的功能是 Code review + GitLab CI。
因?yàn)樗菃我卉浖瓿闪嗽S多軟件的工作敏弃，所以集成度更高，一些接口不用考慮（如 Gerrit Trigger）噪馏，同時工作模式也有改變(never push to master branch)麦到，原來的一些概念（change, patch set）也沒有了，有了新概念（Fork/Merge Request）欠肾。GitLab CI 不是Jenkins 也沒有插件瓶颠，build 代碼跟源代碼集成在一起，開發(fā)人員可以直接修改刺桃，不用單獨(dú)學(xué)習(xí)怎么使用Jenkins粹淋，降低了學(xué)習(xí)成本。
GitLab 中的一些概念
Fork: GitLab, GitLab 中引入的概念瑟慈，獲取一個獨(dú)立版本的repo
Group - folder桃移，相當(dāng)于目錄，里邊有一些projects
Project： 跟Gerrit 中的Project 概念一致葛碧，git 里面叫 repo
Issue：Jira 中的ticket
Plan：Jira 中的 dashboard借杰，對應(yīng) GitLab 中的 Issue Board
Milestone：Jira 中的 sprint
GitLab flow
GitLab flow是GitLab官方推薦的分支管理策略，Gitlab flow 的最大原則叫做"上游優(yōu)先"（upsteam first）进泼，即只存在一個主分支master蔗衡，它是所有其他分支的"上游"。只有上游分支采納的代碼變化乳绕，才能應(yīng)用到其他分支绞惦。
分支約定
臨時分支：在開發(fā)完成會被刪除
- 功能分支
feature- 用于新功能的開發(fā)，建議以issue-feature-name命名 - 修復(fù)分支
fix- 用戶bug的修復(fù)洋措，建議以issue-fix-name命名
固定分支
- 開發(fā)分支
master- 用于發(fā)布到測試環(huán)境济蝉，上游分支為feature和fix，該分支為受保護(hù)分支 - 預(yù)發(fā)分支
pre-production- 用于發(fā)布到預(yù)發(fā)環(huán)境，上游分支為master - 正式分支
production- 用于發(fā)布到正式環(huán)境堆生，上游分支為pre-production
Fork repo
fork 是Github专缠，GitLab特有的概念，是把主repo 拉一個到自己的空間里淑仆，開發(fā)人員想怎么改都行涝婉，不會影響原有的repo。實(shí)踐中蔗怠，更多的是用Fork 方式墩弯，這樣會減少branch，降低維護(hù)成本寞射。
測試流程
軟件開發(fā)階段一般如下圖表示渔工，具體的過程在此之上做了簡化。
1 網(wǎng)頁上開 issue桥温，會得到一個編號
真實(shí)環(huán)境使用Jira引矩，它更好用，通過配置侵浸，可以跟GitLab集成旺韭。
在這里為了簡化，使用自帶的Issue掏觉。
以root 身份創(chuàng)建issue区端。
2 Fork repo
以被分配issue 的賬戶登陸。
頁面右上角澳腹，發(fā)現(xiàn)了新 issue 的提醒织盼，點(diǎn)擊進(jìn)去，查看具體信息酱塔。
切換到repo頁面沥邻，fork 它到自己的 namespace。（實(shí)踐中用 fork 而不是 branch延旧，避免分支太多難以維護(hù)谋国。）
3 clone repo
$ git clone git@roy-gitlabce.eastasia.cloudapp.azure.com:royzeng/demo.git
作為測試，隨意修改一些文件
$ echo "process test" >> fork.txt
$ git add .
$ git commit -m "fix #5"
commit message 中的 fix是關(guān)鍵字迁沫，#5 是 issue 的編號芦瘾，它們組合起來就能與 issue 關(guān)聯(lián)起來。
4 提交并push到GitLab倉庫
$ git push origin master
5 運(yùn)行GitLab CI
如果之前寫好了.gitlab-ci.yml 文件集畅，autobuild 就開始了近弟。
6 在GitLab上創(chuàng)建一個Merge Request
Pipeline build 成功后，就可以找人來review 代碼了挺智，在 GitLab祷愉，這叫做 Merge Request。
下個頁面提供一些具體信息，讓誰來review 代碼二鳄。
7 項(xiàng)目管理者進(jìn)行代碼審查
切換用戶赴涵，作為代碼審查的人，會在自己頁面右上角看到 merge request 的圖標(biāo)订讼，點(diǎn)擊它髓窜。
Merge Request 頁面包含了許多信息，具體如下
接下來看具體的代碼欺殿，這一部分跟Gerrit review 相似寄纵。
8 合并到master
Merge 之后，回頭去看那個issue 已經(jīng)是 closed 狀態(tài)了脖苏。
9 在master branch 運(yùn)行第二次GitLab CI
