проекти и относно решението за създаване на услуга за съвместна разработка Git Forge, която ще бъде изградена с помощта на платформата GitLab. GitLab ще стане основната платформа за взаимодействие с Git хранилища и за хостване на проекти, свързани с CentOS и Fedora дистрибуции. Използвана преди това услуга ще продължи да съществува, но ще бъде предадено на грижите на общност, заинтересована от продължаващо развитие. Pagure ще бъде отстранен от поддръжката на екипа CPE (Community Platform Engineering), нает в Red Hat, който се занимава с поддържането на инфраструктурата за разработване и публикуване на изданията на Fedora и CentOS.
Когато оценявахме възможните решения за новия Git Forge, взехме предвид
Pagure и Gitlab. Въз основа на проучване на около и желанията на участниците в проектите Fedora, CentOS, RHEL и CPE бяха формирани изисквания за функционалност и изборът беше направен в полза на Gitlab. В допълнение към стандартните операции с хранилища (сливане, създаване на разклонения, добавяне на код и т.н.), сигурността, лекотата на използване и стабилността на платформата бяха посочени сред основните изисквания.
Изискванията включват функции като изпращане на насочени заявки през HTTPS, средства за ограничаване на достъпа до клонове, поддръжка за частни клонове, разделяне на достъпа за външни и вътрешни потребители (например за работа по премахване на уязвимости по време на ембарго върху разкриването на информация за проблема) , познавателен интерфейс, обединяване на подсистеми за работа с доклади за проблеми, код, документация и планиране на нови функции, наличие на инструменти за интеграция с IDE, поддръжка на стандартни работни процеси.
От възможностите на GitLab, които в крайна сметка повлияха на решението за избор на тази платформа, беше спомената поддръжката на подгрупи със селективен достъп до хранилища, възможността за използване на бот за автоматично сливане (CentOS Stream е необходим за поддържане на пакети с ядрото), наличие на вградени инструменти за планиране на разработката, възможност за използване на готова SAAS услуга с гарантирано ниво на достъпност (ще освободи ресурси за поддръжка на сървърната инфраструктура).
Решението е вече критики сред разработчиците поради факта, че решението е взето без задълбочено предварително обсъждане. Бяха изразени също опасения, че услугата няма да използва безплатното Comminity издание на GitLab. По-специално, възможностите, необходими за прилагане на изискванията за Git Forge, описани в съобщението, са налични само в собствената версия .
Намерението да се използва услугата SAAS (приложение като услуга), предоставена от GitLab, вместо да се разположи GitLab на неговите сървъри, също беше критикувано, което изважда услугата извън контрол (например невъзможно е да сте сигурни, че всички уязвимости в системата се елиминира незабавно, инфраструктура се поддържа, един ден няма да има и саботаж от страна на персонала на трета компания е изключен). Решението също не работи с , които уточняват, че проектът трябва да дава предимство на безплатни алтернативи.
Междувременно GitLab за откриването на имплементации на 18 функционалности, предлагани преди това само в патентовани издания на GitLab. Възможностите покриват различни области на управление на пълния цикъл на разработка на софтуер, включително планиране на разработката, създаване на проекти, проверка, управление на пакети, генериране на версии, конфигурация и сигурност.
Следните функции са прехвърлени на свободното отглеждане:
- Прикачване на свързан проблем;
- Проблем с експортиране от GitLab към CSV;
- Режим на планиране, организиране и визуализиране на процеса на разработка на отделни функционалности или версии;
- Вградена услуга за свързване на участниците в проекта с трети страни чрез имейл.
- Уеб терминал за Web IDE;
- Възможност за синхронизиране на файлове за тестване на промени в кода в уеб терминала;
- Дизайн контроли, които ви позволяват да качвате макети и активи за издаване, като използвате издаване като единна точка за достъп до всичко, от което се нуждаете, за да разработите нова функция;
- Доклади за качество на кода;
- Поддръжка за мениджъри на пакети Conan (C/C++), Maven (Java), NPM (node.js) и NuGet (.NET);
- Поддръжка за Canary внедрявания, което ви позволява да инсталирате нова версия на приложението на малка част от системите;
- Постепенни дистрибуции, позволяващи новите версии да бъдат доставени само на малък брой системи в началото, като постепенно се увеличава покритието до 100%;
- Флагове за активиране на функционалност, които правят възможно доставянето на проекта в различни издания, динамично активиране на определени функции;
- Режим за преглед на внедряването, който ви позволява да оцените състоянието на всяка среда за непрекъсната интеграция, базирана на Kubernetes;
- Поддръжка за дефиниране на множество Kubernetes клъстери в конфигуратора (например, можете да използвате отделни Kubernetes клъстери за пробни реализации и натоварвания);
- Поддръжка за дефиниране на политики за сигурност на контейнерна мрежа, които ви позволяват да ограничите достъпа между Kubernetes pods.
Освен това може да се отбележи GitLab актуализира 12.9.1, 12.8.8 и 12.7.8 (Community Edition и Enterprise Edition), които коригират уязвимостта. Проблемът присъства от пускането на GitLab EE/CE 8.5 и позволява съдържанието на всеки локален файл да бъде прочетено при преместване на проблем между проекти.
Подробности за уязвимостта ще бъдат разкрити след 30 дни.
Източник: opennet.ru