前提

目前公司在很多項目在上線時，都明確要求了，週四、週五上線production環境需要發郵件申請，週六、週日不允許上線，週一至週三每天下午5點到晚上9點不允許上線。

之所以這麼要求，是因為減少在人員不齊情況下上線帶來的風險。

而這種規範，只能由公司各個項目組之間的自覺，但是這種自覺其實是一種不可靠因素。我個人感覺還是需要一套約束，來降低這種不可靠因素。

目標

前提確定好後，那就需要一個目標了。也就說，在某些分支上的某些時間點是不允許讓CI進行自動構建的。

一開始，我的想法是通過git hook來實現，但是後來給否決了，原因為：

  • pre-commit 只是針對當前commit的時間點，並不是push的時間點
  • pre-push 雖說可以做到，但是問題在於，可以通過--no-verify來跳過鉤子，而且這種跳過是下發到組內每個成員的。
  • 對merge無能為力，網上的方案都是通過prepare-commit-msg來判斷當前commit是否存在Merge字元串，不可靠

理想情況下，組員是沒有任何許可權去控制這一塊的，也就是說無法被繞過，git hook的方式都是在組員本地，也存在了各種被繞過的風險。

那既然無法在本地校驗來達到目標，那就只能把目標放在gitlab-ci這一塊了。

正文

這裡有個前提，一個小組內，只能有部分人具有CI的控制權。並且一定有code review。只有具備以上兩點才能進行下一步。

通過在CI Variables來增加以下兩個變數：

NOT_SUPPORT_HOUR 17,18,19,20,21
NOT_SUPPORT_WEEK 4,5,6,0

這個變數就應對上上面所說的只能有部分人具有CI控制權

然後在.gitlab-ci.yml裏增加一個check_deploy stages，以及增加相關的pip

stages:
- check_deploy
check_time:
image: busybox
stage: check_deploy
script:
- export TZ=UTC-8
- export CURRENT_WEEK=$(date +%w)
- export CURRENT_HOUR=$(date +%H)
- if [ $(echo $NOT_SUPPORT_HOUR | grep "${CURRENT_HOUR}") ]; then exit 126; fi;
- if [ $(echo $NOT_SUPPORT_WEEK | grep "${CURRENT_WEEK}") ]; then exit 126; fi;
only:
- master

通過啟動一個busybox容器，來對當前時間以及不允許時間段進行一個比較，噹噹前時間點在不允許時間端內，則拋出錯誤碼126。且只對上線分支有效（這裡為master分支）

這個也對應上了，之前所說的一定有code review

其實這個方法也有缺陷，那就是是剛剛所說的兩個前提，以及不應該把這種限制下發到小組單位，理想的情況下各個小組都是沒有許可權進行控制的，正在的控制權應該上升到更高一層，但是目前還想不到好的方式讓更高一層介入進來。所以目前只能通過這種方式來做到上線控制。

其他

我司(愛樂奇)招人，感興趣的小夥伴可以來投簡歷呀。

彈性工作制、每日水果、同事都特別nice、965、團建、五險一金...

地點上海浦軟大廈

推薦閱讀：

相關文章