git

Git是一個開源的分布式版本控制系統(tǒng)，可以有效、高速的處理從很小到非常大的項目版本管理。Git 是 Linus Torvalds 為了幫助管理 Linux 內(nèi)核開發(fā)而開發(fā)的一個開放源碼的版本控制軟件

Gitlab 可以做什么

• Gitlab 是 Git 服務(wù)端的集成管理平臺，提供了：

1. 代碼托管服務(wù)
2. 訪問權(quán)限控制
3. 問題跟蹤，bug的記錄、跟蹤和討論
4. Wiki，項目中一些相關(guān)的說明和文檔
5. 代碼審查，可以查看、評論代碼
   1. 持續(xù)集成

issue

issue是項目管理中的重點，主要包括以下功能：

1. 用于登記bug與需求
2. 可以按照issue類型不同打上不同的tag
3. 每個issue在每個project中有唯一的id
4. 項目負責(zé)人可以@相應(yīng)的開發(fā)進行開發(fā)
5. 在經(jīng)過單元測試和code review后，如果功能點符合，可以關(guān)閉相應(yīng)的issue
6. 可以通過gitlab的web界面進行相應(yīng)的分析，比如按照tag和assignee進行篩選

commit

commit message可以用于追蹤問題，所以
對于Git的commit的message，盡量詳細的說明本次提交主要干了什么，是fix 什么bug，開發(fā)什么特性，還是update 某個功能點，這同樣有助于進行code review

Git 使用原則

• 不建議留任何未提交文件就去拉取，fetch也好，不要貪拉
• 拉取不成功，解決沖突，提交不成功，解決沖突，解決不了沖突，請聯(lián)系隊友
• commit 寫好注釋

Git tips

#查看提交暫存區(qū)和版本庫中文件的差異
git diff--cached

 gitlog --stat             #查看簡單的diff結(jié)果，可以加上--stat參數(shù)

git tag -a v1.4 -m 'my version 1.4'
git log --oneline
#放棄工作區(qū)的修改
  git checkout <file-name>
#存儲當前的修改，但不用提交commit
  git stash
  
 # 切換到Master分支
　　git checkout master
　　# 對Develop分支進行合并
　　git merge --no-ff develop
　　
#刪除feature分支：
　　git branch -d feature-x
#刪除遠程分支：
　　git push origin --delete <branchName>

一個代碼片段收集功能可以輕松實現(xiàn)代碼復(fù)用，便于日后有需要的時候進行查找。

[git 版本管理]http://www.ruanyifeng.com/blog/2012/07/git.html

共同的事

分支管理策略

一、主分支 Master

首先，代碼庫應(yīng)該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發(fā)布。

master分支上存放的應(yīng)該是隨時可供在生產(chǎn)環(huán)境中部署的代碼，它承擔(dān)的責(zé)任就是：僅在發(fā)布新的可供部署的代碼時才更新到master分支上的代碼。當開發(fā)活動告一段落，產(chǎn)生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應(yīng)的版本號標簽（TAG）。

二、開發(fā)分支 Develop

主分支只用來分布重大版本，日常開發(fā)應(yīng)該在另一條分支上完成。我們把開發(fā)用的分支，叫做Develop。

develop分支是保存當前最新開發(fā)成果的分支，它承擔(dān)的責(zé)任就是功能開發(fā)完畢等待最后QA的驗收，通常這個分支上的代碼也是可進行每日夜間發(fā)布的代碼。當代碼已經(jīng)足夠穩(wěn)定時，就可以將所有的開發(fā)成果合并回master分支了。

三、臨時性分支

除了常設(shè)分支以外，還有一些臨時性分支，用于應(yīng)對一些特定目的的版本開發(fā)。：

輔助分支是用于組織解決特定問題的各種軟件開發(fā)活動的分支，它的生存周期伴隨著它的功能完成而消失。輔助分支包括

• 功能（feature）分支

• 預(yù)發(fā)布（release）分支

• 修補bug（fixbug）分支

