Projekte und Es geht um die Entscheidung zur Schaffung eines gemeinsamen Entwicklungsdienstes namens Git Forge, der auf der Plattform GitLab basieren wird. GitLab wird die primäre Plattform für die Interaktion mit Git-Repositories und für das Hosting von Projekten, die mit den Distributionen CentOS und Fedora verbunden sind, sein. Der zuvor genutzte Dienst wird weiterhin bestehen, jedoch wird er in die Obhut einer Gemeinschaft übergeben, die an der Fortsetzung der Entwicklung interessiert ist. Pagure wird nicht mehr von dem angestellten Team CPE (Community Platform Engineering) bei Red Hat betreut, das für die Unterstützung der Infrastruktur für die Entwicklung und Veröffentlichung von Fedora- und CentOS-Releases verantwortlich ist.
Bei der Bewertung möglicher Lösungen für das neue Git Forge wurden
Pagure und GitLab in Betracht gezogen. Auf Basis von etwa und Wünschen von Teilnehmern der Projekte Fedora, CentOS, RHEL und CPE wurden die funktionalen Anforderungen definiert und die Entscheidung fiel zugunsten von GitLab. Neben den typischenOperationen mit Repositories (Merge, Fork-Erstellung, Code-Integration usw.) wurden Sicherheit, Benutzerfreundlichkeit und Stabilität der Plattform als Schlüsselkriterien festgelegt.
Zu den Anforderungen gehörten Funktionen wie das Senden von Push-Anfragen über HTTPS, Möglichkeiten zur Zugriffsbeschränkung auf Branches, die Unterstützung privater Branches, die Trennung des Zugangs für externe und interne Benutzer (zum Beispiel für die Arbeit an der Beseitigung von Schwachstellen während eines Embargos zur Offenlegung von Problemdetails), Benutzerfreundlichkeit der Schnittstelle, die Vereinheitlichung von Subsystemen zur Bearbeitung von Fehlermeldungen, Code, Dokumentation und Planung neuer Funktionen sowie Integrationsmöglichkeiten mit IDEs und die Unterstützung gängiger Arbeitsabläufe.
Zu den Funktionen von GitLab, die letztendlich die Entscheidung zur Auswahl dieser Plattform beeinflussten, zählen die Unterstützung von Untergruppen mit selektivem Zugriff auf Repositories, die Möglichkeit zur Nutzung eines Bots für automatische Zusammenführungen (CentOS Stream wird benötigt, um Pakete mit dem Kern zu unterstützen), die Verfügbarkeit integrierter Planungstools für die Entwicklung sowie die Möglichkeit, einen fertigen SAAS-Service mit garantierter Verfügbarkeit zu nutzen (dies wird Ressourcen für die Wartung der Serverinfrastruktur freisetzen).
Die Entscheidung steht bereits Kritik unter Entwicklern, da die Entscheidung ohne vorherige umfassende Diskussion getroffen wurde. Zudem wurden Bedenken geäußert, dass der Service nicht die freie Community-Edition von GitLab nutzen wird. Insbesondere sind die Funktionen, die für die Umsetzung der im Ankündigung genannten Anforderungen an Git Forge erforderlich sind, nur in der proprietären Version verfügbar. .
Kritisiert wurde ebenfalls die Absicht, den von GitLab angebotenen SAAS-Service (Software-as-a-Service) zu nutzen, anstatt GitLab auf eigenen Servern bereitzustellen, was den Service aus der Kontrolle nimmt (z. B. kann man sich nicht sicher sein, dass alle Sicherheitsanfälligkeiten im System zeitnah behoben werden) wird die Infrastruktur nicht mehr und eine Diversion durch Mitarbeiter eines Drittunternehmens ausgeschlossen). Die Entscheidung steht zudem im Widerspruch zu , die definieren, dass das Projekt freien Alternativen den Vorzug geben sollte.
In der Zwischenzeit hat das Unternehmen GitLab Die Einführung von 18 Funktionen, die zuvor nur in proprietären Versionen von GitLab angeboten wurden. Diese Funktionen decken verschiedene Bereiche des vollständigen Softwareentwicklungszyklus ab, einschließlich Entwicklungsplanung, Projektverwirklichung, Verifizierung, Paketverwaltung, Release-Management, Konfiguration und Sicherheit.
Die folgenden Funktionen wurden in die freie Version überführt:
- Verknüpfung relevanter Issues;
- Export von Issues aus GitLab in CSV;
- Modus zur Planung, Strukturierung und Visualisierung des Entwicklungsprozesses für einzelne Funktionen oder Releases;
- Integrierter Dienst zur Verbindung von Projektmitarbeitern mit externen Personen via E-Mail.
- Web-Terminal für die Web-IDE;
- Möglichkeit zur Dateisynchronisierung für das Testen von Änderungen im Code im Web-Terminal;
- Designmanagement-Tools, die das Hochladen von Mockups und Ressourcen in Issues ermöglichen, wobei Issues als zentraler Zugriffspunkt für alles dienen, was zur Entwicklung neuer Funktionen erforderlich ist;
- Codequalitätsberichte;
- Unterstützung für Paketmanager: Conan (C/C++), Maven (Java), NPM (node.js) und NuGet (.NET);
- Unterstützung für Canary-Deployments, die es ermöglichen, eine neue Version der Anwendung auf einem kleinen Teil der Systeme zu installieren;
- Inkrementelle Auslieferungen, die zunächst neue Versionen nur an eine begrenzte Anzahl von Systemen ausliefern, bevor der Umfang auf 100 % erhöht wird;
- Funktionsaktivierungsflags, die es ermöglichen, das Projekt in verschiedenen Editionen bereitzustellen, indem bestimmte Funktionen dynamisch aktiviert werden;
- Überwachungsmodus für Deployments, der die Bewertung des Zustands jeder Umgebung der kontinuierlichen Integration auf Basis von Kubernetes ermöglicht;
- Unterstützung für die Definition mehrerer Kubernetes-Cluster im Konfigurator (zum Beispiel kann man separate Kubernetes-Cluster für Testimplementierungen und Produktionslasten verwenden);
- Unterstützung für die Definition von Sicherheitsrichtlinien für Container-Netzwerke, die den Zugriff zwischen Kubernetes-Pods einschränken;
speziellen Distribution Updates von GitLab 12.9.1, 12.8.8 und 12.7.8 (Community Edition und Enterprise Edition), in denen eine Schwachstelle behoben wurde. Das Problem tritt ab der Version GitLab EE/CE 8.5 auf und ermöglicht den Zugriff auf den Inhalt beliebiger lokaler Dateien beim Verschieben von Issues zwischen Projekten.
Details zur Schwachstelle werden in 30 Tagen bekannt gegeben.
Quelle: opennet.ru
