摘要:之所以這么要求,是因為減少在人員不齊情況下上線帶來的風險。只有具備以上兩點才能進行下一步。所以目前只能通過這種方式來做到上線控制。
前提目前公司在很多項目在上線時,都明確要求了,周四、周五上線production環(huán)境需要發(fā)郵件申請,周六、周日不允許上線,周一至周三每天下午5點到晚上9點不允許上線。
之所以這么要求,是因為減少在人員不齊情況下上線帶來的風險。
而這種規(guī)范,只能由公司各個項目組之間的自覺,但是這種自覺其實是一種不可靠因素。我個人感覺還是需要一套約束,來降低這種不可靠因素。
目標前提確定好后,那就需要一個目標了。也就說,在某些分支上的某些時間點是不允許讓CI進行自動構建的。
一開始,我的想法是通過git hook來實現(xiàn),但是后來給否決了,原因為:
pre-commit 只是針對當前commit的時間點,并不是push的時間點
pre-push 雖說可以做到,但是問題在于,可以通過--no-verify來跳過鉤子,而且這種跳過是下發(fā)到組內每個成員的。
對merge無能為力,網(wǎng)上的方案都是通過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
其實這個方法也有缺陷,那就是是剛剛所說的兩個前提,以及不應該把這種限制下發(fā)到小組單位,理想的情況下各個小組都是沒有權限進行控制的,正在的控制權應該上升到更高一層,但是目前還想不到好的方式讓更高一層介入進來。所以目前只能通過這種方式來做到上線控制。
作者信息:Author: Black-Hole
Blog: bugs.cc/
github: github.com/BlackHole1/
Twitter: twitter.com/Free_BlackH…
Email: 158blackhole@gmail.com
其他我司招人,感興趣的小伙伴可以來投簡歷呀。
彈性工作制、每日水果、小伙伴都nice、965、五險一金...
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/7029.html
摘要:近期在按照業(yè)務劃分項目時,我們組被分了好多的項目過來,大量的是基于的,也是我們組持續(xù)在使用的語言。部署環(huán)境強依賴本地,因為需要在本地建立倉庫的臨時目錄,并經(jīng)過多次的方式完成部署上線的操作。 近期在按照業(yè)務劃分項目時,我們組被分了好多的項目過來,大量的是基于 Node.js 的,也是我們組持續(xù)在使用的語言。 現(xiàn)有流程中的一些問題 在維護多個項目的時候,會暴露出一些問題: 如何有效的使用...
摘要:正式內測月初,上線,正式進入開發(fā)者的視野。公測注冊取消邀請碼限制,用戶可直接注冊使用。支持持續(xù)部署相比持續(xù)集成,持續(xù)部署的工作流程更受關注。 從 0 到 1,從邀請式內測到收費上線,flow.ci 經(jīng)歷了十個多月的沉淀與打磨。這期間,flow.ci 工程師們奮力趕工,進行了一系列的大功能更新,Bug 修復,功能優(yōu)化。 這篇文章記錄了 flow.ci 內測期間的大功能更新和相關的實踐教程...
摘要:系列文章第五篇中介紹了線上生產(chǎn)環(huán)境使用集群,這篇文章對原來的架構進行了優(yōu)化,同時使用了最新的一些特性,記錄一些流水賬。配置文件鑒于上次搭建時配置文件管理混亂,這次做了統(tǒng)一規(guī)劃為每個環(huán)境創(chuàng)建不同的配置文件,可以以環(huán)境名后綴。刪除無用的容器。 系列文章第五篇中介紹了線上生產(chǎn)環(huán)境使用 Docker 集群,這篇文章對原來的架構進行了優(yōu)化,同時使用了 Docker 最新的一些特性,記錄一些流水賬...
摘要:所以此版本號在這里的作用并不是用來區(qū)分版本的,小版本號才是真正用來做版本區(qū)分的,那么在引用這個就要這么來控制版本號,舉個栗子鎖定大版本號和小版本號,不管我們開發(fā)過程中提交了多少次,我們引用都是最新的。 最近在把公司內部用的一個庫發(fā)布到內網(wǎng)的npm私服上,僅僅是發(fā)布的話是比較簡單的,但這個庫是由多個人一起維護的,而且npm私服只有一套,所以生產(chǎn)環(huán)境和開發(fā)環(huán)境,用的是同一個,那么,我們的需...
摘要:集成測試完成后,由運維同學從發(fā)起一個到分支,此時會會運行單元測試,構建鏡像,并發(fā)布到預發(fā)布環(huán)境測試人員在預發(fā)布環(huán)境下再次驗證功能,團隊做上線前的其他準備工作運維同學合并,將為本次發(fā)布的代碼及鏡像自動打上版本號并書寫,同時發(fā)布到生產(chǎn)環(huán)境。 云原生 (Cloud Native) 是伴隨的容器技術發(fā)展出現(xiàn)的的一個詞,最早出自 Pivotal 公司(即開發(fā)了 Spring 的公司)的一本技術小...
閱讀 3684·2021-11-25 09:43
閱讀 2600·2021-11-18 13:11
閱讀 2193·2019-08-30 15:55
閱讀 3271·2019-08-26 11:58
閱讀 2823·2019-08-26 10:47
閱讀 2230·2019-08-26 10:20
閱讀 1270·2019-08-23 17:59
閱讀 2999·2019-08-23 15:54