這三種分支都屬于臨時性需要，使用完以后，應(yīng)該刪除，使得代碼庫的常設(shè)分支始終只有Master和Develop。

四、功能分支

第一種是功能分支，它是為了開發(fā)某種特定功能，從Develop分支上面分出來的。開發(fā)完成后，要再并入Develop。

img

功能分支的名字，可以采用feature-*的形式命名。

創(chuàng)建一個功能分支：

# 這里x可以定義為自己名字的縮寫，比如hxg
git checkout -b feature-x develop

開發(fā)完成后，將功能分支合并到develop分支：

git checkout develop

git merge --no-ff feature-x

刪除feature分支：

git branch -d feature-x      

五、預(yù)發(fā)布分支

第二種是預(yù)發(fā)布分支，它是指發(fā)布正式版本之前（即合并到Master分支之前），我們可能需要有一個預(yù)發(fā)布的版本進行測試。

預(yù)發(fā)布分支是從Develop分支上面分出來的，預(yù)發(fā)布結(jié)束以后，必須合并進Develop和Master分支。它的命名，可以采用release-*的形式。

創(chuàng)建一個預(yù)發(fā)布分支：

#這里版本號可以定義為3位，
git checkout -b release-1.2 develop

確認沒有問題后，合并到master分支：

　　git checkout master

　　git merge --no-ff release-1.2

　　# 對合并生成的新節(jié)點，做一個標簽

　　git tag -a 1.2

再合并到develop分支：

git checkout develop

git merge --no-ff release-1.2
　

最后，刪除預(yù)發(fā)布分支：

git branch -d release-1.2

六、修補 bug 分支

最后一種是修補bug分支。軟件正式發(fā)布以后，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支，進行bug修補。

修補bug分支是從Master分支上面分出來的。修補結(jié)束以后，再合并進Master和Develop分支。它的命名，可以采用fixbug-*的形式。

img

創(chuàng)建一個修補bug分支：

　git checkout -b fixbug-0.1 master

修補結(jié)束后，合并到master分支：

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
　

再合并到develop分支：

　git checkout develop

　git merge --no-ff fixbug-0.1

最后，刪除"修補bug分支"：

git branch -d fixbug-0.1

工具：

TortoiseGit,SourceTree

持續(xù)集成

持續(xù)集成是一種軟件開發(fā)實踐，即團隊開發(fā)成員經(jīng)常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試)來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。許多團隊發(fā)現(xiàn)這個過程可以大大減少集成的問題，讓團隊能夠更快的開發(fā)內(nèi)聚的軟件。

1. 快速發(fā)現(xiàn)錯誤。每完成一點更新，就集成到主干，可以快速發(fā)現(xiàn)錯誤，定位錯誤也比較容易。
2. 防止分支大幅偏離主干。如果不是經(jīng)常集成，主干又在不斷更新，會導(dǎo)致以后集成的難度變大，甚至難以集成。

[Gitlab-CI]是GitLab Continuous Integration（Gitlab持續(xù)集成）的簡稱。
從Gitlab的8.0版本開始，gitlab就全面集成了Gitlab-CI,并且對所有項目默認開啟。
只要在項目倉庫的根目錄添加.gitlab-ci.yml文件，并且配置了Runner（運行器），那么每一次合并請求（MR）或者push都會觸發(fā)CI [pipeline]

Gitlab-runner

Gitlab-runner是.gitlab-ci.yml腳本的運行器，Gitlab-runner是基于Gitlab-CI的API進行構(gòu)建的相互隔離的機器（或虛擬機）。GitLab Runner 不需要和Gitlab安裝在同一臺機器上，但是考慮到GitLab Runner的資源消耗問題和安全問題，也不建議這兩者安裝在同一臺機器上。

Gitlab Runner分為兩種，Shared runners和Specific runners。
Specific runners只能被指定的項目使用，Shared runners則可以運行所有開啟Allow shared runners選項的項目。


