背景
爲公司設計正確的倉庫命名規範是至關重要的。爲產品開發創建正確的倉庫結構，在產品擴展性方面發揮着至關重要的作用。它不僅可以減少創建管理倉庫的開銷，還可幫助團隊意識到倉庫規範管理的好處，幫助組織內部各個團隊清楚的瞭解軟件交付物的命名規範。
使用 Artifactory 作爲倉庫管理平臺，將所有不同類型的二進制文件存放在一個地方，並將企業級功能完全集成到軟件開發生命週期中。
軟件開發涉及到不斷更新和迭代的過程。 通過參與產品開發的各個團隊，以最高精度維護倉庫結構成爲該過程的重要任務之一。 我們面臨的挑戰是，沒有清晰的命名約定或創建倉庫結構的指導原則可以遵循。
JFrog 建議使用四部分的命名結構，其中包括：
1. Team —— 產品或團隊名稱作爲項目的主要標識符
2. Technology —— 使用的技術，工具或包的類型。
3. Maturity —— 軟件包生命週期，例如開發，測試和發佈階段。
4. Locator —— 定位，工件的物理拓撲。
此結構會生成以下推薦的倉庫命名結構，該結構應在整個公司中使用：<Team> - <Technology> - <Maturity> - <Locator>。
其他準則適用於四種不同的 Artifactory 倉庫類型，包括：本地，遠程，虛擬和分發。 本地倉庫命名約定由兩部分組成。第一個是存儲的文件是你們自己的，第二個是第三方的。 遠程倉庫是 Artifactory 拓撲的一部分，它們的命名規則應與本地倉庫定義的規則保持一致，或者如果是提供給其他人使用的，建議給它們稍微不同的命名約定。虛擬倉庫是對外透明的，封裝了內部細節，所以不需要定位器結構字段。最後重要的一點是，分發倉庫支持多種技術類型，通常以“-Dist”結尾。
爲倉庫設置命名約定時，需要考慮的三個主要類別是：安全，性能和可操作性。
當使用 Artifactory 作爲倉庫時，最好的做法是在倉庫級別管理安全權限。這樣公司中不同的團隊將會管理不同的倉庫。
性能問題因技術而異，爲了確保倉庫效率最高，應該執行清理策略。此外，在倉庫結構中應用的可操作性應考慮效益問題以及團隊結構。儘管管理員偏好較少的倉庫，但有時創建單獨的倉庫，並具有不同的讀/寫/刪除權限，以防止團隊間的彼此干擾是最好的方式。
本文涵蓋的所有這些考慮事項將使你能夠在全球拓撲中管理你的 Artifactory，併爲安裝了企業版 Artifactory 的公司提供所需的 DevOps 支持。
使用倉庫管理平臺
JFrog Artifactory 是爲加速開發週期而創建的通用二進制倉庫管理平臺。這意味着它不僅是一個倉庫，而且還是一個功能強大的管理平臺，有助於管理多個倉庫以簡化分佈式軟件開發流程。
在爲倉庫定義準則和約定時，靈活性優於嚴格的規則。創建彈性的規範能夠爲 Artifactory 管理員提供足夠的空間來根據需要量身定製規則。
命名約定和倉庫結構是同樣重要的。選擇合適的名稱和用一個倉庫還是多個倉庫一直是棘手的問題。選擇的組織結構應該與你們現在的開發，測試，部署和分發流程一致，這一點非常重要。這裏所描述的命名約定和組織結構主要基於當前主流的流程，但可能並不適用於所有公司。然而，希望你可以使用這裏列出的組織和命名中的注意事項來將其適應於你自己的命名約定。
創建命名約定
公司通常需要處理在多個倉庫中產生的多種技術，生命週期和產品。當你有不止一個產品的時候，你需要給它起個名字。作爲開發人員，在過去的幾十年裏，我們已經瞭解到一個名字可以清晰地表明你正在做什麼。
JFrog 認爲最佳實踐應該包含以下四點：
最佳實踐1：定義生成可用 URL 的倉庫名稱。例如，由於 Artifactory 是區分大小寫的，所以建議使用小寫字母。更重要的是，避免在你的環境中使用需要 URL 編碼的字符，例如”_”字符。通過簡化 URL，這將使你的 Artifactory 實例的最終使用者以及管理反向代理和負載均衡的管理員更容易理解和使用。
最佳實踐2：所有編碼人員都熟悉的：self documenting code! 儘可能確保你的倉庫名稱是自描述。雖然是一個描述字段，但是當倉庫名稱清晰時，它使事情變得更加容易。
最佳實踐3：Artifactory UI 界面搜索展示的問題。你的倉庫名字的描述應該放到首位。通過這樣做，在應用過濾器選項之後，將根據名稱組件的重要性在 Artifactory 樹型瀏覽器中將相似的倉庫放在一起。
最佳實踐4：要注意一些特殊的規則。例如，有一些特殊字符（'/'，'\\'，'：'，'|'，'？'，'*'，'''，'''，'<'，'>'' ，'+'，空格）應當被禁止。名稱最多可以包含64個字符，遠程倉庫可以包含58個字符。還有一些保留的和不推薦的名稱，如'Repo'和'Trash'。附加單詞'-Cache'也被認爲是保留的，因爲它主要用於爲遠程倉庫自動創建緩存。
倉庫命名基礎結構
JFrog 推薦一個四部分命名結構，最好是按以下順序。
1.產品或團隊
產品或團隊名稱是項目的主要標識。你可以根據企業命名約定選擇縮寫。例如，一些組織喜歡使用產品縮寫而不是使用整個產品名稱。另一方面，有些人更喜歡使用團隊名稱和產品名稱。主要的想法是選擇一個與你的團隊相關且容易理解的名字。
例如：JFrog
爲命名約定選擇團隊/產品名稱的粒度級別是開發命名約定中最困難的部分之一。這將在本文後面的倉庫組織部分進一步討論。但是，由於存在虛擬倉庫，這也可以在晚些時候相當容易地更改，所以不要太擔心，所以應選擇易於理解和一致的東西，並查看它是否適用於你。
2.技術
技術是指工具或包裝的類型。Artifactory 是一個通用的二進制倉庫管理平臺，其核心功能使其能夠存儲各種類型的包，這些包涵蓋了 Maven，NuGet 和 Docker 等技術。每個倉庫應該保存同一種類型的二進制文件。
繼續上面的示例，例如：JFrog-Docker
在命名約定中加入工具或軟件包名稱的類型可幫助開發人員識別工件，使其更容易根據其類型進行瀏覽。在大多數情況下，這將精確反映在創建倉庫時選擇的軟件包類型，但你可以選擇更具體。例如，如果你的通用倉庫存儲視頻，則可以選擇“Video”一詞作爲技術類型。其他例子有：使用'Centos'而不是'Rpm'或'Rhel'，'Ubuntu'而不是'Deb'。
3．成熟度
Maturity 指的是軟件包開發的成熟度，如開發，測試和發佈階段。包的Promotion 可以在 Artifactory 中以多種不同的方式完成。從較小事件的簡單屬性標記（例如“通過測試”）到工件已經通過的較多的質量檢測，其中工件將從一個倉庫移動或複製到另一個倉庫。
那麼，爲什麼我們要這樣做呢？通常情況下，在傳統的開發模式中，當工件改變其狀態時，這可能代表了在其成熟度的不同階段。你可能有一個“ 沙箱 ”，對於在初始提交構建的“ Dev ”或“ Snapshot ” 產生的工件正在由開發人員在他們的辦公電腦上進行測試。然後工件將移動到“ Qa ”，“ Preprod ”或“ Staging ”倉庫，最後轉到“ Release”或“ Prod “倉庫。當工件完成時，或者當它觸發了保留的某些監管要求時，工件及其可能的所有依賴關係可以移動到“ Archive”。
在 DevOps 中怎麼做呢？根據 DevOps 原則，工件不應該傳遞給新團隊，而應該在整個生命週期中由同一團隊擁有。從自動化的角度來看，控制狀態不是關於公司內的團隊，而是基於具有不同權限模型的不同環境，以確保工件不會過早部署。
繼續上面的示例，例如：JFrog-Docker-Release
下圖說明了一個典型的 Promotion 概念。如果滿足質量要求，工件從一個 DevOps 階段傳遞到另一個階段：
4.定位
定位實質上是指你的工件的物理拓撲結構。拓撲中的每個倉庫都必須是唯一的。真正本地的本地倉庫，意味着它們的內容在本地進行管理/上傳，應以“Local”結尾。作爲其他地方管理的內容和遠程倉庫應以其他服務的指示符結尾。
例如，“bj” 可以用於在北京的數據中心管理的工件。爲了符合要求，訪問外部位置的遠程倉庫應以“-Remote”結尾。這通常被省略，特別是對於主要的中央倉庫，假設用戶熟悉“Jcenter”和“Npmjs”作爲中央倉庫的名稱，但是這樣的假設可能導致混淆。
使用以下倉庫名稱完成我們的示例：JFrog-Docker-Release-bj
倉庫類型
Artifactory 擁有四種倉庫類型：本地，遠程，虛擬和分發。本地和遠程倉庫是真正的物理倉庫，而虛擬倉庫實際上是它們的集合，用於創建搜索和解決工件的受控域。分發倉庫是將數據從 Artifactory 導出到 JFrog Bintray 的特例。
JFrog Bintray 是一個通用的分發平臺。它是一個雲平臺，可讓你完全控制發佈，存儲，升級和分發軟件的方式。
本節提供了有關針對每個倉庫類型如何應用上述命名結構的指導原則。
命名約定的任何部分在不相關時都可以是可選的，並且四部分命名約定的一般概念可以適用於初始約定中未涉及的其他情況。
1.本地倉庫
使用前一節中描述的四部分命名結構，我們可以解決本地倉庫命名約定的所有必需注意事項，包括：團隊/組織（業務單位或產品），技術，成熟度和定位。正如所討論的，順序代表了重要性。JFrog 的建議是：<Team> - <Tech> - <Maturity> - <Locator>，但其他命名方式可能適用於某些情況。
本地倉庫有兩個基本的使用場景：第一個場景是當你引用與你自己的組織工件相關的工件時。在這種情況下，定位完全基於拓撲考慮。另一方面，團隊和成熟度稍微複雜一些，主要取決於所需的倉庫數量。團隊取決於業務邏輯和權限。成熟度取決於工件的所有權/處置。如果一個 Artifactory 實例專注於部署而不是開發，那麼考慮成熟度實際上比技術更重要。但是，優先符合統一的命名約定。
本地倉庫的第二個使用場景是用於存儲第三方工件的時候。這通常包括一種場景，無論是什麼原因，你無法遠程代理某第三方依賴源（無論是因爲防火牆還是僅僅因爲它沒有 http 訪問權限），或者你正在實施一個白名單。總的來說，在這兩種場景下，技術類型結構定義還是一樣的，但團隊名稱應該是指明其來源地的東西; 例如，Tomcat 或 Centos。由於通常還有這些拓撲，所以定位的方式與其他本地倉庫的工作方式相同。然而，成熟度現在不是像 Release / Dev 這樣的東西，而是反映了工件的信任級別。所以它可能是“Upload”或“Whitelist”。例如，“Tomcat-Mvn-Upload-Local”。如果你使用本地倉庫在某個狀態下對遠程進行快照，則可能是日期。例如，“Centos7-Rpm-Oct2017-Local”。
2.遠程倉庫
遠程倉庫分爲兩類：
一些是 Artifactory 拓撲的一部分，在這種情況下，它們的命名約定應該與本地儲存庫和四個相關部分的命名約定一致，並且定位指示源儲存庫被遠程訪問。
一些是中央儲存庫。這些是你的工件正在從中依賴的外部倉庫，可以通過它們的源 ID 引用，如 JCenter。對於嚴格的一致性，你可以考慮以下模型，<Center_Name> - <Technology> --Remote，默認的 Artifactory 命名行爲使用源。通常，這有助於輕鬆識別工件。
3.虛擬倉庫
大多數虛擬倉庫不包含<Locator>，並且由<Team> - <Tech> - <Maturity>組成。在很多情況下，用戶不需要知道拓撲實現細節。通常，所有消費和寫入都是通過虛擬倉庫完成的，而不是本地/遠程倉庫。這樣儘可能多的實現細節可以省略，讓用戶使用一個衆所周知的 URL。此外，儘管本地倉庫的成熟度嚴格限於工件階段，但對於虛擬倉庫，你可能會更多地考慮受衆。例如，名稱中包含“-Dev”的虛擬倉庫指示開發人員應該使用的虛擬倉庫。最後，一個常見的使用案例是整個公司使用一個虛擬倉庫，該倉庫將特定技術的所有倉庫（例如 Docker）聚合爲解析和讀取權限。
4.分發倉庫
分發倉庫在這個約定中有些異乎尋常，因爲它們可以支持多種技術類型，並且通常沒有成熟度的區別，因爲你只應該分發穩定的工件。一般來說，它們應該以“-dist”作爲定位符結束。分發產品的分發倉庫應使用以下約定：<productname> -product- <orgname> -dist。更通用的分發倉庫應該使用像<ruleset> - <orgname> -dist這樣的約定爲其配置的規則集的某個名稱標識符。如果你的組織不具有多個 Bintray 組織，則這種組織名稱可以省略，這是比較常見的。但是，必須將不同的分發倉庫分發給不同的組織，並且額外的組織（例如支持開源項目）也不是前所未聞的。有些前瞻性規劃不會損失任何功能，這就是爲什麼它包含在推薦的約定中的原因。
未完。請關注下篇：Artifactory 倉庫架構和命名最佳實踐（下）