專欄策劃｜雅純
志愿編輯｜張晟
軟體交付是以代碼為中心的交付程序，其中代碼的作用有幾點：第一，最終的制品要交付成什么樣，需要通過代碼描述清楚；第二，代碼定義了系統和軟體是怎樣作業的；第三，代碼定義了系統的運行環境是怎樣的，所有這些都是圍繞代碼，
那我們的代碼管理和軟體配置管理應該怎樣做呢？
我們先看一個例子，下圖是某個團隊的代碼組織結構，這樣的代碼組織結構會有什么問題呢？
問題1：代碼組的命名方式混亂
我們發現在最上層的目錄中叫risk-managenment，這是一個系統，這個系統是風險管理，但是子目錄寫的是叫“qinglong”，那“qinglong”是應用還是團隊，我不知道，然后下面還有一個玄武，下面還有一個aTeam，中英文混雜，這樣的命名方式是很混亂的，
問題2：用代碼塊存盤外部二進制檔案
在android-sdks里面會存放很多sdk檔案，這些檔案是很大的，這個代碼庫存盤很多外部二進制檔案，我們知道在代碼庫直接存這樣的大檔案，對整個代碼庫的資源消耗是非常大的，
問題3：同一歸屬的代碼保存在不同的代碼組
在aTeam目錄下有一個data-model，但是其他相關的檔案都在玄武下，就是data-console、data-task、data-ui，我們不知道它具體是什么，但是我們知道這幾個大概率是同一個應用或者是同一個產品，所以它在兩個不同的層級也是不合理的，
問題4：公共庫保存在子代碼組里
再下一個是common-lib，通過名字來理解就是公共庫，但是這個公共感覺只給玄武這個子代碼組使用，
問題5：應用的檔案（或測驗）與應用分開存放
最后還有一個docs目錄下有risk-docs和data-docs，一個是針對風險控制的系統，一個是針對資料地系統，那這個里面檔案也是一個代碼庫，檔案代碼庫和測驗代碼庫，它和應用是分開存放的，這也是不合理的，
好的代碼庫組織形式是怎樣的？
問題：假設所有的代碼都保存在一個代碼庫，且所有人均可訪問，代碼庫應該怎么組織？
我們認為代碼庫是可以分組的，代碼組（+子代碼組）+代碼庫=大庫，
基于這個邏輯，我們再看看剛才那個例子里合理的代碼組的結構應該是怎樣的，
如上圖所示，整個代碼庫是一個系統，這個系統有兩個應用，一個是risk，一個是data，每個應用下面是有很多的服務和檔案，它們有一個公共的Model，叫common-lib，這是被所有的應用所依賴的，所以我們把屬于同一個應用的Git倉庫放在一起，讓common放到該有的地方去，不是按照團隊，而是按照應用組劃分，這樣劃分，結構就更加清晰了，這里我們稍微總結了一些實踐的建議，
- 代碼庫的內容：
-軟體的源代碼（ProductionCode）；
-將檔案（和測驗）的git庫放到其相關應用組下；
-不要將制品（如系統二進制包）保存在代碼庫中，如果確實需要，以LFS或類似方式存放；
（小編推薦：云效代碼管理Codeup為企業提供免費不限容量的LFS存盤）
- 代碼庫的組織結構：
-按照系統、應用和模塊的層次來組織代碼庫；
-同一個系統/應用層級的所有內容位于同一個代碼組下；
- 代碼庫的可見性：
-通用代碼庫放在其通用級別都可以訪問的位置；
-除核心演算法等少數代碼庫外，建議對代碼庫的訪問在同一系統/應用下對所有相關人員公開；
代碼組織完了以后，開發者就可以圍繞代碼庫來進行協作，整個代碼庫的協作程序就是：一切皆Commit，無論是rebase還是merge，都是Commit，
那對于Commit，我們有什么要注意的呢？
什么是好的Commit
我們總結了3點建議給到大家：
1.Samll
Git庫要盡可能地小，尤其是目前的基礎設施現狀下，雖然你的一個倉庫里可以放多個應用，但是維護起來的成本會很大的，還有管理方面，不要在Git上存盤構建產物和其他二進制檔案，把構建產物放在構建倉庫上，雖然給別人方便了，卻很難知道這個構建產物是現在的代碼產生出來的還是之前產生出來的，這是很難去追溯的，對于二進制檔案，如果確有必要（例如游戲的素材），建議使用LFS的方式來保存，
2.Linear
避免無意義的merge，盡量用rebase操作，其次是避免無效commit，有很多代碼庫commit記錄很長，但是里面80%都是無效的，例如都是fix1、fix2這樣的commit，都卻不知道它具體做了些什么，這種顯然是不合理的，對于這種冗長的commit串列，有時候可以在merge的時候squash一下，
3.Atomic
原子性，指操作的原子化，原子性有什么好處呢？一個Commit解決一個特定的問題，比如說我就是修復一個UTcase，或者是加一個UT或者是加一個功能，或者是加一個API，這些明確的問題對應到一個commit，很容易追溯，解決的問題不能很大，不能寫了2000行代碼解決了一個feature，一起提交，這是非常危險的，作為開發者，做的好的應該是快速有階段性的成果，并且持續地有反饋，持續地貼近目標，反之，開發者的體驗不好，相關協作者的體驗也不好，因為別人不知道你做了多少了，很有可能跟你發生mergeconflict，
下面列舉一些Commit的反模式：
1.無效的commit
如Mergebranch'develop'of https://codeup.aliyun.com/abc/xyzintodevelop第一個問題，在幾乎所有公司里面都是隨便拉開一個代碼，本地和遠程都有這種情況，本來一個rebase搞定的事情，這樣做會導致很多無效的commit，甚至對commit追溯能力會產生很大地影響，
2.巨型commit
一個commit里面包含了大量的代碼變化，且屬于多個實作目的，就像codereview，有些人提的mergerequest，一下子過來3000多行代碼，作為reviewer，你完全不知道他做了什么，這是非常危險的，
3.半成品的commit
如包含有基本語法問題或實作錯誤的代碼的commit半成品的commit，例如，到飯點了，不管了，先提交一把，這樣的代碼連編譯都過不了，這個顯然是不好的，沒有任何意義，
4.分支間的互相merge
最后一個是分支間的互相merge，從develop合到master，又從master合到develop，互相合來合去，一旦這種合并多了以后，commit就會很難追溯，因為不知道源頭在哪，我們建議代碼庫應該有一個唯一的主干，單向往主干merge，盡量避免反向merge的情況，
（小編推薦：云效代碼管理Codeup的主干開發模式，就提倡輕量的commit評審 和主干研發，幫助企業避免分支間的復雜合并～）
軟體配置管理
問題：軟體配置經常被修改，被發布，它屬于代碼嗎？
軟體配置其實是另外一種形式的代碼，有可能大家在實際作業中配置不是存在Git倉庫里面的，可能是在一個配置中心或者其他類似系統里面，但無論在哪里，本質上，我們可以把配置等同于某種型別的代碼，
下圖是大家常見的靜態配置和動態配置，或者說啟動相關的配置和運行相關的配置，
啟動相關配置
- 啟動相關配置是構建到鏡像中或者作為啟動引數傳進去的，
- 啟動之后不再修改了，不需要去動態監聽它的變化，
- 對這類配置的修改，一般需要重新創建或者重啟容器，
以此類推，哪些配置是啟動相關的呢？比如DB連接串、容器CPU規格、啟動模式等（比如有的壓測應用啟動的時候區分master模式和worker模式），其它像DNS服務地址等，諸如此類的我們都認為是啟動相關的配置，
運行相關配置
- 通常是通過監聽某個服務或檔案來獲取和更新的，比如說我要看一下我的白名單是什么，我去讀一下白名單，
- 配置的更新是不需要修改容器和Pod，
- 運行中的容器需要持續監聽配置的變化，當有變化后自動生效、無需重啟，
我們舉一下場景實體說明一下：
- 大促時期調整日志級別，只記錄ERROR級別的日志，
- 服務的黑白名單，為了限制某些IP的訪問，將其列入黑名單，
- 特性開關，通過開關打開或關閉某個feature，
- 監控采樣頻率，由每分鐘采樣一次調整為每5分鐘采樣一次，
這些配置不需要也不應該每次修改都重新部署應用，他們都屬于運行相關的配置，
我們再來看一個demo示例里面哪些是啟動相關的，哪些是運行相關的，我們列舉一下：
這是啟動的時候就會需要的一個引數，
我們將secret檔案注入到Deployment中，應用自動從檔案感知secret的值，無需重啟，因此它是運行時的配置，越內層的配置，修改成本越高，
從另外的角度看一下配置，它有不同的層次，代碼、鏡像、Pod和系統，代碼中的配置位于最內層，修改成本是最高的，因此，如果是編碼級別的修改，要經過所有的階段才能上線，如果運行階段的話，我是不需要動前面的部分，
最后，留一個問題給大家：運行環境相關的配置是屬于哪一種？歡迎大家在評論區留言互動，
軟體交付的終態是提供穩定可預期的系統，要做到這點，需要確保：1.運行環境的一致性；2.軟體制品的一致性，所以下篇，我們將開始分享如何保證運行環境的一致性，以及環境中大家常見的痛點和應對方案，敬請期待！
閱讀上篇：構建制品不一致，后續作業都是白費
點擊下方鏈接免費使用云效代碼管理Codeup
https://www.aliyun.com/product/yunxiao/codeup?channel=yy_rccb_36
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/423672.html
標籤：其他