什麼是製品？
製品是指由原始碼編譯打包生成的二進位制檔案，不同的開發語言對應著不同格式的二進位制檔案；這些二進位制檔案通常用於執行在伺服器上或者作為編譯依賴,“製品的管理”是配置管理的重要組成部分。
通常，這些元件是各種檔案的存檔，包括：類檔案中的Java位元組碼、C物件檔案、文字檔案、二進位制檔案。元件的多種格式，例如：Java JAR，WAR，EAR格式；普通ZIP或.tar.gz檔案；其他軟體包格式，例如NuGet軟體包，Ruby gems，NPM軟體包；可執行檔案格式，例如.exe 或.sh 檔案，Android APK檔案，各種安裝程式格式。
按照使用場景，製品大致分為三類
- 外部引入的第三方元件
- 產品內部依賴包，公共SDK
- 產品交付安裝包
按照開發語言，製品型別包含以下型別：
- Generic File 指的是通用檔案型別的製品。
- Docker
- Maven
- npm
- PyPI
- Helm
- Composer
- NuGet
- Conan
為什麼要製品管理？
- 外部依賴下載慢
- 影響研發構建速度
- 版本管理混亂 （svn,ftp）
- 交付包使用FTP或者SVN進行管理，管理粒度相對較粗；在這種粗放式的製品管理方式下，不同型別包的儲存與獲取是一件頭疼的事情，版本追蹤極其混亂，團隊協作也是障礙重重。
- 由於受到監管約束，一鍵部署是不可能任務，跨網段的包交付智慧依賴於手工拷貝
- 安全漏洞風險
- 依賴元件越多，引入漏洞的風險也越高
- 第三方依賴包下載管理混亂，沒有準入管控
- 漏洞藏的越深，修復漏洞所花費的時間就越長
- 製品儲存風險
- 團隊內部搭建的製品庫是單點的，缺乏叢集部署
- 資源浪費
- 因為沒有統一的製品庫，存在重複建設的問題；維護成本高，或者說目前根本就沒有維護
製品和CI/CD流水線
對於CI/CD流水線而言，製品起到一個承上啟下的關鍵作用，它是持續整合CI的終點，同時也是持續交付CD的起點。
如果缺乏有效的製品管理策略和工具，根本不可能建立高效的流水線；脫離製品管理，每次只能重新從程式碼開始構建，對於任何企業組織是不可接受的，同時也不符合“一次構建，多次使用”的原則。
在整個研發過程中，製品對於測試人員和運維人員至關重要，他們關注的是怎麼拿到需要的版本進行測試和部署，如果缺乏有效的製品管理，整個DevOps價值流就會出現銜接上的問題。你可能會碰到這種情況，測試同學會通過各種方式去詢問那個版本可以測試，包在哪裡等情況。
包的後設資料
何為包的後設資料？別人給你一個包，你怎麼知道包裡包含了哪些需求缺陷變更，包含了哪些程式碼提交，還有包的md5,hash等資訊。這些資訊對於測試人員追蹤問題的引入，後續改進，版本回歸至關重要，通俗點說，弄清楚製品的前世今生。
那麼這些資訊哪裡來？當然是持續構建CI流水線，需求，程式碼提交都可以通過CI流水線收集。如果你的組織購買過Jfrog的產品，會發現這個特點在的它的平臺上尤為突出。
製品的晉級
在開發實踐中，大多數團隊會準備DEV, TEST, UAT, RELEASE等不同的環境，相應的建設不同的流水線，將製品部署到不同的環境前都會對製品進行不同的測試，所裡這裡也衍生出來了製品的晉級，就是給製品設定不同的准入門禁。
綜上所屬，製品和CI/CD流水線有著緊密的聯絡，不可分割，在設計流水線時候要考慮好製品的使用場景。
製品管理工具
如上所述，由於製品管理的重要性，所以衍生出來對應的製品解決方案用來統一管理不同格式的軟體製品。 除了基本的儲存功能，還提供了版本控制、訪問控制、安全掃描、依賴分析等重要功能，最終建立“單一可信源”，是一種企業處理軟體開發過程中產生的所有包型別的標準化方式。
目前主市場上主流的製品管理工具主要有以下幾種：
Nexus
Nexus是一套“開箱即用”的系統不需要資料庫，它使用檔案系統加Lucene來組織資料。Nexus 使用ExtJS來開發介面，利用Restlet來提供完整的REST APIs，通過m2eclipse與Eclipse整合使用。Nexus支援WebDAV與LDAP安全身份認證。
Nexus是少有的支援幾乎所有主流製品格式，並且提供免費版的製品管理產品，這也是大多數中小公司的選擇，可以滿足大部分業務場景，但是，免費版不提供高可用方案。
價格參考： https://www.sonatype.com/products/pricing?topnav=true
由於Nexus在國內沒有代理商，所以大家對它的認知還有限，其實Nexus僅僅是sonatype產品解決方案的一種，提供對軟體研發週期的製品管理方案。
Jfrog Artifactory
Jfrog是一家以色列公司，專注於製品管理環境，提供商用的解決方案，所以它的產品是要花錢的。
下圖列出了Jfrog Artifactory和Nexus的產品特點對比，僅供參考。既然是掏錢買的，肯定比免費的Nexus提供的支援和服務更多，包括高可用，元件的漏洞風險分析，多地分發等等。不是說Nexus不行，而是我們大家用的大部分都是Nexus的免費版，其實它的收費版也提供類似的方案。
Harbor
Harbor是VMware公司開源的企業級Docker Registry專案，其目標是幫助使用者迅速搭建一個企業級的Docker registry服務。
基於官方 Registry V2 實現，提供了管理UI，基於角色的訪問控制(Role Based AccessControl)，AD/LDAP整合、以及審計日誌(Auditlogging) 等企業使用者需求的功能，通過新增一些企業必需的功能特性，例如安全、標識和管理等，擴充套件了開源 Docker Distribution。
Harbor目前已經成為私有Docker/Helm管理的主要工具，相比於Nexus, Harbor在docker映象的管理方面更有優勢，提供映象同步服務，支援團隊專案隔離。在實踐過程中，筆者發現Nexus在docker映象的團隊隔離方面上，存在一些問題。
WePack
WePack是騰訊Coding基於之前的DevOps拆分出來的單獨的製品管理服務，支援私有化部署。也許也是看到單獨的製品管理工具，比大而全的DevOps平臺更好的切入使用者場景吧。
如何管理製品？
為了統一管理不同語言格式的包，以上製品管理工具幾乎都按照如下方式管理組織製品。
製品庫的層級關係為：倉庫 > 包 > 版本，每個層級描述如下：
- 倉庫：用於管理不同型別的倉庫和倉庫下的包資源，可以設定倉庫對外的訪問許可權。
- 包：構建產物對外提供訪問的基礎單元，用於介紹當前構建產物的用途和使用指引。
- 版本：列出某個包下的所有構建產物，詳細記錄了每次構建產物的版本迭代更新變化。
規範製品庫命名
如果團隊比較大一，對製品管理的要求不高，按照以上方式基本可以滿足需求。但是，如果建設公司級別的需要規範一些命名，如下所示
製品版本號規範化
製品的版本號用於標記特定製品，通過規範化命名有助於自動化指令碼的編寫和流水線的複用。
製品庫許可權規範化
不管是基於開源工具，還是自研工具，基於製品倉庫的許可權設計也是必要的，做到團隊產品的隔離。
開源製品的安全風險
對於製品的管理，大多人數都停留在僅僅是儲存，拉取使用的想法，筆者今年前也是這種思維。2021年末的Log4j2的安全事件，引起了整個IT圈的軒然大波，這個開源元件幾乎涉及所有的java應用，每個公司不得不緊急排查自己產品是否引入該風險。
通過該事件，讓我們開始關注開源元件可能存在的風險，這也是目前比較熱門的研發過程中的“供應鏈安全”，也是DevSecOps其中重要的一個環節。
作為研發過程中的製品管理，引入階段的稽核機制，使用中的安全，越來越成為大家關注的熱點。如果所示，組織需要引入元件稽核制度，杜絕開發人員隨意的拉取網際網路的開源製品，並且建立實時的漏洞掃描機制，形成組織級的白名單倉庫。
SBOM-軟體物料清單
現代軟體主要是使用第三方和開源元件組裝而成的，它們以複雜而獨特的方式融合在一起，並與原始程式碼整合以實現所需的功能。除了通過在開源元件引入階段加入安全稽核機制，IT企業往往也需要關注自己開發或使用的軟體產品的組成，像我們在超市購買食品時在食品包裝上看到的食品配料清單，標註了所用的所有材料。
為了準確摸清軟體所含元件的情況，SBOM（即：Software Bill Of Materials）應運而生，其包括多種關鍵資訊，如：元件名稱、版本號、供應商等，這些關鍵資訊在分析軟體安全時發揮著關鍵作用。通過這些資訊，可以追溯軟體的原始供應鏈，極大提高開發者對其所用軟體安全風險的理解，幫助企業在網路安全風險分析、漏洞管理和應急響應過程中提高效率。
對軟體開發企業而言，SBOM可有效控制開源元件風險，幫助企業更早識別並消除開源元件安全缺陷和許可風險；對軟體採購企業而言，SBOM可幫助採購決策者輕鬆瞭解開發方軟體是否存在開源元件風險；對軟體開發人員而言，SBOM可幫助開發人員全面準確掌握其所研發軟體的開源元件情況。
總結
- 製品管理是DevOps實踐過程中的重要環節，起著承上啟下，收集過程資訊的重要角色；
- 於此同時，製品的引入使用會存在安全風險，組織需要關注這一點，避免類似Log4j2安全事件帶來的一系列風險；
- 作為實踐者，在製品的管理上需要結合組織和流水線需要，指定相應的規範，避免混亂；
- 好的製品管理流程，可減少開發自測和測試人員進行接收測試銜接過程中的低效溝通；
這裡僅僅是對製品管理做了全域性的梳理，後續會對其中具體的知識點進行詳細介紹。