這篇文章是站在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)了脖苏。