Projekte und über die Entscheidung zur Schaffung des kollaborativen Entwicklungsdienstes Git Forge, der auf der GitLab-Plattform 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. Der zuvor genutzte Dienst wird weiterhin bestehen bleiben, jedoch in die Obhut der Community übergeben, die an der Weiterentwicklung interessiert ist. Pagure wird aus der Betreuung durch das bei Red Hat angestellte CPE-Team (Community Platform Engineering), das für die Wartung der Infrastruktur für die Entwicklung und Veröffentlichung von Fedora- und CentOS-Versionen verantwortlich ist, entlassen.
Bei der Bewertung möglicher Lösungen für das neue Git Forge wurden
Pagure und Gitlab. Basierend auf der Untersuchung von etwa und Wünschen von Mitgliedern der Projekte Fedora, CentOS, RHEL und CPE wurden die Anforderungen an die Funktionalität formuliert und die Entscheidung zugunsten von Gitlab getroffen. Neben den typischen Operationen mit Repositories (Zusammenführungen, Erstellen von Forks, Code hinzufügen usw.) wurden Sicherheit, Benutzerfreundlichkeit und Stabilität der Plattform als zentrale Anforderungen genannt.
Zu den Anforderungen gehören Funktionen wie das Versenden von Push-Anfragen über HTTPS, Zugriffskontrollmittel für Branches, Unterstützung für private Branches, Trennung des Zugangs für externe und interne Nutzer (zum Beispiel zur Behebung von Schwachstellen während eines Embargos zur Offenlegung von Informationen über Probleme), Benutzerfreundlichkeit der Oberfläche, Vereinheitlichung der Subsysteme zur Bearbeitung von Problemen, Code, Dokumentation und Planungen neuer Funktionen sowie Integrationsmöglichkeiten mit IDEs und Unterstützung typischer Arbeitsabläufe.
Unter den Funktionen von GitLab, die letztendlich die Entscheidung für diese Plattform beeinflusst haben, sind die Unterstützung von Untergruppen mit selektivem Zugriff auf Repositories, die Verwendung eines Bots für automatische Zusammenführungen (CentOS Stream wird benötigt, um die Pakete mit dem Kernel zu unterstützen), integrierte Entwicklungsplanungstools sowie die Möglichkeit, einen fertigen SAAS-Dienst mit garantierter Verfügbarkeit zu nutzen (was die Ressourcen zur Wartung der Serverinfrastruktur entlastet).
Die Entscheidung hat bereits Kritik unter Entwicklern bezüglich der Entscheidung, die ohne vorherige umfassende Diskussion getroffen wurde. Es wurden auch Bedenken geäußert, dass der Service die freie Community-Edition von GitLab nicht verwenden wird. Insbesondere die Funktionen, die für die Umsetzung der im Ankündigungsdokument beschriebenen Anforderungen an Git Forge erforderlich sind, sind nur in der proprietären Version verfügbar. .
Kritik wurde auch an der Absicht geübt, den von GitLab bereitgestellten SAAS-Service (Software as a Service) zu nutzen, anstatt GitLab auf eigenen Servern bereitzustellen, was den Service außerhalb der Kontrolle bringt (zum Beispiel kann man sich nicht sicher sein, dass alle Sicherheitsanfälligkeiten im System schnell behoben werden). die Infrastruktur unterstützt, in einem schönen Moment nicht da sein wird. und Abweichungen von Mitarbeitern externer Unternehmen ausgeschlossen werden). Die Entscheidung steht auch im Widerspruch zu , in denen festgelegt ist, dass das Projekt freien Alternativen den Vorzug geben sollte.
In der Zwischenzeit hat GitLab die Einführung von 18 Funktionalitäten angekündigt, die zuvor nur in proprietären Editionen von GitLab angeboten wurden. Die Funktionen decken verschiedene Bereiche des vollständigen Lebenszyklusmanagements der Softwareentwicklung ab, einschließlich der Planung von Entwicklungen, Projektmanagement, Validierung, Paketverwaltung, Release-Generierung, Einstellung und Schutz.
Folgende Funktionen sind in die freie Version überführt worden:
- Verknüpfung verwandter Issues;
- Export von Issues aus GitLab nach CSV;
- Planungs-, Sortier- und Visualisierungsmodus des Entwicklungsprozesses einzelner Funktionen oder Releases;
- Integrierte Servicetools zur Verknüpfung von Projektteilnehmern mit externen Personen über E-Mail.
- Web-Terminal für die Web-IDE;
- Möglichkeit zur Synchronisierung von Dateien, um Änderungen im Code im Web-Terminal zu testen;
- Designverwaltungstools, die das Hochladen von Designs und Ressourcen in Issues ermöglichen, wobei Issues als zentraler Zugangspunkt für alles dienen, was für die Entwicklung neuer Funktionen benötigt wird;
- Berichte zur Codequalität;
- Unterstützung von Paketmanagern wie Conan (C/C++), Maven (Java), NPM (Node.js) und NuGet (.NET);
- Unterstützung für Canary-Deployments, die das Bereitstellen einer neuen Version der Anwendung auf einem kleinen Teil der Systeme ermöglichen.
- Inkrementelle Verteilungen, die es ermöglichen, neue Versionen zunächst nur an eine kleine Anzahl von Systemen zu liefern und die Abdeckung schrittweise auf 100 % zu erhöhen;
- Aktivierungsflags für Funktionen, die es ermöglichen, das Projekt in verschiedenen Editionen bereitzustellen, indem bestimmte Funktionen dynamisch aktiviert werden;
- Überwachungsmodus für Bereitstellungen, der es ermöglicht, den Zustand jeder Umgebung der kontinuierlichen Integration auf Kubernetes-Basis zu bewerten;
- Unterstützung zur Definition mehrerer Kubernetes-Cluster im Konfigurator (zum Beispiel können separate Kubernetes-Cluster für Testimplementierungen und Produktionslasten verwendet werden);
- Unterstützung zur Definition von Netzwerk-Sicherheitsrichtlinien für Container, die den Zugriff zwischen Kubernetes-Pods einschränken;
Zusätzlich kann vermerkt werden 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 Veröffentlichung von GitLab EE/CE 8.5 auf und ermöglicht den Zugriff auf den Inhalt jeder lokalen Datei beim Verschieben von Issues zwischen Projekten.
Details zur Schwachstelle werden in 30 Tagen veröffentlicht.
Quelle: opennet.ru
