Passenderweise. So organisieren Sie die Steuerung von Paketen aus externen Repositorys und delegieren die Steuerung an Produktteams

Heutzutage arbeiten viele Unternehmen ohne die Möglichkeit, die Zusammensetzung externer Repositorys-Pakete direkt zu verwalten, selbst wenn sie Spiegelung, Proxy und Caching verwenden. Dies führt dazu, dass sich die Ausführungsumgebung ständig ändert, insbesondere ändert sich die Zusammensetzung der Docker-Images häufiger als es die Produktion erfordert.



Es gibt Situationen, in denen unerwünschte Änderungen in externen Abhängigkeiten in die Zusammensetzung des zu entwickelnden Produkts einfließen können. Dies gilt insbesondere während der Produktzertifizierung. Infolgedessen Verzögerungen bei der Zertifizierung, nächtliche Tests und Fehler bei Integrationstests, Ausfall der lokalen Produktion (eine Produktionsumgebung, die sich in den eigenen Ressourcen des Unternehmens befindet) beim Rolling eines Hotfixes usw. In einem neuen Artikel haben wir einen Ansatz beschrieben, um diese Probleme zu vermeiden.

Was wir erreichen wollten

Bevor wir mit der Beschreibung des Ansatzes fortfahren, einige Worte zu den Aufgaben, die wir lösen wollten:

• Erhalten Sie die volle Kontrolle über die Zusammensetzung externer Pakete in der Version (Vorhersagbarkeit).
• Korrigieren Sie die Zusammensetzung externer Repositorys für die schnelle Einführung von Hotfixes mit minimalem zusätzlichen Test (Geschwindigkeit).
• Stellen Sie Produkt-QS-Ständen eine wiederholbare, vorhersehbare, feste Umgebung zur Verfügung (Wiederholbarkeit).
• Unabhängigkeit vom Vorhandensein eines externen Kommunikationskanals (Autonomie).
• Sofortiges Umschalten auf offizielle Repositories im Fehlerfall (Fehlertoleranz).
• Garantierte Validierung von Schlüsseln für externe Repositorys in Assembly-Pipelines (Trust).
• Und vor allem übertragen Sie das Management und die Kontrolle über die Zusammensetzung externer Pakete in die Hände von Produktteams und Release-Managern (Selbstverwaltung).

Feature Build-Lebenszyklusanalyse

Unser Ansatz löst das Problem, die Zusammensetzung externer Repositorys für ein bestimmtes Datum, eine Veröffentlichung oder ein Feature festzulegen. Das folgende Diagramm zeigt die Verwaltung von Release, Feature Build und Hotfix-Lebenszyklus.



Nehmen wir als Beispiel das bedingte Debian Stretch-Repository. Dieser Ansatz gilt für Docker-, SaltStack- usw. Repositorys. Für die Daten T1, T2 und T3 wurden drei Slices auf der Zeitachse aufgezeichnet.







Wir haben den Inhalt des externen Debian Stretch-Repositorys für die Erstellung der Distributionen Feature1, Feature2 und Feature3 tabellarisch aufgeführt. Aus der Tabelle können Sie ersehen, dass die Zusammensetzung des externen Repositorys von jedem Zweig unabhängig gesteuert wird. Wir haben uns darauf geeinigt, die Hauptniederlassung für Debian Stretch täglich zu verpflichten und jedes Slice im Format JJJJMMTT zu kennzeichnen, z. B. 2020304 für das Slice vom 4. März 2020. In der Tabelle sind die Snapshots des externen Repositorys zusammengefasst, das für die Verteilung in jedem Zweig zu drei verschiedenen Zeitpunkten verwendet wird, sowie die Zusammensetzung im Assistenten für Debian Stretch. Das Team für jede Funktion oder für jede Version aktualisiert die Zusammensetzung der externen Repositorys nach eigenem Ermessen und entsprechend ihrem Entwicklungszyklus.



