Was ist Azure Artifacts?
Dieser Einheit bietet einen kurzen Überblick darüber, wie Sie Azure Artifacts verwenden können, um für Ihre Apps nutzbare Pakete sicher zu erstellen und zu verwalten.
Sehen wir uns an, wie das Team entscheidet, ob Azure Artifacts die richtige Methode zum Hosten des .NET-Pakets ist.
Mara: Ich finde es sinnvoll, wenn wir das neue Modellpaket in Azure Artifacts hosten. Wir sind bereits alle Teil der Microsoft Azure DevOps-Organisation, daher wäre die Authentifizierung einfacher, als zu versuchen, sie für einen anderen Paket-Manager einzurichten.
Andy: Ich habe mir das vor der Besprechung angeschaut und es scheint mir einfach zu sein. Ich stimme Mara zu.
Amita: Was ist Azure Artifacts?
Andy: Azure Artifacts ist ein Repository in Ihrer Azure DevOps-Organisation, in dem Sie die Abhängigkeiten für Ihre Codebasis verwalten können. Azure Artifacts kann Ihre Artefakte und Ihre Binärdateien speichern. Es bietet einen als Feed bezeichneten Container für Gruppen von Abhängigkeiten. Entwickler, die Zugriff auf den Feed haben, können Pakete einfach nutzen oder veröffentlichen.
Wie kann ich ein Paket erstellen und in der Pipeline verwenden?
Tim: Wenn ich also richtig verstehe, verwendet der App-Code bereits Pakete aus NuGet. Wir werden unser eigenes Paket erstellen und es in Azure Artifacts hosten. Können Sie die Teile und ihre Zusammenarbeit erläutern? Es fällt mir schwer, mir den ganzen Prozess vorzustellen.
Andy: Sicher. Lassen Sie uns den Prozess der Erstellung eines Pakets und dessen Verwendung in unserer Azure DevOps-Pipeline durchgehen.
Andy geht zum Whiteboard.
Erstellen des Pakets
Zunächst müssen wir ein Projekt in Azure Artifacts erstellen. 
Dazu können wir Azure DevOps verwenden.
Dann erstellen wir eine Pipeline in Azure Pipelines, die sich mit dem GitHub-Repository für den Paketcode verbindet. Dann erstellt die Pipeline den Code, packt ihn und pusht das Paket an Azure Artifacts. 
Wir müssen die App, die dieses Paket nutzt, aktualisieren, damit sie auf den von uns erstellten Azure Artifacts-Feed verweist. 
Danach aktualisieren wir die Pipeline, die unsere App erstellt. Mit dem Update können wir unseren Azure Artifacts-Feed verwenden, um die neue Paketabhängigkeit zu pullen und die Erstellung wie gewohnt durchzuführen. 
Aktualisieren des Pakets
Tim: Was geschieht, wenn jemand das Paket aktualisiert?
Andy: Wenn Sie das Paket mit einem neuen Feature oder einer Fehlerbehebung aktualisieren und Tests durchführen, um sicherzustellen, dass es ordnungsgemäß funktioniert, erhöhen Sie die Versionsnummer des Pakets. Führen Sie dann einen Commit für die Änderung aus. Die Paketpipeline erkennt den Commit und erstellt in Azure Artifacts ein neues Artefakt mit der neuen Versionsnummer. Keine Sorge, das alte Paket mit der niedrigeren Versionsnummer ist für Apps, die von dieser Version abhängig sind, weiterhin vorhanden. Aus diesem Grund heben Sie die Listeneintrag eines Pakets in der Regel nicht auf.
Unsere App könnte diese neuere Version des Pakets verwenden wollen. In diesem Fall aktualisieren wir die App so, dass auf die neuere Version verwiesen wird, und führen die Tests lokal aus, um sicherzustellen, dass diese neue Version mit unserer App funktioniert. Wenn wir zufrieden sind, dass alles funktioniert, übermitteln wir die App-Änderung an die Pipeline. Die App wird mit der neuen Version der Paketabhängigkeit erstellt.
Amita: Das klingt nach einem guten Plan, und es wird auch dem anderen Team helfen. Außerdem wird ein Drift beim Code vermieden. Das hilft auch bei der Qualitätssicherung.
Einbeziehen einer Strategie für die Versionsverwaltung in die Buildpipeline
Wenn Sie eine Buildpipeline verwenden, benötigen Pakete Versionen, bevor sie verwendet und getestet werden können. Aber erst wenn Sie das Paket getestet haben, können Sie seine Qualität erkennen. Da Paketversionen nie geändert werden sollten, wird es schwierig, eine bestimmte Version im Voraus zu wählen.
Azure Artifacts ordnet jedem Paket in seinen Feeds eine Qualitätsstufe zu und unterscheidet zwischen Vorabversion und Releaseversionen. Azure Artifacts bietet verschiedene Ansichten auf die Liste der Pakete und ihrer Versionen, die diese nach ihrer Qualitätsstufe trennen. Dieser Ansatz eignet sich gut bei der semantischen Versionierung, die nützlich ist, um die Absicht einer bestimmten Version vorherzusagen. Azure Artifacts verwendet auch einen Deskriptor, um zusätzliche Metadaten aus dem Azure Artifacts-Feed einzubeziehen. Ansichten werden häufig verwendet, um Paketversionen freizugeben, die getestet, überprüft oder bereitgestellt wurden, und gleichzeitig Pakete zurückzuhalten, die sich noch in der Entwicklung befinden und noch nicht für die Öffentlichkeit bereit sind.
Feeds in Azure Artifacts haben standardmäßig drei verschiedene Ansichten. Diese Ansichten werden in dem Moment hinzugefügt, in dem ein neuer Feed erstellt wird. Die drei Ansichten sind:
- Release: Die Ansicht @release enthält alle Pakete, die als offizielle Releases gelten.
- Vorabversion: Die Ansicht @prerelease enthält alle Pakete, die eine Bezeichnung in ihrer Versionsnummer aufweisen.
- Lokal: Die Ansicht @local enthält alle Release- und Vorabversionspakete sowie die aus Upstreamquellen heruntergeladenen Pakete.
Sie können Ansichten verwenden, um den Consumern eines Paketfeeds zu helfen, nach freigegebenen und nicht freigegebenen Versionen von Paketen zu filtern. Im Wesentlichen ermöglichen die Ansichten einem Consumer eine bewusste Entscheidung: Auswahl aus freigegebenen Paketen oder Abonnieren von Vorabversionen einer bestimmten Qualitätsstufe.
Paketsicherheit in Azure Artifacts
Die Gewährleistung der Sicherheit Ihrer Pakete ist genauso wichtig wie die Gewährleistung der Sicherheit des restlichen Codes. Ein Aspekt der Paketsicherheit ist die Sicherung des Zugriffs auf die Paketfeeds (ein Feed ist in Azure Artifacts der Ort, an dem Sie Pakete speichern). Durch das Festlegen von Berechtigungen für den Feed können Sie Ihre Pakete für so viele oder wenige Personen freigeben, wie es Ihr Szenario erfordert.
Feedberechtigungen
Feeds weisen vier Zugriffsebenen auf: Besitzer, Mitwirkender, Mitarbeiter und Leser. Jede Zugriffsebene verfügt über einen bestimmten Satz von Berechtigungen. Besitzer*innen können z. B. jede Art von Identität – Einzelpersonen, Teams und Gruppen – zu jeder Zugriffsebene hinzufügen. Standardmäßig hat der Builddienst für die Projektsammlung die Rolle „Projektmitarbeiter“, und Ihr Projektteam hat die Rolle „Leser“.
Konfigurieren der Pipeline für den Zugriff auf Sicherheits- und Lizenzbewertungen
Es gibt verschiedene Tools von Drittanbietern, die Ihnen helfen, die Sicherheits- und Lizenzbewertung der von Ihnen verwendeten Softwarepakete zu beurteilen.
Einige dieser Tools überprüfen die Pakete, wenn sie in die Build- oder CD-Pipeline einbezogen werden. Während des Buildprozesses prüft das Tool die Pakete und gibt sofort ein Feedback zurück. Während des CD-Prozesses verwendet das Tool die Buildartefakte und führt Überprüfungen durch. Zwei Beispiele für solche Tools sind Mend Bolt und Black Duck. Mit Azure DevOps verwenden Sie Buildtasks, um Überprüfungen in Ihre Pipeline einzubinden.