前言
容器化給我們帶來很多好處，比如鏡像交付的不可變性，交付物的標準化，使得CICD的能力能夠進一步提升。合理的設計好鏡像名稱更加能夠在管理鏡像及出問題的時候事半功倍。
一個栗子
我們使用阿里雲的容器鏡像服務託管鏡像，鏡像的名字是這樣的格式：registry.cn-qingdao.aliyuncs.com/[namespace]/[imageName]:[buildNumber]-[gitCommitHash]
registry.cn-qingdao.aliyuncs.com
這部分是描述鏡像倉庫，沒什麼可說的
imageName
鏡像的名字，以我們的經驗是{appName}-{category}-{env}，appName跟category還好理解，一個是應用名字，一個是分類，例如是frontend的http服務還是backend的rpc服務，見名知意，那這個env是什麼呢？說好的鏡像不可變呢，爲啥又跟環境扯上了關係。
這個就要說下我們的開發流程了，按照標準最簡單的CICD流程
所有的開發人員從master分支checkout獨立的featureBranch，在各自的featureBranch上進行開發，
開完畢後merge到master分支進行構建鏡像測試，然後預發，然後發佈到線上
但是現實總是殘酷的，我們作爲一個創業公司，不可避免的要提高開發效率，多個版本並行，跨迭代測試，功能先測後上是常有的事，那麼這個如何解決呢？
經過我們的討論，我們這樣設計的，開發人員在各自的featureBranch上進行開發，開發完畢在DEV環境自測，測試完畢後merge到Test分支，測試環境用Test分支進行測試。
但是發佈的時候就有所不同，發佈的話是用master分支進行發佈需要上線的功能merge到master分支進行發佈，所以測試同學測試的分支未必是發佈的分支，這樣是否會有問題？其實是有問題的，但是在效率面前，我們承擔了風險，爲了使風險最低，鏡像不會直接上線，而是走預發流程在staging進行基本的驗證，重要服務可能還會導入小量的流量驗證，真正上線的時候，還有金絲雀發佈來進一步保證。我們用master構建出的鏡像爲了與測試分支區分，就標註了prod字樣，意思是線上鏡像。這樣就解釋了爲什麼鏡像名字當中含有環境的信息。
buildNumber
這個是我們jenkins系統這次構建的構建號，通過構建號能夠找到構建日誌信息
gitCommitHash
這個是git的短hash，在git當中可以通過這個hash值找到提交點的各種詳細信息，甚至提交點被合併到了哪些分支等等的信息，我們可以通過提交點來回退版本，更精準。