Projektek и a Git Forge együttműködésen alapuló fejlesztői szolgáltatás létrehozásáról szóló döntésről, amely a GitLab platformon fog épülni. A GitLab lesz az elsődleges platform a Git-tárhelyekkel való interakcióhoz és a disztribúciókkal kapcsolatos projektek tárolásához. CentOS és a Fedora. Korábban használt szolgáltatás továbbra is létezni fog, de átadják a folyamatos fejlesztésben érdekelt közösségnek. Pagure-t eltávolítják a Red Hat által alkalmazott CPE (Community Platform Engineering) csapatból, amely a Fedora kiadások fejlesztéséhez és közzétételéhez szükséges infrastruktúrát tartja fenn. CentOS.
Az új Git Forge lehetséges megoldásainak értékelésekor figyelembe vettük
Pagure és Gitlab. Egy tanulmány alapján kb és a Fedora projekt résztvevőinek jókívánságai, CentOS, az RHEL és a CPE esetében meghatározták a funkcionális követelményeket, és a Gitlab mellett döntöttek. A szabványos repository műveletek (egyesítés, elágazás, kód hozzáadása stb.) mellett a biztonság, a könnyű használhatóság és a platform stabilitása is a legfontosabb követelmények közé tartozott.
A követelmények között szerepeltek olyan szolgáltatások, mint a push kérések küldése HTTPS-en keresztül, a fiókokhoz való hozzáférés korlátozásának eszközei, a privát fiókok támogatása, a külső és belső felhasználók hozzáférésének elkülönítése (például a sebezhetőségek kiküszöbölése a problémával kapcsolatos információk közzétételére vonatkozó embargó idején). , ismeretterjesztő felület, alrendszerek egyesítése a problémajelentésekkel való munkavégzéshez, kód, új funkciók dokumentációja és tervezése, eszközök rendelkezésre állása az IDE-vel való integrációhoz, szabványos munkafolyamatok támogatása.
A GitLab azon funkciói közül, amelyek végül befolyásolták a platform kiválasztásának döntését, a következőket említették: a tárolókhoz szelektív hozzáféréssel rendelkező alcsoportok támogatása, a botok automatikus egyesítéshez való használatának lehetősége (szükséges hozzá CentOS Patak a kernelcsomagok karbantartásához), beépített eszközök megléte a fejlesztéstervezéshez, a kész SAAS szolgáltatás használatának lehetősége garantált rendelkezésre állási szinttel (felszabadítja az erőforrásokat a szerver infrastruktúra karbantartásához).
A döntés már megvan kritika a fejlesztők körében amiatt, hogy a döntés alapos előzetes vita nélkül született. Aggályok merültek fel azzal kapcsolatban is, hogy a szolgáltatás nem fogja használni a GitLab ingyenes közösségi kiadását. A közleményben leírt Git Forge követelményeinek megvalósításához szükséges képességek csak a védett verzióban érhetők el. .
Kritikát kapott az a szándék is, hogy a GitLab szerverein a GitLab telepítése helyett a SAAS (application as a service) szolgáltatást használják, ami kiveszi a szolgáltatást az irányítás alól (például nem lehet biztos abban, hogy minden biztonsági rést a rendszert azonnal megszüntetik, az infrastruktúra karbantartott, egyszer nem lesz és a harmadik fél cég személyzete által végzett szabotázs kizárt). A megoldás szintén nem működik , amelyek előírják, hogy a projektnek előnyben kell részesítenie az ingyenes alternatívákat.
Eközben a GitLab 18 olyan funkció megvalósításának felfedezéséről, amelyeket korábban csak a GitLab szabadalmaztatott kiadásaiban kínáltak. A képességek lefedik a teljes szoftverfejlesztési ciklus kezelésének különböző területeit, beleértve a fejlesztési tervezést, a projektkészítést, az ellenőrzést, a csomagkezelést, a kiadás generálást, a konfigurációt és a biztonságot.
A következő funkciók kerültek szabad tartományba:
- Kapcsolódó probléma csatolása;
- Probléma exportálása a GitLabból CSV-be;
- Az egyes funkciók vagy kiadások fejlesztési folyamatának tervezési, szervezési és megjelenítési módja;
- Beépített szolgáltatás a projekt résztvevőinek harmadik felekkel való összekapcsolásához e-mailben.
- Webterminál webes IDE-hez;
- Fájlok szinkronizálásának képessége a webterminál kódjában bekövetkezett változások teszteléséhez;
- Tervezési vezérlők, amelyek lehetővé teszik makettek és eszközök feltöltését a kiadáshoz, a kiadást egyetlen hozzáférési pontként használva mindenhez, amire egy új funkció fejlesztéséhez szükség van;
- Kódminőségi jelentések;
- A Conan (C/C++), Maven (Java), NPM (node.js) és NuGet (.NET) csomagkezelők támogatása;
- Canary telepítések támogatása, amely lehetővé teszi az alkalmazás új verziójának telepítését a rendszerek egy kis részére;
- Növekményes disztribúciók, amelyek lehetővé teszik az új verziók eleinte csak kis számú rendszerhez való eljuttatását, fokozatosan 100%-ra növelve a lefedettséget;
- Funkcionalitás aktiváló jelzők, amelyek lehetővé teszik a projekt különböző kiadásokban történő szállítását, bizonyos funkciók dinamikus aktiválását;
- Telepítési áttekintés mód, amely lehetővé teszi az egyes folyamatos integrációs környezetek állapotának felmérését a Kubernetes alapján;
- Több Kubernetes-fürt meghatározásának támogatása a konfigurátorban (például külön Kubernetes-fürtöket használhat próbamegvalósításokhoz és munkaterhelésekhez);
- Támogatás a konténerhálózati biztonsági házirendek meghatározásához, amelyek lehetővé teszik a Kubernetes podok közötti hozzáférés korlátozását.
Ezenkívül meg lehet jegyezni A GitLab 12.9.1, 12.8.8 és 12.7.8 (Community Edition és Enterprise Edition) frissítései, amelyek kijavítják a biztonsági rést. A probléma a GitLab EE/CE 8.5 kiadása óta fennáll, és lehetővé teszi bármely helyi fájl tartalmának olvasását, amikor egy problémát áthelyezünk a projektek között.
A sérülékenység részleteit 30 nap múlva hozzák nyilvánosságra.
Forrás: opennet.ru
