Fedora en CentOS loop Git Forge. GitLab maak 18 eie vermoëns oop

Projekte CentOS и Fedora сообщили oor die besluit om 'n samewerkende ontwikkelingsdiens Git Forge te skep, wat met die GitLab-platform gebou sal word. GitLab sal die primêre platform word vir interaksie met Git-bewaarplekke en vir die aanbieding van projekte wat verband hou met CentOS- en Fedora-verspreidings. Voorheen gebruik diens Bladsy sal voortbestaan, maar sal oorhandig word aan die sorg van 'n gemeenskap wat in voortgesette ontwikkeling belangstel. Pagure sal verwyder word van die ondersteuning van die CPE (Community Platform Engineering)-span in diens van Red Hat, wat besig is met die instandhouding van die infrastruktuur vir die ontwikkeling en publikasie van Fedora- en CentOS-vrystellings.

Toe ons moontlike oplossings vir die nuwe Git Forge evalueer, het ons dit oorweeg
Pagure en Gitlab. Gebaseer op 'n studie van ongeveer 300 resensies en wense van deelnemers aan die Fedora-, CentOS-, RHEL- en CPE-projekte, funksionaliteitsvereistes is gevorm en die keuse is ten gunste van Gitlab gemaak. Benewens standaardbedrywighede met bewaarplekke (samevoeging, skep vurke, byvoeging van kode, ens.), is sekuriteit, gebruiksgemak en stabiliteit van die platform onder die sleutelvereistes genoem.

Vereistes het kenmerke ingesluit soos die stuur van stootversoeke oor HTTPS, maniere om toegang tot takke te beperk, ondersteuning vir private takke, skeiding van toegang vir eksterne en interne gebruikers (byvoorbeeld om te werk aan die uitskakeling van kwesbaarhede tydens 'n embargo op die bekendmaking van inligting oor die probleem) , vertroudheidskoppelvlak, unifikasie van substelsels om met probleemverslae te werk, kode, dokumentasie en beplanning van nuwe kenmerke, beskikbaarheid van gereedskap vir integrasie met IDE, ondersteuning vir standaard werkvloeie.

Van die GitLab-vermoëns wat uiteindelik die besluit om hierdie platform te kies beïnvloed het, is melding gemaak van ondersteuning vir subgroepe met selektiewe toegang tot bewaarplekke, die vermoë om 'n bot te gebruik vir outomatiese samesmeltings (CentOS Stream word vereis om pakkette met die kern in stand te hou), die teenwoordigheid van ingeboude gereedskap vir die beplanning van ontwikkeling, die vermoë om 'n klaargemaakte SAAS-diens met 'n gewaarborgde vlak van beskikbaarheid te gebruik (sal hulpbronne vrystel vir die instandhouding van die bedienerinfrastruktuur).

Die besluit is reeds veroorsaak kritiek onder ontwikkelaars weens die feit dat die besluit geneem is sonder uitgebreide voorafbespreking. Kommer is ook geopper dat die diens nie die gratis Comminity-uitgawe van GitLab sal gebruik nie. In die besonder, die vermoëns wat nodig is om die vereistes vir Git Forge wat in die aankondiging beskryf word te implementeer, is slegs beskikbaar in die eie weergawe GitLab Ultimate.

Die voorneme om die SAAS (toepassing as 'n diens) diens wat deur GitLab verskaf word te gebruik, in plaas daarvan om GitLab op sy bedieners te ontplooi, is ook gekritiseer, wat die diens buite beheer neem (dit is byvoorbeeld onmoontlik om seker te wees dat alle kwesbaarhede in die stelsel word onmiddellik uitgeskakel, behoorlik infrastruktuur in stand gehou word, sal daar eendag geen telemetrie opgelê en sabotasie deur die personeel van 'n derdepartymaatskappy is uitgesluit). Die oplossing werk ook nie met Fedora se stigtingsbeginsels, wat spesifiseer dat die projek voorkeur moet gee aan gratis alternatiewe.

Intussen, GitLab aangekondig oor die ontdekking van implementerings van 18 funksies wat voorheen slegs in eie uitgawes van GitLab aangebied is. Vermoë dek verskeie areas van die bestuur van die volle sagteware-ontwikkelingsiklus, insluitend ontwikkelingsbeplanning, projekskepping, verifikasie, pakketbestuur, vrystellinggenerering, konfigurasie en sekuriteit.

Die volgende funksies is na die vrye reeks oorgedra:

  • Aanheg van verwante kwessie;
  • Voer kwessie uit GitLab na CSV;
  • 'n wyse van beplanning, organisering en visualisering van die ontwikkelingsproses van individuele funksionaliteit of vrystellings;
  • Ingeboude diens om projekdeelnemers met derde partye te verbind deur e-pos te gebruik.
  • Webterminal vir Web IDE;
  • Vermoë om lêers te sinchroniseer om veranderinge in kode in die webterminal te toets;
  • Ontwerpkontroles wat jou toelaat om mockups en bates op te laai om uit te reik, deur kwessie te gebruik as 'n enkele toegangspunt tot alles wat jy nodig het om 'n nuwe kenmerk te ontwikkel;
  • Kode kwaliteit verslae;
  • Ondersteuning vir pakketbestuurders Conan (C/C++), Maven (Java), NPM (node.js) en NuGet (.NET);
  • Ondersteuning vir kanarie-ontplooiings, sodat jy 'n nuwe weergawe van die toepassing op 'n klein deel van die stelsels kan installeer;
  • Inkrementele verspreidings, wat toelaat dat nuwe weergawes eers aan slegs 'n klein aantal stelsels gelewer word, wat die dekking geleidelik tot 100% verhoog;
  • Funksionaliteit aktiveringsvlae, wat dit moontlik maak om die projek in verskeie uitgawes te lewer, wat sekere kenmerke dinamies aktiveer;
  • Ontplooiingsoorsigmodus, wat jou toelaat om die toestand van elke deurlopende integrasie-omgewing op grond van Kubernetes te assesseer;
  • Ondersteuning vir die definisie van veelvuldige Kubernetes-klusters in die konfigurator (jy kan byvoorbeeld aparte Kubernetes-klusters gebruik vir proefimplementerings en werkladings);
  • Ondersteuning vir die definisie van houernetwerksekuriteitsbeleide wat jou toelaat om toegang tussen Kubernetes-peule te beperk.

Daarbenewens kan dit opgemerk word publikasie GitLab werk 12.9.1, 12.8.8 en 12.7.8 (Community Edition en Enterprise Edition) op, wat die kwesbaarheid regstel. Die probleem is teenwoordig sedert die vrystelling van GitLab EE/CE 8.5 en laat die inhoud van enige plaaslike lêer toe om gelees te word wanneer 'n probleem tussen projekte geskuif word.
Besonderhede oor die kwesbaarheid sal na 30 dae bekend gemaak word.

Bron: opennet.ru

Voeg 'n opmerking