【把玩Azure DevOps】Day11 Azure DevOps Artifacts简介

前面连续好几篇的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放上来吧！