â utilita jonĂ« GitOps CLI me kod tĂ« hapur pĂ«r ndĂ«rtimin dhe dorĂ«zimin e aplikacioneve nĂ« Kubernetes. Siç e premtuam, shĂ«noi fillimin e shtimit tĂ« mundĂ«sive tĂ« reja nĂ« werf dhe rishikimin e qasjeve tĂ« zakonshme. Tani jemi tĂ« lumtur tĂ« paraqesim lĂ«shimin v1.1, i cili Ă«shtĂ« njĂ« hap i madh nĂ« zhvillim dhe njĂ« bazĂ« pĂ«r tĂ« ardhmen ndĂ«rtuesit werf. Versioni Ă«shtĂ« i disponueshĂ«m tani nĂ« .
Baza e lëshimit është arkitektura e re e ruajtjes së fazave dhe optimizimi i funksionimit të të dy ndërtuesve (për Stapel dhe Dockerfile). Arkitektura e re e ruajtjes hap mundësi për realizimin e ndërtimeve të shpërndara nga disa hoste dhe ndërtimeve paralele në një host.
Optimizimi i funksionimit përfshin heqjen e llogaritjeve të panevojshme në fazën e llogaritjes së nënshkrimeve të fazave dhe ndryshimin e mekanizmave të llogaritjes së shenjave të skedarëve në më efikaset. Kjo optimizim zvogëlon kohën mesatare të ndërtimeve të projektit përmes werf. Ndërsa ndërtimet e plota, kur të gjitha fazat ekzistojnë në cache stages-storage, tani janë me të vërtetë të shpejta. Në shumicën e rasteve, rihapja e ndërtimit do të kalojë më shpejt se për 1 sekondë! Kjo vlen gjithashtu për procedurat e verifikimit të fazave gjatë punës së ekipeve werf deploy dhe werf run.
Gjithashtu, nĂ« kĂ«tĂ« lĂ«shim Ă«shtĂ« shtuar strategjia e etiketimit tĂ« imazheve bazuar nĂ« pĂ«rmbajtje â content-based tagging, e cila tani Ă«shtĂ« e aktivizuar si standard dhe Ă«shtĂ« e rekomanduar e vetme.
Le të shqyrtojmë më në detaje risitë kryesore në werf v1.1, dhe po ashtu do të flasim për planet për të ardhmen.
ĂfarĂ« Ă«shtĂ« ndryshuar nĂ« werf v1.1?
Forma e re e emërtimit të fazave dhe algoritmi i përzgjedhjes së fazave nga cache
Rregulli i ri për gjenerimin e emrit të fazës. Tani çdo ndërtim faze gjeneron një emër unik për fazën, i cili përbëhet nga 2 pjesë: nënshkrimi (siç ishte në v1.0) plus një identifikues unik temporal.
Për shembull, emri i plotë i imazhit të fazës mund të duket kështu:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
⊠ose në formën e përgjithshme:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
KĂ«tu:
-
NĂNSHKRIMIâ Ă«shtĂ« nĂ«nshkrimi i fazĂ«s, i cili pĂ«rfaqĂ«son identifikuesin e pĂ«rmbajtjes sĂ« fazĂ«s dhe varet nga historia e ndryshimeve nĂ« Git, e cila çoi nĂ« kĂ«tĂ« pĂ«rmbajtje; -
TIMESTAMP_MILLISECâ Ă«shtĂ« njĂ« identifikues garantuar unik i imazhit, i cili gjenerohet nĂ« momentin e ndĂ«rtimit tĂ« njĂ« imazhi tĂ« ri.
Algoritmi i përzgjedhjes së fazave nga cache bazohet në kontrollin e lidhshmërisë së komiteteve Git:
- Werf llogarit nënshkrimin e një faze.
- Në stages-storage mund të ekzistojnë disa faza me këtë nënshkrim. Werf zgjedh të gjitha fazat që përputhen me nënshkrimin.
- Nëse faza aktuale është e lidhur me Git (git-archive, fazë përdoruesi me patch-e Git:
install,beforeSetup,setup; ose git-latest-patch), atĂ«herĂ« werf zgjedh vetĂ«m ato faza qĂ« janĂ« tĂ« lidhura me njĂ« komitet qĂ« Ă«shtĂ« paraardhĂ«si i komitetit aktual (pĂ«r tĂ« cilin Ă«shtĂ« thirrur ndĂ«rtimi). - Nga fazat e mbetura tĂ« pĂ«rshtatshme, zgjidhet njĂ« â ajo mĂ« e vjetĂ«r sipas datĂ«s sĂ« krijimit.
Faza për degë të ndryshme Git mund të ketë të njëjtin nënshkrim. Por werf do të parandalojë përdorimin e cache-it të lidhur me degë të ndryshme, pavarësisht nga nënshkrimet.
.
Algoritmi i ri për krijimin dhe ruajtjen e fazave në ruajtjen e fazave
Nëse gjatë përzgjedhjes së fazave nga cache werf nuk gjen një fazë të përshtatshme, atëherë iniciatohet procesi i ndërtimit të një faze të re.
VĂ«rejmĂ« se disa procese (nĂ« njĂ« ose mĂ« shumĂ« hoste) mund tĂ« fillojnĂ« ndĂ«rtimin e tĂ« njĂ«jtĂ«s fazĂ« afĂ«rsisht nĂ« tĂ« njĂ«jtĂ«n kohĂ«. Werf pĂ«rdor algoritmin e bllokimit optimist stages-storage nĂ« momentin e ruajtjes sĂ« imazhit tĂ« sapo ndĂ«rtuar nĂ« stages-storage. Pra, kur ndĂ«rtimi i njĂ« faze tĂ« re Ă«shtĂ« gati, werf bllokon stages-storage dhe ruan atje imazhin e sapo ndĂ«rtuar vetĂ«m nĂ«se nuk ekziston njĂ« imazh i pĂ«rshtatshĂ«m (sipas nĂ«nshkrimit dhe parametrave tĂ« tjerĂ« â shih algoritmin e ri tĂ« pĂ«rzgjedhjes sĂ« fazave nga cache).
Imazhi i sapo ndërtuar do të ketë garantuar një identifikues unik sipas TIMESTAMP_MILLISEC (shih formatin e ri të emërtimit të fazave). Në rastin kur nëdo të gjendet një imazh i përshtatshëm, werf do të hedhë imazhin e sapo ndërtuar dhe do të përdorë imazhin nga cache. stages-storage Në fjalë të tjera: procesi i parë që përfundon ndërtimin e imazhit (më i shpejtë) do të ketë të drejtën ta ruajë atë në stages-storage (dhe më pas ky imazh i vetëm do të përdoret për të gjitha ndërtimet). Procesi më i ngadalshëm i ndërtimit nuk do të bllokojë asnjëherë procesin më të shpejtë nga ruajtja e rezultateve të ndërtimit të fazës aktuale dhe kalimi në ndërtimin e fazës tjetër.
Përmirësuar performancën e ndërtuesit Dockerfile
.
Aktualisht, konveji i fazave pĂ«r imazhin e ndĂ«rtuar nga Dockerfile pĂ«rbĂ«het nga njĂ« fazĂ« â
Aktualisht, konvejeri i fazave pĂ«r imazhin qĂ« po ndĂ«rtohet nga Dockerfile pĂ«rbĂ«het nga njĂ« fazĂ« vetĂ«m â dockerfile. GjatĂ« llogaritjes sĂ« nĂ«nshkrimit llogaritet somat e skedarĂ«ve context, qĂ« do tĂ« pĂ«rdoren gjatĂ« ndĂ«rtimit. Para kĂ«tij pĂ«rmirĂ«simi, werf kalonte recursiv nĂ« tĂ« gjithĂ« skedarĂ«t dhe merrte sumĂ«n kontrolluese, duke pĂ«rmbledhur kontekstin dhe modin e çdo skedari. Duke filluar nga versionet v1.1, werf mund tĂ« pĂ«rdorĂ« sumat kontrolluese tĂ« llogaritura, tĂ« ruajtura nĂ« depo Git.
Në thelb të algoritmit është . Algoritmi merr parasysh regjistrimet në .dockerignore dhe kalon recursiv në pemën e skedarëve vetëm kur është e nevojshme. Kështu, ne u shkëputëm nga leximi i sistemit të skedarëve, dhe varësia e algoritmit nga madhësia context nuk është e rëndësishme.
Gjithashtu, algoritmi kontrollon skedarët e pa ndjekur dhe i merr parasysh në sumën kontrolluese kur është e nevojshme.
Përmirësuar performancën gjatë importimit të skedarëve
Në versionet werf v1.1 përdoret një server rsync gjatë . Më parë, importimi bëhej në dy hapa duke përdorur montimin e drejtorisë nga sistemi host.
Performanca e importeve në macOS tani nuk është e kufizuar ndaj volumeve Docker, dhe importet kryhen për të njëjtën kohë si në Linux dhe Windows.
Etiketimi i bazuar në përmbajtje
Werf v1.1 mbĂ«shtet atĂ« qĂ« quhet etiketimi i bazuar nĂ« pĂ«rmbajtjen e imazhit â content-based tagging. Etiketat e imazheve tĂ« rezultuara Docker varen nga pĂ«rmbajtja e kĂ«tyre imazheve.
Kur ekzekutohet komandĂ«n werf publish --tags-by-stages-signature ose werf ci-env --tagging-strategy=stages-signature do tĂ« etiketohen imazhet qĂ« publikohen me atĂ« qĂ« quhet nĂ«nshkrimi i fazave tĂ« imazhit. Ădo imazh etiketizohet me nĂ«nshkrimin e vet tĂ« fazave tĂ« kĂ«tij imazhi, i cili llogaritet sipas rregullave tĂ« njĂ«jta si nĂ«nshkrimi regulativ i secilĂ«s fazĂ« veçmas, por Ă«shtĂ« njĂ« identifikues pĂ«rmbledhĂ«s i imazhit.
Nënshkrimi i fazave të imazhit varet nga:
- përmbajtja e këtij imazhi;
- historiku i ndryshimeve në Git, i cili solli këtë përmbajtje.
Në depo Git gjithmonë ka komitete të jetra, të cilat nuk ndryshojnë përmbajtjen e skedarëve të imazhit. Për shembull, komitetet vetëm me komente ose komitetet e bashkimit, ose komitetet që ndryshojnë ato skedarë në Git, që nuk do të importohen në imazh.
Duke përdorur etiketimin e bazuar në përmbajtje, zgjidhen problemet e rifillimeve të panevojshme të pod-eve të aplikacionit në Kubernetes për shkak të ndryshimeve në emrin e imazhit, edhe nëse përmbajtja e imazhit nuk ka ndryshuar. Në fakt, kjo është një nga arsyet që pengojnë ruajtjen e shumë mikroshërbimeve të një aplikacioni në një depo të vetme Git.
Gjithashtu, etiketimi i bazuar në përmbajtje është një metodë më e besueshme e etiketimit, sesa etiketimi sipas degëve Git, sepse përmbajtja e imazheve të rezultuara nuk varet nga rendi i ekzekutimit të pipeline-ve në sistemin CI për ndërtimin e disa komiteteve të së njëjtës degë.
E rĂ«ndĂ«sishme: duke filluar nga ky moment stages-signature â kjo Ă«shtĂ« strategjia e vetme e rekomanduar e etiketimit. Ajo do tĂ« pĂ«rdoret si standard nĂ« komandĂ«n werf ci-env (nĂ«se nuk specifikohet qartĂ« njĂ« tjetĂ«r skemĂ« etiketimi).
. Kjo veçori do tĂ« ketĂ« gjithashtu njĂ« publikim tĂ« veçantĂ«. RIVLERĂSUAR (3 Prill): Artikulli me detaje .
Nivelet e regjistrimit
Përdoruesi ka mundësinë të kontrollojë daljen, të caktuar nivelin e regjistrimit dhe të punojë me informacionin e ndihmës. Janë shtuar opsionet --log-quiet, --log-verbose, --log-debug.
Për default, dalja përmban minimumin e informacionit:
Duke përdorur daljen e detajuar (--log-verbose) mund të ndjekësh se si funksionon werf:
Dalja e detajuar (--log-debug), përveç informacionit të ndihmës nga werf, gjithashtu përmban log-et e bibliotekave të përdorura. Për shembull, mund të shohësh se si ndodh ndërveprimi me Docker Registry, si dhe të regjistrosh vendet ku shpenzohet një sasi e konsiderueshme kohe:
Planet e ardhshme
Kujdes! MundĂ«sitĂ« e pĂ«rshkruara mĂ« poshtĂ« me shĂ«nimin v1.1 do tĂ« bĂ«hen tĂ« disponueshme qĂ« nĂ« kĂ«tĂ« version, shumica e tyre â gjatĂ« kĂ«saj periudhe. PĂ«rmirĂ«simet do tĂ« vijnĂ« pĂ«rmes azhurnimeve automatikisht . KĂ«to mundĂ«si nuk prekin pjesĂ«n stabile tĂ« funksioneve v1.1, dalja e tyre nuk do tĂ« kĂ«rkojĂ« ndĂ«rhyrje manuale nga pĂ«rdoruesi nĂ« konfigurimet ekzistuese.
Mbështetje e plotë për realizime të ndryshme të Docker Registry (E RE)
- Versioni: v1.1
- Afatet: mars
QĂ«llimi â pĂ«rdoruesi duhet tĂ« pĂ«rdorĂ« realizimin e rastit pa kufizime gjatĂ« pĂ«rdorimit tĂ« werf.
Aktualisht kemi identifikuar këtë grup zgjidhjesh, për të cilat pritet të garantohet mbështetje e plotë:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Me yll, shënohen zgjidhjet që aktualisht mbështeten plotësisht nga werf. Për të tjerët ka mbështetje, por me kufizime.
Mund të dallohen dy problemet kryesore:
- Disa zgjidhje nuk mbështesin fshirjen e etiketave duke përdorur API-në e Docker Registry, e cila nuk u lejon përdoruesve të përdorin pastrimin automatik, të implementuar në werf. Kjo është e vërtetë për AWS ECR, Docker Hub dhe GitHub Packages.
- Disa dhe zgjidhje të tjera nuk mbështesin, të ashtuquajturat, repository të nxitura (Docker Hub, GitHub Packages dhe Quay) ose mbështesin, por përdoruesi duhet t'i krijojë ato manualisht, duke përdorur UI ose API (AWS ECR).
Këto dhe çështje të tjera ne synojmë t'i zgjidhim duke përdorur API-të native të zgjidhjeve. Ky projekt përfshin gjithashtu mbulimin me teste të ciklit të plotë të funksionimit të werf për secilën prej tyre.
NdĂ«rtime tĂ« shpĂ«rndara tĂ« imazheve (â)
- Versioni: v1.2 v1.1 (prioriteti për zbatimin e këtij funksionaliteti është rritur)
- Kohët: mars-prill mars
Aktualisht, werf v1.0 dhe v1.1 mund të përdoren vetëm në një host të dedikuar për operacionet e ndërtimit dhe publikimit të imazheve dhe për deploy-in e aplikacionit në Kubernetes.
Për të hapur mundësitë e punës shpërndara të werf, kur ndërtimi dhe deploy-i i aplikacioneve në Kubernetes nisin në disa hoste të rastësishme dhe këto hoste nuk ruajnë gjendjen e tyre mes ndërtimesh (runner të përkohshëm), kërkohet që werf të implementojë mundësinë e përdorimit të Docker Registry si një depo të fazave.
Më parë, kur projekti werf quhej ende dapp, kishte një mundësi të tillë. Megjithatë, na u desh të përballeshim me disa probleme që duhen marrë parasysh gjatë implementimit të kësaj funksionaliteti në werf.
Shënim. Ky funksionalitet nuk parashikon punën e ndërtuesit brenda pod-ëve të Kubernetes, pasi për këtë duhet eliminuar varësia nga serveri lokal i Docker-it (në pod-in e Kubernetes s'ka qasje në serverin lokal të Docker-it, sepse procesi i vetë është i nisur në kontejner, dhe werf nuk mbështet dhe nuk do të mbështesë punën me serverin Docker nëpërmjet rrjetit). Mbështetje për punën në Kubernetes do të implementohet ndarazi.
Mbështetje zyrtare për GitHub Actions (E RE)
- Versioni: v1.1
- Afatet: mars
Përfshin dokumentacionin e werf (seksionet reference dhe guide), si dhe GitHub Action zyrtare për punën me werf.
Për më tepër, kjo do të lejojë punën e werf në runner të efemer.
Mekanika e ndërveprimit të përdoruesit me CI-system do të bazohet në vendosjen e label-eve në pull-request për të iniciuar veprime të caktuara për ndërtimin/aktualizimin e aplikacionit.
Zhvillimi lokal dhe implementimi i aplikacioneve me werf (â)
- Versioni: v1.1
- Kohët: janar-shkurt prill
Qëllimi kryesor është të arrihet një konfigurim i unifikuar për implementimin e aplikacioneve si lokal, ashtu edhe në prodhim, pa veprime komplekse, "nga kutia".
Werf kërkon gjithashtu një mënyrë pune në të cilën është e lehtë të redaktohet kodi i aplikacionit dhe të merret menjëherë feedback nga aplikacioni në punë për debugin.
Algoritmi i ri i pastrimit (E RE)
- Versioni: v1.1
- Kohët: prill
Në versionin aktual të werf v1.1, procedura cleanup nuk parashikon pastrimin e imazheve për skemën e etiketimit bazuar në përmbajtje (content-based tagging) - këto imazhe do të grumbullohen.
Po ashtu, versioni aktual i werf (v1.0 dhe v1.1) përdor politika të ndryshme pastrimi për imazhet e publikuara sipas skemave të etiketimit: dega Git, etiketa Git ose komenti Git.
ĂshtĂ« gjetur njĂ« algoritĂ«m i ri tĂ« unifikuar pĂ«r tĂ« gjitha skemat e etiketimit pĂ«r pastrimin e imazheve bazuar nĂ« historinĂ« e komiteve nĂ« Git:
- Të ruhen jo më shumë se N1 imazhe, të lidhura me N2 komitetet e fundit për secilën nga git HEAD (dega dhe etiketat).
- Të ruhen jo më shumë se N1 imazhe-faza, të lidhura me N2 komitetet e fundit për secilën nga git HEAD (dega dhe etiketat).
- Të ruhen të gjitha imazhet që përdoren në ndonjë nga burimet e klasterit Kubernetes (skanohen të gjitha kube-kontekste të skedarit të konfigurimit dhe emrat e hapësirave; mund të kufizohet një sjellje e tillë me opsione speciale).
- Të ruhen të gjitha imazhet që përdoren në manifestet e konfigurimit të burimeve të ruajtura në Helm-releaset.
- Një imazh mund të fshihet, nëse nuk është lidhur me asnjë HEAD nga git (për shembull, sepse ai HEAD përkatës është fshirë) dhe nuk përdoret në asnjë nga manifestet në klasterin Kubernetes dhe në releaset Helm.
NdĂ«rtime paralele tĂ« imazheve (â)
- Versioni: v1.1
- Kohët: janar-shkurt prill*
Versioni aktual i werf ndërtçon imazhet dhe artefaktet e përshkruara në werf.yaml, radhazi. Nevojitet paralelizimi i procesit të ndërtimit të fazave dhe artefakteve të pavarura, si dhe sigurimi i një daljeje të lehtë dhe informative.
* Shënim: data është shtyrë për shkak të rritjes së përparësisë për implementimin e ndërtimit shpërndarë, i cili do të shtojë më shumë mundësi për shkallëzimin horizontal, si dhe përdorimin e werf me GitHub Actions. Ndërtime paralele përbën hapin e ardhshëm të optimizimi, që ofron shkallëzim vertical gjatë ndërtimit të një projekti.
Kalimi nĂ« Helm 3 (â)
- Versioni: v1.2
- Kohët: shkurt-mars maj*
Përfshin kalimin në një bazë të re kodu dhe një mënyrë të provuar dhe të lehtë për migrimin e instalimeve ekzistuese.
* Shënim: kalimi në Helm 3 nuk do të sjellë mundësi të rëndësishme në werf, pasi të gjitha karakteristikat kryesore të Helm 3 (3-way-merge dhe mungesa e tiller) tashmë janë implementuar në werf. Për më tepër, werf ka përveç atyre të përmendura. Megjithatë, ky kalim mbetet në planet tona dhe do të realizohet.
Jsonnet pĂ«r pĂ«rshkrimin e konfiguracionit Kubernetes (â)
- Versioni: v1.2
- Afatet: janar-shkurt prill-maj
Werf do të mbështesë përshkrimin e konfiguracionit për Kubernetes në formatin Jsonnet. Në të njëjtën kohë, werf do të mbetet i kompatibilshëm me Helm dhe do të ketë mundësi përzgjedhjeje të formatit të përshkrimit.
Arsyeja është fakti që shabllonat e gjuhës Go, sipas vlerësimit të shumë njerëzve, kanë një prag të lartë të hyrjes dhe kuptueshmëria e kodit të këtyre shablloneve gjithashtu vuan.
Po ashtu, po shqyrtohet mundësia e implementimit të sistemeve të tjera të përshkrimit të konfiguracionit Kubernetes (p.sh., Kustomize).
Puna brenda Kubernetes (â)
- Versioni: v1.2
- Afatet: prill-maj maj-qershor
Qëllimi: të sigurohet ndërtimi i imazheve dhe dorëzimi i aplikacioneve duke përdorur runner-at në Kubernetes. Pra, ndërtimi i imazheve të reja, publikimi, pastrimi dhe deploy mund të ndodhin drejtpërdrejt nga pod-et Kubernetes.
Për të realizuar këtë mundësi, së pari kërkohet mundësia e ndarjes së ndërtimit të imazheve (shih pikën e mësipërme).
Po ashtu kërkohet mbështetje për modin e funksionimit të ndërtuesit pa server Docker (pra, ndërtimi i ngjashëm me Kaniko ose ndërtimi në userspace).
Werf do të mbështesë ndërtimin në Kubernetes jo vetëm me Dockerfile, por edhe me ndërtuesin e tij Stapel me rikonstruime inkrementale dhe Ansible.
Një hap drejt zhvillimit të hapur
Ne e duam komunitetin tonë (, ) dhe dëshirojmë që gjithnjë e më shumë njerëz të ndihmojnë në përmirësimin e werf, të kuptojnë në cilin drejtim po shkojmë dhe të marrin pjesë në zhvillim.
Më së fundmi, u vendos të kalojmë në për të hapur procesin e punës së ekipit tonë. Tani mund të shihni planet e afërta, si dhe punët aktuale në drejtimet e mëposhtme:
- ;
- ;
- ;
- .
ĂshtĂ« bĂ«rĂ« njĂ« punĂ« e madhe me issues:
- Janë fshirë ato që nuk janë relevante.
- Ato ekzistuese janë sjellë në një format të rëndësishëm, me sasinë e duhur të detajeve dhe hollësive.
- Janë shtuar issues të reja me ide dhe propozime.
Si të aktivizoni versionin v1.1
Versioni është në dispozicion në këtë moment në (në kanalet stable dhe rock-solid lëshimet do të shfaqen ndërsa stabilizohen, megjithatë ea ai vetë është tashmë mjaft stabil për t'u përdorur, pasi ka kaluar përmes kanaleve alpha dhe beta). Aktivizohet në këtë mënyrë:
source $(multiwerf use 1.1 ea)
werf COMMAND ...PĂ«rfundimi
Arkitektura e re e ruajtjes së fazave dhe optimizimi i funksionimit të ndërtuesit për Stapel dhe ndërtuesit Dockerfile hap mundësi për të realizuar ndërtimet e shpërndara dhe paralel në werf. Këto mundësi do të shfaqen së shpejti në të njëjtin version v1.1 dhe do të jenë automatikisht të disponueshme përmes mekanizmit të azhurnimeve automatike (për përdoruesit ).
NĂ« kĂ«tĂ« version Ă«shtĂ« shtuar strategjia e etiketimit sipas pĂ«rmbajtjes sĂ« imazheve â content-based tagging, â e cila Ă«shtĂ« bĂ«rĂ« strategjia e paracaktuar. Gjithashtu, logu i komandeve kryesore Ă«shtĂ« ristrukturuar: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Hapi tjetër i rëndësishëm do të jetë shtimi i ndërtimeve të shpërndara. Ndërtimet e shpërndara që nga versioni v1.0 janë bërë një detyrë më prioritare se ndërtimet paralel, sepse sjellin më shumë vlerë për werf: përmirësimi vertical i ndërtuesve dhe mbështetje për ndërtuesit efemerë në sisteme të ndryshme CI/CD, si dhe mundësia për të bërë mbështetje zyrtare për GitHub Actions. Prandaj, afatet për realizimin e ndërtimeve paralel janë shtyrë. Megjithatë, ne po punojmë për të realizuar të dy mundësitë sa më shpejt.
Qëndroni të informuar për novitet! Dhe mos harroni të na vizitoni në , për të krijuar një issue, për të gjetur një ekzistuese dhe për të vendosur një plus, për të krijuar një PR ose thjesht për të ndjekur zhvillimin e projektit.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»
- «»;
- Cikli i shënimeve mbi risitë në werf:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