GitLab-Runner就是一個用來執(zhí)行軟件集成腳本的東西。你可以想象一下：Runner就像一個個的工人，而GitLab-CI就是這些工人的一個管理中心，所有工人都要在GitLab-CI里面登記注冊，并且表明自己是為哪個工程服務(wù)的。當相應(yīng)的工程發(fā)生變化時，GitLab-CI就會通知相應(yīng)的工人執(zhí)行軟件集成腳本。如下圖所示：

img

stages:

  - build

Job:

  stage: build
  only:
    - develop
    - master
  script:
    - echo "aa"

.gitlab-ci.yml 是配置CI用你的項目中做哪些操作， 這個文件位于倉庫的根目錄。

https://gitlab.com/gitlab-org/gitlab-ci-yml

Pipelines

Pipelines 是定義于.gitlab-ci.yml中的不同階段的不同任務(wù)，里面可以包含多個流程，如安裝依賴、運行測試、編譯、部署測試服務(wù)器、部署生產(chǎn)服務(wù)器等流程。

任何提交或者 Merge Request 的合并都可以觸發(fā) Pipeline，如下圖所示：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

我把[Pipelines]理解為流水線，流水線包含有多個階段（stages），

Stages

Stages表示構(gòu)建階段，說白了就是上面提到的流程。我們可以在一次 Pipeline 中定義多個 Stages，這些 Stages 會有以下特點：

• 所有 Stages 會按照順序運行，即當一個 Stage 完成后，下一個 Stage 才會開始

• 只有當所有 Stages 完成后，該構(gòu)建任務(wù) (Pipeline) 才會成功
• 如果任何一個 Stage 失敗，那么后面的 Stages 不會執(zhí)行，該構(gòu)建任務(wù) (Pipeline) 失敗

因此，Stages 和 Pipeline 的關(guān)系就是：

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

每個階段包含有一個或多個工序（jobs），比如先購料、組裝、測試、包裝再上線銷售，每一次push或者MR都要經(jīng)過流水線之后才可以合格出廠。而.gitlab-ci.yml正是定義了這條流水線有哪些階段，每個階段要做什么事。

Jobs表示構(gòu)建工作，表示某個 Stage 里面執(zhí)行的工作。我們可以在 Stages 里面定義多個 Jobs，這些 Jobs 會有以下特點：

• 相同 Stage 中的 Jobs 會并行執(zhí)行
• 相同 Stage 中的 Jobs 都執(zhí)行成功時，該 Stage 才會成功
• 如果任何一個 Job 失敗，那么該 Stage 失敗，即該構(gòu)建任務(wù) (Pipeline) 失敗

所以，Jobs 和 Stage 的關(guān)系圖就是：

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+

untitled1.png

端到端部署

https://v.qq.com/x/page/z03959pwc0r.html

http://115.28.84.155/org/index.do
http://123.56.64.36:9000/projects
http://115.28.86.238/

隨著新業(yè)務(wù)的增加和老業(yè)務(wù)的不斷優(yōu)化，項目中的代碼也在一直增加，當代碼量達到幾十萬行的時候，人工審查肯定會費時費力，所以有了 SonarQube代碼質(zhì)量管理平臺，通過配置審查規(guī)則，讓程序幫你檢測代碼中潛在的bug，讓耗時操作通過機器完成，節(jié)約人力成本

sonarQube能帶來什么？
1.Bugs和漏洞
檢測代碼中的bug和漏洞

2.壞味道
檢測代碼中潛在的錯誤

3.重復(fù)
顯然程序中包含大量復(fù)制粘貼的代碼是質(zhì)量低下的 sonar可以展示源碼中重復(fù)嚴重的地方

4.結(jié)構(gòu)
檢測代碼行數(shù)，代碼的組成成分，和占用的百分比

5.注釋量
檢測代碼注釋的量

6.依賴關(guān)系
項目結(jié)構(gòu)

圖 1. 質(zhì)量緯度

圖 2. SonarQube 的服務(wù)架構(gòu)