Beispiel 1: Das Produktteam beginnt mit der Entwicklung eines neuen Features und legt die Zusammensetzung des externen Repositorys ab 20200228 in den Konfigurationsdateien fest (siehe Abbildung oben).



Wechseln zu 20200228

deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free



Während der Entwicklung muss aufgrund des Auftretens neuer Pakete die Paketdatenbank auf das Datum 20200304 aktualisiert werden. Schalten Sie das Arbeitsrepository auf das gewünschte Datum um.



Wechseln zu 20200304

deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free



Als nächstes erfolgt ein weiterer Wechsel der Paketbasis am Datum 20200501. Wechseln



zu 20200501

deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free



Wenn wir jetzt Zeitscheiben zeichnen, werden wir sehen, dass die Entwicklung von Feature1 zu den Zeitpunkten T1 und T2 am 4. März 2020 auf der Paketbasis "eingefroren" ist. Und im T3-Schnitt wird bereits eine neue Paketbasis für den 1. Mai 2020 entwickelt.

Produkt-Multi-Release-Abhängigkeitsmanagement

Betrachten wir nun das Abhängigkeitsmanagement für mehrere aktive Produktversionen. Es gibt drei Versionen zur Unterstützung: 2.5, 2.6 und 2.7.



In der Tabelle sehen wir die Entsprechung von Releases und Daten, für die der Repository-Snapshot erstellt wurde. Es zeigt, welcher Snapshot der Zusammensetzung des externen Repositorys zum Erstellen einer bestimmten Version der Distribution verwendet wurde.







Anstatt Slices nach JJJJMMTT-Daten zu benennen, verwenden wir auch die Tag-Benennung im Format <ProjectName.ReleaseVersion> (release_name.release_version des Produkts, z. B. name.2.2) oder <ProjectName-FeatureNumber> (fügen Sie eine Feature-Nummer hinzu, z. B. 3).



Snapshot für 2.5 ab 20200301

deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301



Während der Entwicklung von Release 2.5 legt das Team daher die Zusammensetzung der abhängigen Repositorys ab 20200301 fest. Irgendwann im April startet das Team eine neue Version 2.6 und beschließt, die Zusammensetzung der externen Repository-Pakete ab 2.5 zu verwenden. Erstellen Sie einen neuen 2.6-Snapshot aus einem 2.5-Snapshot. In Zukunft könnten die Repositorys für die Versionen 2.5 und 2.6 leicht voneinander abweichen. Wir haben unser Debian-Stretch-Projektname-2.6-Tag für 2.6 erstellt.



Schnappschuss für 2.6 ab 20200301

deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301



In Version 2.7 kann das Team die Entwicklung vom Hauptzweig aus starten - eine tägliche Momentaufnahme des ursprünglichen Repositorys.



Schnappschuss für 2.7 ab 20200404

deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404

Abhängigkeitsmanagement für mehrere Produkte

Betrachten wir das Abhängigkeitsmanagement für mehrere Produkte am Beispiel von zwei Produkten mit unterschiedlichen Release-Zyklen und ihren eigenen Produktteams: Stealth und Infiniti.







Lassen Sie uns auf der Tabelle kommentieren, was wann passiert.



1. Lassen Sie die Entwicklung der Version 2.2 des Stealth-Projekts am 1. März 2020 beginnen. Hierzu wurde eine Momentaufnahme der Zusammensetzung der Paketdatenbank für das aktuelle Datum erstellt. Die Veröffentlichung von Version 2.2.124 erfolgt mit der Paketdatenbank des externen Repositorys ab 20200301.



Stealth 2.2

deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301



2. Am fünften Tag wird die Paketdatenbank aktualisiert. Das Debian-Stretch-Stealth-2.2-Arbeits-Repository wechselt sofort zum gewünschten Datum. Die Veröffentlichung der Releases 2.2.131 und 2.2.162 erfolgt mit den externen Repository-Paketen ab 20200305. Ohne zusätzliche Manipulationen in der Umgebung erhielten alle 100500 Microservices des Produkts sofort eine neue Umgebung in der Assembly-Pipeline 20200305 ...



