Fedora i CentOS obsługują Git Forge. GitLab otwiera 18 zastrzeżonych możliwości

Projekty CentOS и Fedora сообщили o decyzji o stworzeniu usługi współpracy programistycznej Git Forge, która zostanie zbudowana przy użyciu platformy GitLab. GitLab stanie się główną platformą do interakcji z repozytoriami Git i do hostowania projektów związanych z dystrybucjami CentOS i Fedora. Poprzednio używana usługa Pagura będzie nadal istnieć, ale zostanie przekazane pod opiekę społeczności zainteresowanej dalszym rozwojem. Pagure zostanie usunięty ze wsparcia zespołu CPE (Community Platform Engineering) zatrudnionego w Red Hat, który zajmuje się utrzymaniem infrastruktury do rozwoju i publikacji wydań Fedory i CentOS.

Oceniając możliwe rozwiązania dla nowego Git Forge, wzięliśmy pod uwagę
Pagure i Gitlab. Na podstawie badania ok Recenzje 300 i życzenia uczestników projektów Fedora, CentOS, RHEL i CPE, sformułowano wymagania funkcjonalne i dokonano wyboru na korzyść Gitlab. Oprócz standardowych operacji na repozytoriach (łączenie, tworzenie forków, dodawanie kodu itp.), wśród kluczowych wymagań wymieniono bezpieczeństwo, łatwość obsługi i stabilność platformy.

Wymagania obejmowały takie funkcje jak wysyłanie żądań push po HTTPS, możliwości ograniczania dostępu do oddziałów, obsługa oddziałów prywatnych, separacja dostępu dla użytkowników zewnętrznych i wewnętrznych (np. praca nad eliminacją podatności w czasie embarga na ujawnianie informacji o problemie) , interfejs znajomości, ujednolicenie podsystemów do pracy z raportami problemów, kodem, dokumentacją i planowaniem nowych funkcji, dostępność narzędzi do integracji z IDE, wsparcie dla standardowych przepływów pracy.

Spośród możliwości GitLaba, które ostatecznie wpłynęły na decyzję o wyborze tej platformy, wymieniono obsługę podgrup z selektywnym dostępem do repozytoriów, możliwość wykorzystania bota do automatycznego scalania (do obsługi pakietów z jądrem wymagany jest CentOS Stream), obecność wbudowanych narzędzi do planowania rozwoju, możliwość korzystania z gotowej usługi SAAS z gwarantowanym poziomem dostępności (zwolni zasoby na utrzymanie infrastruktury serwerowej).

Decyzja już jest spowodowany krytyka wśród deweloperów ze względu na fakt, że decyzja została podjęta bez szerszej dyskusji wstępnej. Pojawiły się również obawy, że usługa nie będzie korzystać z bezpłatnej wersji GitLab w ramach społeczności. W szczególności możliwości niezbędne do realizacji opisanych w ogłoszeniu wymagań dla Git Forge dostępne są wyłącznie w wersji autorskiej Ostateczny GitLab.

Krytykowano także zamiar wykorzystania usługi SAAS (aplikacja jako usługa) dostarczanej przez GitLab, zamiast wdrażania GitLaba na swoich serwerach, co wymyka się spod kontroli nad usługą (np. nie można mieć pewności, że wszystkie podatności w zabezpieczeniach system jest niezwłocznie eliminowany, odpowiednio infrastruktura jest utrzymana, pewnego dnia jej nie będzie narzucona telemetria i sabotaż ze strony personelu obcej firmy jest wykluczony). Rozwiązanie również nie działa Podstawowe zasady Fedory, które precyzują, że w projekcie należy preferować bezpłatne rozwiązania alternatywne.

Tymczasem GitLab ogłosił o odkryciu implementacji 18 funkcjonalności oferowanych dotychczas wyłącznie w autorskich edycjach GitLaba. Możliwości obejmują różne obszary zarządzania pełnym cyklem tworzenia oprogramowania, w tym planowanie rozwoju, tworzenie projektów, weryfikację, zarządzanie pakietami, generowanie wersji, konfigurację i bezpieczeństwo.

Na wybieg przeniesiono następujące funkcje:

  • Załączam powiązany problem;
  • Eksportuj problem z GitLab do CSV;
  • Tryb planowania, organizowania i wizualizowania procesu rozwoju poszczególnych funkcjonalności lub wydań;
  • Wbudowana usługa umożliwiająca łączenie uczestników projektu z podmiotami trzecimi za pomocą poczty elektronicznej.
  • Terminal internetowy dla Web IDE;
  • Możliwość synchronizacji plików w celu testowania zmian w kodzie w terminalu internetowym;
  • Kontrole projektowania, które umożliwiają przesyłanie makiet i zasobów do wydania, wykorzystując wydanie jako pojedynczy punkt dostępu do wszystkiego, czego potrzebujesz do opracowania nowej funkcji;
  • Raporty dotyczące jakości kodu;
  • Wsparcie dla menedżerów pakietów Conan (C/C++), Maven (Java), NPM (node.js) i NuGet (.NET);
  • Wsparcie dla wdrożeń canary, umożliwiające zainstalowanie nowej wersji aplikacji na niewielkiej części systemów;
  • Dystrybucje przyrostowe, umożliwiające początkowo dostarczanie nowych wersji jedynie na niewielką liczbę systemów, stopniowo zwiększając zasięg do 100%;
  • Flagi aktywacji funkcjonalności, które umożliwiają dostarczenie projektu w różnych edycjach, dynamicznie aktywując określone funkcje;
  • Tryb przeglądu wdrożeń, który pozwala ocenić stan każdego środowiska ciągłej integracji opartego na Kubernetesie;
  • Obsługa definiowania wielu klastrów Kubernetes w konfiguratorze (na przykład możesz używać oddzielnych klastrów Kubernetes do próbnych wdrożeń i obciążeń);
  • Obsługa definiowania zasad bezpieczeństwa sieci kontenerowej, które pozwalają ograniczać dostęp między podami Kubernetes.

Dodatkowo można to zauważyć publikacja GitLab aktualizuje wersje 12.9.1, 12.8.8 i 12.7.8 (Community Edition i Enterprise Edition), które naprawiają lukę. Problem występuje od wydania GitLab EE/CE 8.5 i umożliwia odczytanie zawartości dowolnego pliku lokalnego podczas przenoszenia problemu między projektami.
Szczegóły dotyczące luki zostaną ujawnione po 30 dniach.

Źródło: opennet.ru

Dodaj komentarz