說一說,正常上線的流程

2021-09-20 20:27:19 字數 1309 閱讀 3010

很多時候,經驗是被痛苦逼出來的,流程是被錯誤逼出來的。在上線的過程當中,這段時間遇到了一些問題,造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。

另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本,也是有可能的。像我現在的公司,經常一天修改好多次文案,就需要不斷的上線。如果處理不及時上線的話,會造成使用者的一些誤解,導致一些投訴以及不好的使用者體驗。這麼頻繁的修改上線,也是需要一定的流程和規範保證。

很多網際網路公司都開始使用git,替換了svn。git非常適合網際網路迭代以及多人多版本開發。如果讓我說為什麼喜歡使用git,我喜歡切換分支,以及分支之間merge的方便快捷。

新建分支以及合併分支的便利性,會造成一些問題,分支不自然的就會過多。所以需要定時的需要刪除一些過時的分支。

一般來說,網際網路專案有上線分支,預上線分支,測試分支,開發分支等.

保證不同的分支做不同的事情,防止分支汙染。

上線分支,是發布到線上的分支,以這個分支為準,其他分支都是以這個分支為基礎拉取。

預上線分支,在預上線環境當中,防止出錯的最後一道保證。

測試分支,可能測試環境大家共用一套,所以把**都merge到這裡,然後發布。這樣大家各自測試自己的,互不打擾。如果有多個測試環境的話,直接使用開發分支測試也是可以的。

開發分支,從上線分支拉取,根據需求修改的新分支。

上面的這張圖看起來有一點複雜。總體上來,可以分為這麼幾步。

第一步,需求來了之後,從上線分支拉取乙個開發分支。

第二步,在開發分支進行開發,自測。

第三步,合併到測試分支,通知qa測試。

第四步,如果通過測試,合併到預上線分支,然後繼續測試。如果不通過測試,進入第二步。

第五步,如果預上線測試通過,將預上線分支合併到上線分支。如果不通過測試,進入第二步。

第六步,上線,然後線上測試。如果通過測試,那麼這個需求開發就結束了。如果沒有通過測試,就撤回上線,然後進入第二步。

測試分支以及預上線分支要定時清理,和上線分支同步。

上線分支以及預上線分支,merge許可權保證在少數人手裡。merge的時候,需要檢查提交以及對線上的影響。

只能在開發分支修改**,其他分支都是等著被merge.

提交之前,需要保證和上線分支沒有衝突。

防止分支被汙染,特別是受到測試分支汙染。

人是最難管理的,以及人是懶惰的。這些話是非常準確的,所以會遇到一下問題,還得需要解決。

需求改動非常小,是不是還得走整體流程。

我只是修改文案,是不是還得走整體流程。

具體怎麼做,每乙個公司和組都有自己的做法,是不是都必須都得走一遍流程。但是,分支規範是必須的,不能隨意修改。直接在上線分支修改,堅決說no!

說一說,正常上線的流程

很多時候,經驗是被痛苦逼出來的,流程是被錯誤逼出來的。在上線的過程當中,這段時間遇到了一些問題,造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本,也是有可能的。像我現在的公司,經常一天修改好多次文案,就需要不斷的上線。如...

說一說,正常上線的流程

很多時候,經驗是被痛苦逼出來的,流程是被錯誤逼出來的。在上線的過程當中,這段時間遇到了一些問題,造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本,也是有可能的。像我現在的公司,經常一天修改好多次文案,就需要不斷的上線。如...

簡單的說一說mmap

mmap memory map,就是記憶體對映 簡單的說就是將檔案對映到使用者的位址空間中。這麼做有什麼好處呢?1.傳統檔案訪問方式是,首先用open系統呼叫開啟檔案,然後使用read,write等呼叫進行順序或者隨即的i o.這種方式是非常低效的,每一次i o操作都需要一次系統呼叫.而通過mmap...