Projekty i o decyzji o stworzeniu usługi wspólnej pracy Git Forge, która zostanie zbudowana z wykorzystaniem platformy GitLab. GitLab będzie główną platformą do interakcji z repozytoriami Git oraz do hostingu projektów związanych z dystrybucjami CentOS i Fedora. Wcześniej stosowana usługa będzie nadal działać, ale zostanie przekazana pod opiekę społeczności zainteresowanej kontynuowaniem rozwoju. Pagure zostanie wyłączony z pod opieki zatrudnionego w Red Hat zespołu CPE (Community Platform Engineering), który zajmuje się utrzymywaniem infrastruktury do rozwoju i publikacji wydań Fedora i CentOS.
Podczas oceny możliwych rozwiązań dla nowego Git Forge rozważano
Pagure i GitLab. Na podstawie analizy około i życzeń uczestników projektów Fedora, CentOS, RHEL i CPE, sformułowano wymagania dotyczące funkcjonalności i wybrano GitLab. Oprócz typowych operacji na repozytoriach (łącznie, tworzenie forków, dodawanie kodu itp.) wśród kluczowych wymagań wymieniono bezpieczeństwo, łatwość użytkowania i stabilność platformy.
Wśród wymagań znalazły się takie funkcjonalności jak możliwość wysyłania push requestów przez HTTPS, środki ograniczające dostęp do gałęzi, wsparcie dla prywatnych gałęzi, rozdzielenie dostępu dla użytkowników zewnętrznych i wewnętrznych (np. w ramach pracy nad usuwaniem podatności podczas embarga na ujawnienie informacji o problemie), przyjazność interfejsu, unifikacja podsystemów do pracy z problemami, kodem, dokumentacją i planowaniem nowych możliwości, dostępność narzędzi do integracji z IDE oraz wsparcie dla typowych procesów roboczych.
Z możliwości GitLab, które ostatecznie wpłynęły na decyzję o wyborze tej platformy, wymieniono wsparcie dla podgrup z ograniczonym dostępem do repozytoriów, możliwość użycia bota do automatycznych złączy (wymagana CentOS Stream do utrzymania pakietów z jądrem), dostępność wbudowanych narzędzi do planowania rozwoju oraz możliwość korzystania z gotowego serwisu SAAS z gwarantowanym poziomem dostępności (co pozwoli uwolnić zasoby na utrzymanie infrastruktury serwerowej).
Decyzja już krytykę wśród deweloperów, związaną z tym, że decyzja została podjęta bez wcześniejszych szerokich konsultacji. Wyrażono także obawy, że usługa nie będzie korzystać z wolnej edycji Community GitLab. W szczególności możliwości niezbędne do realizacji opisanych w zapowiedzi wymagań dotyczących Git Forge są dostępne tylko w wersji zamkniętej. .
Krytyce poddano również zamiar skorzystania z oferowanej przez GitLab usługi SAAS (aplikacja jako usługa), zamiast wdrożenia GitLab na własnych serwerach, co może wyprowadzić usługę spod kontroli (na przykład, nie można być pewnym, że wszystkie luki w systemie są na bieżąco eliminowane, wsparcie infrastruktury, w pewnym momencie nie będzie i wykluczona dywersja ze strony pracowników zewnętrznych firm). Decyzja ta również nie jest zgodna z , które określają, że projekt powinien preferować wolne alternatywy.
Tymczasem firma GitLab ogłosiła realizację 18 funkcjonalności, które wcześniej były oferowane tylko w wersjach zamkniętych GitLab. Funkcje obejmują różne obszary zarządzania pełnym cyklem rozwoju oprogramowania, w tym planowanie rozwoju, tworzenie projektów, weryfikację, pracę z pakietami, tworzenie wydań, konfigurację i zabezpieczenia.
Wśród wolnych przekazane zostały następujące funkcje:
- Załączanie powiązanych zgłoszeń;
- Eksport zgłoszeń z GitLab do CSV;
- Tryb planowania, porządkowania i wizualizacji procesu rozwoju poszczególnych funkcjonalności lub wydań;
- Wbudowana usługa do łączenia uczestników projektu z osobami zewnętrznymi za pomocą e-maila.
- Web-terminal dla Web IDE;
- Możliwość synchronizacji plików w celu testowania zmian w kodzie w web-terminalu;
- Narzędzia do zarządzania projektem umożliwiające przesyłanie do zgłoszeń modeli i zasobów, używając zgłoszeń jako jedynego punktu dostępu do wszystkiego, co jest potrzebne do opracowania nowej funkcjonalności;
- Raporty o jakości kodu;
- Wsparcie menedżerów pakietów Conan (C/C++), Maven (Java), NPM (node.js) i NuGet (.NET);
- Wsparcie dla wdrożeń kanaryjnych, które umożliwiają wdrożenie nowej wersji aplikacji na niewielkiej części systemów;
- Incrementalne wdrożenia, które na początku dostarczają nowe wersje tylko dla niewielkiej liczby systemów, stopniowo zwiększając pokrycie do 100%;
- Flagi aktywacji funkcjonalności, które umożliwiają wydawanie projektu w różnych edycjach, dynamicznie aktywując określone możliwości;
- Tryb przeglądowy wdrożeń, umożliwiający ocenę stanu każdego środowiska ciągłej integracji opartego na Kubernetes;
- Wsparcie dla definiowania wielu klastrów Kubernetes w konfiguratorze (na przykład można używać oddzielnych klastrów Kubernetes do testowych wdrożeń i obciążeń roboczych);
- Wsparcie dla definiowania polityk bezpieczeństwa sieci kontenerów, które umożliwiają ograniczenie dostępu między podami Kubernetes.
Dodatkowo można zaznaczyć aktualizacje GitLab 12.9.1, 12.8.8 i 12.7.8 (Community Edition i Enterprise Edition), w których naprawiono lukę. Problem występuje od wersji GitLab EE/CE 8.5 i pozwala na odczytanie zawartości dowolnego lokalnego pliku podczas przenoszenia zgłoszeń między projektami.
Szczegóły dotyczące luki zostaną ujawnione za 30 dni.
Źródło: opennet.ru
