前面連續好幾篇的Pipeline，是不是有點膩了呢？這一篇讓我們暫時來換換口味吧！

這裡的Artifacts指的是Project左邊選單中的Artifacts，和前幾篇Pipeline裡面所指的Artifacts並不相同，只是剛好英文名稱一樣而已。在Pipeline中的我把它稱為「成品庫」，在這裡所指的Artifacts我把它稱為「套件庫」。

第一次進入Artifacts長這個樣子：

從選單中可以看到有一個組織層級的Feed，這個是最先系統就已經先建立好的Feed，所有的Project進入到Artifacts都可以看到它：

既然有組織層級的Feed，相對應的應該也有Project層級的Feed，不過在這邊我們暫時不需要建立另外一個新的Project feed。

其實這個Feed就已經可以讓我們將自己的nuget package push上來，但是在那之前我們還是先把一些設定的地方看完吧！

在右上角的兩個圖示分別可以讓我們設定Project的Artifacts設定，以及Feed選單所選擇的Feed設定：

從Artifacts設定中可以看到預設是每一個組織中的成員都可以建立Artifact feed，包括Stakeholder的角色，這部份可以考慮修改一下設定：

相較於Artifact設定只有幾個，Feed的設定項目就比較多了：

上面這張是Feed基本設定，Name是預設建立時跟著組織的名稱，可以改成更適合的名字。比較需要提的設定是最下面的Retention policies的部份，因為Artifacts裡面所放的package是會計算檔案大小，Artifacts的儲存容量是需要計費的，免費的額度是2GB的空間(在Organization settings中的Billing可以看到)，超過這個容量就會被限制上傳，要解開限制就需要開啟付費選項，所以建議可以勾選Enable package retention啟用設定，系統預設每個package版本上限是20個(Maximum nuber of versions per package)，Days to keep recently downloaded packages則是30天。

接下來看一下Permissions的設定：

Permissions裡面加入的User或Group將決定是否能夠取得package的清單，也就是在VS中能不能看得到私有的套件列表，當然也決定誰可以把package推上來。這部份若是打算讓外部的合作夥伴(就是外包商啦)能夠從VS中安裝套件，也是在這裡把他們加入，這部份後續的文章會再提到。

接著是Views的部份：

這裡的Local指的是包含下面的Prerelease與Release，而Prerelease和Release的部份，如果有印象從VS搜尋package的時候，應該有個Include prerelease的選項可以勾選，有些套件會有還沒確定發行的版本必須勾選了之後才看得到(不知道的話就打開你的VS吧)。

最後是Upstream sources的部分：

其實這裡預設應該有四個，其中一個PyPI(pypi.org)的被我刪掉了，簡單來說就是上游來源，也就是我們建立的套件如果有使用到別的套件時，可以把它們複製一份放到我們的Feed倉庫中。是不是要包含這些Upstream的部份在建立Feed的時候是有選擇可以選擇的，而組織預建的Feed則是包含這些上游來源。

那為什麼要包含這些上游來源呢？

我前面也說了，Artifacts是會依照使用的容量計算的，所以到底要不要包含這些Upstream可以做一些決擇，其實把這些Upstream包含進來的考量主要應該是避免這些來源存取不到。什麼情況下會存取不到？

1. Upstream本身的服務掛了
2. 公司內限制外部存取

所以如果沒有第2點的限制，又不擔心第1點的話，那倒是可以不用加入Upstream sources(Upstream掛了就下班?)。

看完上面的內容之後，應該知道Azure DevOps的Artifacts是做什麼用的了吧？！沒有特別的需要的話，其實使用預設的Feed應該就夠了，Feed中不只可以存放nuget packages，從Upstream sources也可以看到其它的來源，代表不同的套件都可以放在同一個Feed。

下一篇，我們就來把自己的nuget package放上來吧！