Праекты и аб рашэнні па стварэнні сэрвісу сумеснай распрацоўкі Git Forge, які будзе пабудаваны з выкарыстаннем платформы GitLab. GitLab стане першаснай платформай для ўзаемадзеяння з Git-рэпазітарамі і для хостынгу праектаў, звязаных з дыстрыбутывамі CentOS і Fedora. Раней ужывальны сэрвіс працягне існаваць, але будзе перададзены на апеку супольнасці, зацікаўленай у працягу распрацоўкі. Pagure будзе выведзены з-пад суправаджэння працаўладкаванай у Red Hat каманды CPE (Community Platform Engineering), якая займаецца падтрыманнем інфраструктуры для распрацоўкі і публікацыі рэлізаў Fedora і CentOS.
Пры адзнацы магчымых рашэнняў для новага Git Forge разглядаліся
Pagure і Gitlab. На падставе вывучэння каля і пажаданняў ад удзельнікаў праектаў Fedora, CentOS, RHEL і CPE, былі сфарміраваны патрабаванні да функцыянальнасці і зроблены выбар на карысць Gitlab. Акрамя тыпавых аперацый з рэпазітарамі (зліццё, стварэнне форкаў, даданне кода і да т.п.) сярод ключавых патрабаванняў былі заяўлены бяспека, зручнасць працы і стабільнасць платформы.
У лік патрабаванняў увайшлі такія магчымасці, як адпраўка push-запытаў па HTTPS, сродкі абмежавання доступу да галінак, падтрымка прыватных галінак, падзел доступу вонкавых і ўнутраных карыстачоў (напрыклад, для працы над ухіленнем уразлівасцяў падчас эмбарга на расчыненне звестак аб праблеме), звычнасць інтэрфейсу, уніфікацыя падсістэм для працы з паведамленнямі аб праблемах, кодам, дакументацыяй і планаваннем новых магчымасцяў, наяўнасць сродкаў для інтэграцыі з IDE, падтрымка тыпавых працоўных працэсаў.
З магчымасцяў GitLab, якія канчаткова паўплывалі на прыняцце рашэння па выбары дадзенай платформы, згаданыя падтрымка падгруп з выбарачным доступам да рэпазітароў, магчымасць выкарыстання робата для аўтаматычных зліццяў (патрабуецца CentOS Stream для падтрымання пакетаў з ядром), наяўнасць убудаваных сродкаў для планавання распрацоўкі, магчымасць гатовага SAAS-сэрвісу з гарантаваным узроўнем даступнасці (дазволіць вызваліць рэсурсы на падтрыманне сервернай інфраструктуры).
Рашэнне ўжо крытыку сярод распрацоўшчыкаў, звязаную з тым, што рашэнне было прынята без папярэдняга шырокага абмеркавання. Таксама былі выказаны апасенні, што сэрвіс не будзе выкарыстоўваць свабодную Comminity-рэдакцыю GitLab. У прыватнасці, магчымасці, неабходныя для рэалізацыі апісаных у анонсе патрабаванняў да Git Forge, даступныя толькі ў прапрыетарнай версіі. .
Крытыцы таксама падвергнуўся намер скарыстацца які прадстаўляецца кампаніяй GitLab сэрвісам SAAS (дадатак як сэрвіс), замест разгортвання GitLab на сваіх серверах, што выводзіць сэрвіс з-пад кантролю (напрыклад, немагчыма быць упэўненым, што ўсе ўразлівасці ў сістэме аператыўна ўхіляюцца, падтрымліваецца інфраструктура, аднойчы не будзе і выключана дыверсія з боку персанала іншай кампаніі). Рашэнне таксама не спалучаецца з , у якіх вызначана, што праект павінен аддаваць перавагі свабодным альтэрнатывам.
Тым часам, кампанія GitLab аб адкрыцці рэалізацый 18 функцыянальных магчымасцяў, якія раней прапаноўваліся толькі ў прапрыетарных рэдакцыях GitLab. Магчымасці ахопліваюць розныя вобласці кіравання поўным цыклам распрацоўкі ПЗ, уключаючы планаванне распрацоўкі, стварэнне праектаў, верыфікацыю, працу з пакетамі, фармаванне рэлізаў, наладу і абарону.
У лік свабодных пераведзены наступныя функцыі:
- Прымацаванне звязаных issue;
- Экспарт issue з GitLab у CSV;
- Рэжым планавання, парадкавання і візуалізацыі працэсу распрацоўкі асобных функцыянальных магчымасцяў або рэлізаў;
- Убудаваная сэрвісная служба для звязвання ўдзельнікаў праекту з іншымі асобамі пры дапамозе email.
- Web-тэрмінал для Web IDE;
- Магчымасць сінхранізацыі файлаў для тэставання змен у кодзе ў web-тэрмінале;
- Сродкі кіравання дызайнам, якія дазваляюць загружаць у issue макеты і рэсурсы, выкарыстоўваючы issue як адзіны пункт доступу да ўсяго, што патрабуецца для распрацоўкі новай магчымасці;
- Справаздачы аб якасці кода;
- Падтрымка пакетных мэнэджараў 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 і дазваляе прачытаць змесціва любога лакальнага файла пры перасоўванні issue паміж праектамі.
Дэталі аб уразлівасці будуць раскрыты праз 30 дзён.
Крыніца: opennet.ru