基于Gitlab CI的上線時間校驗

ephererid 發布于2019-05-23 14:34 / 1372人閱讀

摘要：之所以這么要求，是因為減少在人員不齊情況下上線帶來的風險。只有具備以上兩點才能進行下一步。所以目前只能通過這種方式來做到上線控制。

前提

目前公司在很多項目在上線時，都明確要求了，周四、周五上線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

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

作者信息：

Author: Black-Hole

Blog: bugs.cc/

github: github.com/BlackHole1/

Twitter: twitter.com/Free_BlackH…

Email: 158blackhole@gmail.com

其他

我司招人，感興趣的小伙伴可以來投簡歷呀。

彈性工作制、每日水果、小伙伴都nice、965、五險一金...

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/7029.html

GitLab CI/CD 在 Node.js 項目中的實踐

摘要：近期在按照業務劃分項目時，我們組被分了好多的項目過來，大量的是基于的，也是我們組持續在使用的語言。部署環境強依賴本地，因為需要在本地建立倉庫的臨時目錄，并經過多次的方式完成部署上線的操作。近期在按照業務劃分項目時，我們組被分了好多的項目過來，大量的是基于 Node.js 的，也是我們組持續在使用的語言。現有流程中的一些問題在維護多個項目的時候，會暴露出一些問題：如何有效的使用...

Profeel 2019-08-23 17:52 評論0 收藏0
幾分鐘看完 flow.ci 全部功能

摘要：正式內測月初，上線，正式進入開發者的視野。公測注冊取消邀請碼限制，用戶可直接注冊使用。支持持續部署相比持續集成，持續部署的工作流程更受關注。從 0 到 1，從邀請式內測到收費上線，flow.ci 經歷了十個多月的沉淀與打磨。這期間，flow.ci 工程師們奮力趕工，進行了一系列的大功能更新，Bug 修復，功能優化。這篇文章記錄了 flow.ci 內測期間的大功能更新和相關的實踐教程...

yuanzhanghu 2019-06-28 15:38 評論0 收藏0
Docker 實踐（九）：生產環境優化

摘要：系列文章第五篇中介紹了線上生產環境使用集群，這篇文章對原來的架構進行了優化，同時使用了最新的一些特性，記錄一些流水賬。配置文件鑒于上次搭建時配置文件管理混亂，這次做了統一規劃為每個環境創建不同的配置文件，可以以環境名后綴。刪除無用的容器。系列文章第五篇中介紹了線上生產環境使用 Docker 集群，這篇文章對原來的架構進行了優化，同時使用了 Docker 最新的一些特性，記錄一些流水賬...

AlienZHOU 2019-06-28 15:53 評論0 收藏0
如何設計npm包的開發和發布流程

摘要：所以此版本號在這里的作用并不是用來區分版本的，小版本號才是真正用來做版本區分的，那么在引用這個就要這么來控制版本號，舉個栗子鎖定大版本號和小版本號，不管我們開發過程中提交了多少次，我們引用都是最新的。最近在把公司內部用的一個庫發布到內網的npm私服上，僅僅是發布的話是比較簡單的，但這個庫是由多個人一起維護的，而且npm私服只有一套，所以生產環境和開發環境，用的是同一個，那么，我們的需...

qieangel2013 2019-08-23 17:02 評論0 收藏0
容器環境下的持續集成最佳實踐：構建基于 Drone + GitFlow + K8s 的云原生語義化

摘要：集成測試完成后，由運維同學從發起一個到分支，此時會會運行單元測試，構建鏡像，并發布到預發布環境測試人員在預發布環境下再次驗證功能，團隊做上線前的其他準備工作運維同學合并，將為本次發布的代碼及鏡像自動打上版本號并書寫，同時發布到生產環境。云原生 (Cloud Native) 是伴隨的容器技術發展出現的的一個詞，最早出自 Pivotal 公司（即開發了 Spring 的公司）的一本技術小...

asoren 2019-06-28 17:10 評論0 收藏0