Projekty и о решении по созданию сервиса совместной разработки Git Forge, который будет построен с использованием платформы GitLab. GitLab станет первичной платформой для взаимодействия с Git-репозиториями и для хостинга проектов, связанных с дистрибутивами CentOS и Fedora. Ранее применяемый сервис продолжит существовать, но будет передан на попечение сообществу, заинтересованному в продолжении разработки. Pagure будет выведен из под сопровождения трудоустроенной в Red Hat команды CPE (Community Platform Engineering), занимающейся поддержанием инфраструктуры для разработки и публикации релизов Fedora и CentOS.
Oceniając możliwe rozwiązania dla nowego Git Forge, braliśmy pod uwagę:
Pagure i Gitlab. Na podstawie badania około и пожеланий от участников проектов Fedora, CentOS, RHEL и CPE, были сформированы требования к функциональности и сделан выбор в пользу Gitlab. Кроме типовых операций с репозиториями (слияние, создание форков, добавление кода и т.п.) среди ключевых требований были заявлены безопасность, удобство работы и стабильность платформы.
Wymagania obejmowały takie funkcje, jak HTTPS push, ograniczenie dostępu do gałęzi, obsługa gałęzi prywatnych, rozdzielenie dostępu użytkowników zewnętrznych i wewnętrznych (na przykład w celu pracy nad usuwaniem luk w zabezpieczeniach w okresie obowiązywania embarga na ujawnianie informacji o problemie), znajomość interfejsu, ujednolicenie podsystemów do pracy ze zgłoszeniami problemów, kodem, dokumentacją i planowaniem nowych funkcji, dostępność narzędzi do integracji IDE, obsługa typowych przepływów pracy.
Из возможностей GitLab, которые окончательно повлияли на принятие решения по выбору данной платформы, упомянуты поддержка подгрупп с выборочным доступом к репозиториям, возможность использования бота для автоматических слияний (требуется CentOS Stream для поддержании пакетов с ядром), наличие встроенных средств для планирования разработки, возможность использования готового SAAS-сервиса с гарантируемым уровнем доступности (позволит высвободить ресурсы на поддержание серверной инфраструктуры).
Decyzja już podjęta krytyka wśród deweloperów związana z faktem, że decyzja została podjęta bez wcześniejszej szerokiej dyskusji. Pojawiły się również obawy, że usługa nie będzie korzystać z bezpłatnej edycji Comminity GitLab. W szczególności możliwości niezbędne do wdrożenia wymagań dla Git Forge opisanych w ogłoszeniu są dostępne tylko w wersji zastrzeżonej .
Krytyce poddano również zamiar wykorzystania usługi SAAS (aplikacja jako usługa) świadczonej przez GitLab, zamiast wdrażania GitLab na własnych serwerach, co powoduje utratę kontroli nad usługą (na przykład nie można mieć pewności, że wszystkie luki w zabezpieczeniach systemu zostaną niezwłocznie naprawione, infrastruktura jest obsługiwana, w pewnym momencie nie będzie i sabotaż przez personel firmy trzeciej jest wykluczony). Rozwiązanie nie jest również kompatybilne z , które stanowią, że projekt powinien dawać pierwszeństwo bezpłatnym alternatywom.
Tymczasem GitLab o implementacjach open source 18 funkcjonalnych możliwości, które wcześniej były oferowane tylko w zastrzeżonych edycjach GitLab. Możliwości obejmują różne obszary zarządzania pełnym cyklem rozwoju oprogramowania, w tym planowanie rozwoju, tworzenie projektu, weryfikację, pracę z pakietami, tworzenie wydań, konfigurację i bezpieczeństwo.
Następujące funkcje zostały przeniesione do wersji darmowych:
- Dołączanie powiązanych kwestii;
- Eksportuj problem z GitLab do CSV;
- Sposób planowania, organizowania i wizualizacji procesu rozwoju poszczególnych funkcjonalności lub wydań;
- Wbudowana usługa umożliwiająca łączenie uczestników projektu z osobami trzecimi za pośrednictwem poczty e-mail.
- Terminal internetowy dla środowiska IDE;
- Możliwość synchronizacji plików w celu testowania zmian w kodzie w terminalu internetowym;
- Narzędzia do zarządzania projektami umożliwiające przesyłanie makiet i zasobów do zgłoszenia, wykorzystując je jako pojedynczy punkt dostępu do wszystkiego, co jest potrzebne do opracowania nowej funkcji;
- Raporty dotyczące jakości kodu;
- Obsługa menedżerów pakietów Conan (C/C++), Maven (Java), NPM (node.js) i NuGet (.NET);
- Obsługa wdrożeń typu „canary”, które umożliwiają instalację nowej wersji aplikacji na niewielkiej grupie systemów;
- Dystrybucje przyrostowe, które początkowo dostarczają nowe wersje tylko do niewielkiej liczby systemów, stopniowo zwiększając zasięg do 100%;
- Flagi aktywacji funkcjonalności, które umożliwiają dostarczanie projektu w różnych edycjach poprzez dynamiczną aktywację określonych funkcji;
- Tryb przeglądu wdrożeń umożliwiający ocenę kondycji każdego środowiska ciągłej integracji opartego na Kubernetes;
- Obsługa definiowania wielu klastrów Kubernetes w konfiguratorze (na przykład można używać oddzielnych klastrów Kubernetes na potrzeby wdrożeń próbnych i obciążeń produkcyjnych);
- Obsługa definiowania zasad bezpieczeństwa sieci kontenerów w celu ograniczenia dostępu między kontenerami Kubernetes.
Dodatkowo można to zauważyć Aktualizacje GitLab 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 w zabezpieczeniach zostaną ujawnione w ciągu 30 dni.
Źródło: opennet.ru