Stealth 2.2

deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305



3. Parallel zum dritten Tag beginnt die Entwicklung des Infiniti Version 4.0-Projekts und es wird ein Teil der Repository-Zusammensetzung für das Datum 20200303 erstellt. Die Versionen 4.0.235 und 4.0.241 werden mit den externen Repository-Paketen für 20200303 veröffentlicht.



Infiniti 4.0

deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303



4. Nach der Veröffentlichung von Version 4.0.241 wird das Team beschließt, die Zusammensetzung des Repositorys auf 20200308 zu aktualisieren und eine neue Version mit einer neuen Zusammensetzung externer Pakete zu veröffentlichen. Version 4.0.250 wird mit Paketpaketen für 20200308 veröffentlicht.



Infiniti 4.0

deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308



Mit zwei Optionen zum Wechseln zwischen den Status der Repositorys können Sie einen Ansatz auswählen, der für den Entwicklungsprozess geeignet ist. Im ersten Fall wechseln wir in den gewünschten Status, indem wir einen Snapshot der Repositorys an einem bestimmten Datum angeben. Im zweiten Fall verwenden wir für Mehrkomponentenprodukte ein benanntes Slice und verschieben es an das gewünschte Datum. Dieser Mechanismus ermöglicht eine einmalige Abschaltung aller 100500 Produktkomponenten.



Wir verwalten die Slices jedes externen Repositorys in einem separaten Docker-Container, sodass wir bei bestimmten Unfällen jederzeit ein bestimmtes Repository zum Herunterladen aus dem externen Netzwerk wechseln können.



Laden Sie eine Liste aller Repositorys herunter

# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.list

Automatische Erstellung von Slices externer Repositorys

Die Repositorys werden jede Nacht gemäß dem GitLab-Scheduler aktualisiert. Wenn ein neues Repository hinzugefügt wird, werden die Änderungen automatisch auf den Server angewendet.







Zum Zeitpunkt des Festschreibens eines neuen Teils des externen Repositorys wird dessen Zertifikat überprüft. Wenn es von dem bei uns gespeicherten abweicht, findet die Aktualisierung nicht statt und wir erhalten eine Fehlermeldung.

Ergebnis

1. Das Vorbereiten einer neuen Version eines Distributionskits für die Zertifizierung bereitet keine Kopfschmerzen mehr. Während des Zertifizierungszeitraums legen wir die Zusammensetzung der Distribution fest. Wenn Sie umgehend etwas korrigieren müssen, treten mit hoher Wahrscheinlichkeit keine Fehler im freigegebenen Hotfix aufgrund von Änderungen in der Umgebung auf.
2. Alle Feature-Builds erhalten den verwalteten Status externer Repositorys.
3. Die Einführung von Hotfix und die Überprüfung der Qualitätssicherung werden mit einem vorhersehbaren, schnellen und erfolgreichen Ergebnis beschleunigt.
4. Feature- , .
5. .

Beachten Sie, dass Debian über eine offizielle Snapshot.debian.org- Ressource mit täglichen Snapshots und tiefen Speichertiefen verfügt. Dies ist für bestimmte Aufgaben ausreichend.



Vielen Dank an Sergey Smirnov und die Community für ein hervorragendes Tool zur Verwaltung der Zusammensetzung der externen Repositories von Aptly. Von uns - ein kleiner Beitrag zu den Best Practices für die Verwendung dieses nützlichen Werkzeugs in Produktionsförderern.



In den folgenden Artikeln werden wir über das Aptly + Simple-CDD-Bundle zur Erstellung von ISO-Images von Distributionen, zur Delegierung der Verwaltung externer Abhängigkeiten an Produktteams und über die Probleme bei der Verwendung von Aptly bei der Verwaltung externer Abhängigkeiten sprechen.



Autoren : Nikita Drachev , Alexander Pazdnikov , Timur Gilmullin