Gitlab-CI
Gitlab簡介
最近感覺就是在不斷的搭建/遷移版本伺服器,而現在市面上關于版本伺服器搭建的指南都流于表面,真正深入骨骼的少之又少,往往以偏概全很多關鍵點并未提及。而版本伺服器的搭建往往是一個初創型或中小型公司迫切需要解決的問題。
目前市使用者量和口碑較好的Git服務提供商,屈指可數。國外的話,
GitHub
都是不錯的選擇,但國際形勢變幻莫測,需要随時備好梯子。國内的話
BitBucket
使用者體驗就做的很不錯,很切合碼農們的審美, 開源中國的
Coding
也有對應的代碼托管服務,不過自從他們家Maven倉庫鏡像下架事件後已不推薦再用,不久後被阿裡收購不是沒有可能。
碼雲
各個版本管理軟體各有優劣,大多數的企業和團隊為了隐私性的需要,選擇了目前市面上功能和體驗都十分給力的
Gitlab
作為非開源的代碼管理平台。
Gitlab目前有兩種不同的版本,社群/個人版和企業版
GitLab社群版是完全免費的,不但能建立免費的私有倉庫而且沒有數量上限,參與人員也沒有數量限制,還能設定成員的權限,甚至細緻到具體某條分支的權限,以及強大的工作流等等。完全滿足我們日常開發、投産所需要的版本控制功能。
Gitlab企業版支援LDAP架構和對應功能,以達到更高的處理性能和存儲效率,并提供其他更多子產品和服務支援
參考連結:Gitlab社群版/企業版對比
安裝前的準備
目前來說,Gitlab的發行版本并不是支援所有Linux/Unix核心版本,以下幾種可能還是需要廣大同學們通過其開源源碼進行編譯安裝 。
- Arch Linux
- Fedora
- FreeBSD
- Gentoo
- macOS
Gitlab安裝
####安裝完成,通路測試#下載下傳并安裝gitlab的yum源 curl -sS http://packages.gitlab.cc/install/gitlab-ce/script.rpm.sh | sudo bash #自動安裝最新版本 yum install gitlab-ce #生成配置并啟動 gitlab-ctl reconfigure #配置域名 vim /etc/gitlab/gitlab.rb external_url 'http://gitlab.huoban.com'
###使用SMTP來發送郵件通知
如果你不想用Gitlab伺服器自帶的postfix服務來發郵件,可以改用SMTP服務。同樣是修改/etc/gitlab/gitlab.rb中的郵件服務配置,使用SMTP伺服器來作為郵件通知的發送方
gitlab_rails['smtp_address'] = "smtp.yourdomain.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = "xxx"
gitlab_rails['smtp_password'] = "xxx"
gitlab_rails['smtp_domain'] = "smtp.yourdomain.com"
gitlab_rails['smtp_authentication'] = 'plain'
gitlab_rails['smtp_enable_starttls_auto'] = true
###配置https
1、建立SSL證書存放目錄
mkdir -p /etc/gitlab/ssl
chmod 0700 /etc/gitlab/ssl
通過Sftp等方式上傳證書gitlab.xxx.com.crt,修改對應證書通路權限
chmod 600 /etc/gitlab/ssl/gitlab.xxx.com.crt
2、修改主配置,支援SSL通路
仍然是修改/etc/gitlab/gitlab.rb主配置檔案
external_url "[https://gitlab.bjwf125.com](https://gitlab.bjwf125.com)"
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.xxx.com.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.xxx.com.key"
##什麼是持續內建(Continuous Integration)
持續內建是一種軟體開發實踐,即團隊開發成員經常內建他們的工作,通常每個成員每天至少內建一次,也就意味着每天可能會發生多次內建。每次內建都通過自動化的建構(包括編譯,釋出,自動化測試)來驗證,進而盡快地發現內建錯誤。許多團隊發現這個過程可以大大減少內建的問題,讓團隊能夠更快的開發内聚的軟體。
軟體內建是軟體開發過程中的一個環節,這個環節的工作一般會包括以下流程:合并代碼---->安裝依賴---->編譯---->測試---->釋出。軟體內建的工作一般會比較細碎繁瑣,為了不影響開發效率,以前軟體內建這個環節一般不會經常進行或者隻會等到項目後期再進行。但是有些問題,如果等到後期才發現,解決問題的代價很大,有可能導緻項目延期或者失敗。是以,為了盡早發現軟體內建錯誤,鼓勵團隊成員應該經常內建他們的工作,通常每個成員每天應該至少內建一次。這就是所說的持續內建。是以說,持續內建是一種軟體開發實踐。
軟體內建的工作細碎繁瑣,以前是由人工完成的。但是現在鼓勵持續內建,那豈不是要累死人,還影響開發效率。是以,應該考慮将軟體內建這個工作自動化,這就出現了所謂的持續內建系統。
##GitLab-CI
GitLab-CI就是一套配合GitLab使用的持續內建系統(當然,還有其它的持續內建系統,同樣可以配合GitLab使用,比如Jenkins)。而且GitLab8.0以後的版本是預設內建了GitLab-CI并且預設啟用的。Gitlab-CI安裝
#配置yum源 cat > /etc/yum.repos.d/gitlab-ci.repo << EOF [gitlab-ci] name=gitlab-ci baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7/ enabled=1 gpgcheck=0 EOF #安裝最新版本 yum -y install gitlab-ci-multi-runner
# gitlab-ci-multi-runner register
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.huoban.com/
Please enter the gitlab-ci token for this runner:
mWtqXCDiK2RDdRdUp7QC
Please enter the gitlab-ci description for this runner:
[zhangqiang001]: huoban-shell
Please enter the gitlab-ci tags for this runner (comma separated):
shell
Whether to run untagged builds [true/false]:
[false]: false
Whether to lock Runner to current project [true/false]:
[false]: false
Registering runner... succeeded runner=mWtqXCDi
Please enter the executor: docker+machine, kubernetes, docker-ssh, virtualbox, shell, ssh, docker-ssh+machine, docker, parallels:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
* 輸入Gitlab CI位址
* 輸入項目CI token
* 輸入 Runner 描述
* 輸入 Runner 标簽,可以多個,用逗号隔開
* 輸入 Runner 執行的語言 (e.g. shell)
建構.gitlab-ci.yml腳本
# vim .gitlab-ci.yml
deploy_stage:
only:
- master
when: manual
script:
- echo ${CI_PROJECT_DIR}
- rsync -rtlpvz ${CI_PROJECT_DIR}/ $SSH_USER@$SSH_HOST:${PROD_BASE_DIR} && echo $?
- ssh $SSH_USER@$SSH_HOST "sudo chmod -R 777 $PROD_BASE_DIR"
tags:
- shell