Fedora и CentOS стартират Git Forge. GitLab предлага 18 проприетарни възможности

Проекти CentOS и Fedora обявиха за решението за създаване на услуга за съвместна разработка Git Forge, която ще бъде изградена с платформа GitLab. GitLab ще стане основната платформа за взаимодействие с Git-репозиториите и за хостинг на проекти, свързани с дистрибуциите CentOS и Fedora. Предишно използваната услуга Pagure ще продължи да съществува, но ще бъде предоставена на обществеността, заинтересована в продължаването на разработката. Pagure ще бъде изваден от поддръжка от екипа на CPE (Community Platform Engineering), който е ангажиран с поддържане на инфраструктурата за разработка и публикуване на изданията на Fedora и CentOS.

При оценката на възможните решения за новия Git Forge бяха разгледани
Pagure и GitLab. На база на проучване на около 300 отзива и пожелания от участниците в проектите Fedora, CentOS, RHEL и CPE, бяха формулирани изискванията към функционалността и бе избран GitLab. Освен стандартните операции с репозитории (сливане, създаване на форкове, добавяне на код и т.н.) сред ключовите изисквания бяха заявени сигурността, удобството на работа и стабилността на платформата.

В изискванията бяха включени възможности като изпращане на push-заявки по HTTPS, средства за ограничаване на достъпа до клонове, поддръжка на частни клонове, разделение на достъпа за външни и вътрешни потребители (например, за работа по отстраняване на уязвимости по време на ембарго за разкриване на информация за проблема), интуитивен интерфейс, унификация на подсистемите за работа с проблеми, код, документация и планиране на нови функции, наличие на средства за интеграция с IDE и поддръжка на стандартни работни потоци.

От функциите на GitLab, които окончателно повлияха на вземането на решение за избор на тази платформа, бяха споменати поддръжката на подгрупи с изборен достъп до репозиториите, възможността за използване на бот за автоматични сливаня (необходимо е CentOS Stream за поддържане на пакети с ядрото), наличието на вградени средства за планиране на разработката и възможността за използване на готов SAAS-сервис с гарантирано ниво на наличност (ще освободи ресурси за поддържане на сървърната инфраструктура).

Решението вече предизвика критика сред разработчиците, свързана с това, че решението беше взето без предварително широко обсъждане. Също така бяха изразени опасения, че услугата няма да използва свободната версия на Community редакцията на GitLab. По-специално, възможностите, необходими за реализиране на изискванията, описани в анонса на Git Forge, са достъпни само в проприетарната версия. GitLab Ultimate.

Критиката беше насочена и към намерението да се използва предоставяния от GitLab SAAS (софтуер като услуга), вместо да се развива GitLab на собствените им сървъри, което извежда услугата извън контрол (например, не може да се бъде сигурен, че всички уязвимости в системата се отстраняват своевременно, по подходящ начин поддържа инфраструктура, в един прекрасен момент може да не бъде налагана телеметрия и да бъде изключена диверсията от страна на персонала на трета компания). Решението също не е в съответствие с основополагаещите принципи на Fedora, в които е определено, че проектът трябва да предпочита свободните алтернативи.

Междувременно, компанията GitLab обяви обяви реализацията на 18 функционалности, които преди бяха предлагани единствено в проприетарните редакции на GitLab. Функционалностите обхващат различни области на управление на целия цикъл на разработка на софтуер, включително планиране на разработка, създаване на проекти, верификация, работа с пакети, образуване на релизи, настройка и защита.

В списъка на освободените функции са:

• Прикачване на свързани проблеми;
• Експортиране на проблеми от GitLab в CSV;
• Режим на планиране, подреждане и визуализация на процеса на разработка на отделни функционалности или релизи;
• Вградена сервизна система за свързване на участниците в проекта със странични лица чрез имейл.
• Уеб термнал за Web IDE;
• Възможност за синхронизиране на файлове за тестване на изменения в кода в уеб терминала;
• Средства за управление на дизайна, позволяващи качването на макети и ресурси в проблемите, използвайки проблемите като точка на достъп до всичко, необходимо за разработката на нова функционалност;
• Отчети за качеството на кода;
• Поддръжка на пакетни мениджъри Conan (C/C++), Maven (Java), NPM (node.js) и NuGet (.NET);
• Поддръжка на канаречни разгръщания, позволяващи инсталирането на нова версия на приложението на малка част от системите;
• Инкрементални разпространения, които позволяват първоначално да бъдат предоставени нови версии само на малък брой системи, постепенно увеличавайки обхвата до 100%;
• Флагове за активиране на функционалността, които дават възможност за доставка на проекта в различни редакции, динамично активирайки определени възможности;
• Режим на преглед на разгръщанията, позволяващ оценка на състоянието на всяка среда за непрекъсната интеграция на базата на Kubernetes;
• Поддръжка за определяне на множество Kubernetes клъстери в конфигуратора (например, можете да използвате отделни Kubernetes клъстери за пробни внедрения и работни натоварвания);
• Поддръжка за определяне на политики за мрежова сигурност на контейнери, позволяващи разделяне на достъпа между подовете на Kubernetes.

Допълнително може да бъде отбелязано публикация обновления на GitLab 12.9.1, 12.8.8 и 12.7.8 (Community Edition и Enterprise Edition), в които е отстранена уязвимост. Проблемът се проявява от изданието GitLab EE/CE 8.5 и позволява прочитане на съдържанието на всеки локален файл при преместване на задача между проекти.
Детайли за уязвимостта ще бъдат разкрити в рамките на 30 дни.

Източник: opennet.ru