Ne zhvilluam DevOps sa më mirë që mundëm. Ishim 8 veta, dhe Vasya ishte më i miri. WindowsPapritmas Vasya u largua, dhe unë pata detyrën të nisja një projekt të ri që furnizon Windows-zhvillim. Kur e hodha të gjithë grumbullin në tavolinë Windows-zhvillimet, pastaj e kuptova që situata është e dhimbshme...
Kështu fillon historia Alexandra Sinchinova mbi Kur specialisti kryesor u largua nga kompania Windows, Aleksandri pyeste veten se çfarë të bënte tani. Shko te LinuxSigurisht! Aleksandri do t'ju tregojë se si arriti të krijojë një precedent dhe të përkthejë një pjesë Windows zhvillimet në Linux duke përdorur shembullin e një projekti të përfunduar për 100,000 përdorues fundorë.
Si ta dorëzoni lehtësisht dhe pa mundim një projekt në RPM duke përdorur TFS, Puppet, Linux .NET Core? Si e mirëmbani versionimin e bazës së të dhënave të projektit nëse zhvilluesi i dëgjon fjalët Postgres dhe Flyway për herë të parë, dhe afati i fundit është pasnesër? Si e integroni me Docker? Si i motivoni zhvilluesit .NET që të braktisin Windows dhe smoothie për Puppet dhe LinuxSi t’i zgjidhni konfliktet ideologjike nëse shërbeni Windows Nuk keni energjinë, dëshirën apo burimet për të filluar prodhimin? Prezantimi i Aleksandrit diskuton këtë, si dhe implementimin e uebit, testimin, CI-në, praktikat e TFS-së në projektet ekzistuese dhe, sigurisht, zgjidhjet e gabuara dhe funksionale.
Kështu që, Vasja u largua, detyra ishte e imja dhe zhvilluesit po prisnin me padurim me pirunë. Kur më në fund e kuptova se Vasja nuk do të kthehej, fillova punën. Së pari, vlerësova përqindjen e Win VM në flotën tonë. Shanset ishin kundër tij. Windows.
Meqenëse po zhvillojmë në mënyrë aktive DevOps, kuptova se duhej të ndryshonim diçka në qasjen ndaj vendosjes së aplikacioneve të reja. Kishte vetëm një zgjidhje: të zhvendosnim gjithçka në versionin nativ, nëse ishte e mundur. LinuxGoogle më ndihmoi - në atë kohë .Net ishte portuar tashmë në Linux, dhe e kuptova se kjo ishte zgjidhja!
Pse .NET core në lidhje me Linux?
Kishte disa arsye për këtë. Duke pasur parasysh zgjedhjen midis pagesës dhe mospagesës, shumica e njerëzve do të zgjidhnin të dytën - siç bëra edhe unë. Një licencë për MSDB kushton rreth 1,000 dollarë, dhe mirëmbajtja e një flote makinash virtuale Windows arrin në qindra dollarë. Për një kompani të madhe, ky është një shpenzim i konsiderueshëm. Prandaj, kursime - arsyeja e parë. Jo më e rëndësishmja, por një nga më të rëndësishmet.
Makinat virtuale Windows marrin më shumë burime sesa vëllezërit e tyre nga Linux - ato janë të rëndaDuke pasur parasysh shkallën e kompanisë së madhe, ne zgjodhëm Linux.
Sistemi është thjesht i integruar në CI ekzistueseNe e konsiderojmë veten DevOps progresivë, përdorim Bamboo, Jenkins dhe GitLab CI, kështu që pjesa më e madhe e punës sonë bëhet në Linux.
Arsyeja e fundit është shoqërim i përshtatshëm. Na duhej të ulnim barrierën e hyrjes për "mirëmbajtësit" - ata që e kuptojnë anën teknike, sigurojnë kohën e funksionimit dhe mirëmbajnë shërbimet nga linja e dytë. Ata ishin tashmë të njohur me paketën. Linux, kështu që është shumë më e lehtë për ta të kuptojnë, mbështesin dhe mirëmbajnë një produkt të ri sesa të shpenzojnë burime shtesë për të kuptuar funksionalitetin e ngjashëm të softuerit për Windows platformat.
Kërkesat
Para së gjithash - komoditeti i zgjidhjes së re për zhvilluesitJo të gjithë ishin të gatshëm për ndryshim, veçanërisht pasi fjala u tha. LinuxZhvilluesit duan Visual Studio-n e tyre të preferuar, TFS me teste të automatizuara ndërtimi dhe smoothie. Mënyra se si e dorëzojnë në prodhim nuk është e rëndësishme për ta. Kjo është arsyeja pse vendosëm të mos e ndryshojmë procesin e njohur dhe ta lëmë për... Windows- Zhvillimet mbeten të pandryshuara.
Nevojitet projekt i ri integrohen në CI ekzistuese. Binarët ishin tashmë aty dhe e gjithë puna duhej bërë duke marrë parasysh parametrat e sistemit të menaxhimit të konfigurimit, standardet e pranuara të dorëzimit dhe sistemet e monitorimit.
Lehtësia e mbështetjes dhe funksionimit, si kusht për pragun minimal të hyrjes për të gjithë pjesëmarrësit e rinj nga divizione të ndryshme dhe departamenti mbështetës.
Afati - dje.
Win Development Group
Me çfarë punonte ekipi atëherë? Windows?
Tani mund ta them me bindje këtë IdentityServer4 është një alternativë e lezetshme falas për ADFS me aftësi të ngjashme, ose çfarë Bërthama e Kornizës së Entitetit - një parajsë për një zhvillues, ku nuk duhet të shqetësoheni për të shkruar skriptet SQL, por përshkruani pyetjet në bazën e të dhënave në terma OOP. Por më pas, gjatë diskutimit të planit të veprimit, e shikova këtë pirg sikur të ishte kuneiformë sumeriane, duke njohur vetëm PostgreSQL dhe Git.
Në atë kohë ne përdornim në mënyrë aktive kukull si një sistem i menaxhimit të konfigurimit. Në shumicën e projekteve tona kemi përdorur GitLab CI, Elastik, duke përdorur shërbime të balancuara me ngarkesë të lartë HAProxy monitoruar gjithçka me Zabbix, ligamentet grafana и Prometeu, Jaeger, dhe e gjithë kjo rrotullohej mbi copa hekuri HP c ESXi mbi VMware. Të gjithë e dinë - një klasik i zhanrit.
Le të shohim dhe të përpiqemi të kuptojmë se çfarë po ndodhte përpara se të fillonim të gjitha këto ndërhyrje.
Cfare ndodhi
TFS është një sistem mjaft i fuqishëm që jo vetëm që shpërndan kodin nga zhvilluesi në makinën përfundimtare të prodhimit, por gjithashtu ka një grup për integrim shumë fleksibël me shërbime të ndryshme - për të ofruar CI në një nivel ndër-platformë.
Më parë, të gjitha këto ishin dritare. TFS përdorte disa agjentë Ndërtimi, të cilët ndërtonin projekte të shumëfishta. Çdo agjent kishte 3-4 punëtorë për të paralelizuar detyrat dhe për të optimizuar procesin. Pastaj, sipas planeve të publikimit, TFS e dorëzonte Ndërtimin e sapo pjekur te Windows- server aplikacioni.
Çfarë donim të arrinim?
Ne përdorim TFS për shpërndarje dhe zhvillim, dhe e lançojmë aplikacionin në Linux server aplikacioni, dhe ka njëfarë magjie midis tyre. Kjo Kutia Magjike dhe atje është kripa e punës përpara. Përpara se ta shkëput, do të bëj një hap mënjanë dhe do të them disa fjalë për aplikacionin.
Projekt
Aplikacioni ofron funksionalitet për trajtimin e kartave me parapagesë.
klient
Kishte dy lloje përdoruesish. I parë fitoi akses duke u identifikuar duke përdorur një certifikatë SSL SHA-2. U e dyta kishte akses duke përdorur një hyrje dhe fjalëkalim.
HAProxy
Pastaj kërkesa e klientit shkoi në HAProxy, e cila zgjidhi problemet e mëposhtme:
- autorizimi primar;
- Përfundimi SSL;
- akordimi i kërkesave HTTP;
- kërkesat për transmetim.
Certifikata e klientit u verifikua përgjatë zinxhirit. ne - autoritet dhe ne mund ta përballojmë këtë, pasi ne vetë lëshojmë certifikata për klientët e shërbimit.
Kushtojini vëmendje pikës së tretë, do t'i kthehemi pak më vonë.
backend
Backend-i ishte planifikuar të bëhej në LinuxSistemi i mbështetjes bashkëvepron me bazën e të dhënave, ngarkon listën e kërkuar të privilegjeve dhe më pas, në varësi të privilegjeve të përdoruesit të autorizuar, jep akses për të nënshkruar dokumente financiare dhe për t'i dërguar ato për ekzekutim, ose për të gjeneruar një raport.
Kursime me HAProxy
Përveç dy konteksteve që lundronte secili klient, kishte edhe një kontekst identiteti. IdentityServer4 thjesht ju lejon të identifikoheni, ky është një analog falas dhe i fuqishëm për ADFS - Shërbimet e Federatës Active Directory.
Kërkesa për identitetin u përpunua në disa hapa. Hapi i parë - klient u fut në fund, i cili komunikoi me këtë server dhe kontrolloi praninë e një token për klientin. Nëse nuk gjendej, kërkesa kthehej përsëri në kontekstin prej nga vinte, por me ridrejtim dhe me ridrejtimin shkonte në identitet.
Hapi i dytë - kërkesa u pranua në faqen e autorizimit në IdentityServer, ku klienti u regjistrua dhe ai token i shumëpritur u shfaq në bazën e të dhënave IdentityServer.
Hapi i tretë - klienti u ridrejtua prapa në kontekstin nga erdhi.
IdentityServer4 ka një veçori: kthen përgjigjen në kërkesën e kthimit nëpërmjet HTTP. Pa marrë parasysh se sa shumë kemi luftuar me vendosjen e serverit, pa marrë parasysh sa ndriçoheshim me dokumentacionin, sa herë merrnim një kërkesë fillestare të klientit me një URL që vinte nëpërmjet HTTPS dhe IdentityServer kthente të njëjtin kontekst, por me HTTP. Ne ishim të tronditur! Dhe ne i transferuam të gjitha këto përmes kontekstit të identitetit në HAProxy, dhe në titujt duhej të modifikonim protokollin HTTP në HTTPS.
Cili është përmirësimi dhe ku keni kursyer?
Kemi kursyer para duke përdorur një zgjidhje falas për autorizimin e një grupi përdoruesish, burimesh, pasi nuk e vendosëm IdentityServer4 si një nyje të veçantë në një segment të veçantë, por e përdorëm atë së bashku me backend-in në të njëjtin server ku funksionon backend-i i aplikacionit. .
Si duhet të funksionojë
Pra, siç premtova – Kutia Magjike. Ne tashmë e kuptojmë se po ecim patjetër në këtë drejtim LinuxLe të formulojmë detyrat specifike që duheshin zgjidhur.
Manifestohet kukulla. Për të ofruar dhe menaxhuar konfigurimin e shërbimit dhe aplikacionit, duhej të shkruheshin receta interesante. Një rrotull lapsi tregon në mënyrë elokuente sa shpejt dhe me efikasitet është bërë.
Metodat e dërgesës. Standardi është RPM. Të gjithë e kuptojnë këtë në Linux Nuk kishte asnjë mënyrë tjetër, por vetë projekti, pasi u ndërtua, ishte një koleksion skedarësh DLL të ekzekutueshëm. Kishte rreth 150 të tillë, duke e bërë projektin mjaft të rëndë. E vetmja zgjidhje e qëndrueshme ishte paketimi i këtyre skedarëve binare në RPM dhe vendosja e aplikacionit prej andej.
Versionimi. Do të publikonim shumë shpesh dhe duhej të vendosnim se si do ta formonim emrin e paketës. Kjo ishte një çështje e nivelit të integrimit me TFS-në. Kishim një agjent ndërtimi në LinuxKur TFS i dërgon një detyrë një punonjësi në një agjent Ndërtimi, ai gjithashtu i kalon atij një sërë variablash që ruhen në mjedisin e punonjësit. Këto variabla mjedisi përmbajnë emrin Ndërtimi, emrin e versionit dhe variabla të tjerë. Më shumë detaje janë të disponueshme në seksionin "Ndërtimi i një Pakete RPM".
Konfigurimi i TFS E gjitha përfundohej në ngritjen e Gazsjellësit. Më parë, ne ndërtonim mbi Windows- të gjithë agjentët Windows-projekte, dhe tani duket Linux-agent — një agjent Ndërtimi që duhet të përfshihet në grupin e ndërtimit, i pasuruar me disa objekte, i specifikuar se çfarë lloji projektesh do të ndërtohen në këtë agjent Ndërtimi dhe Pipeline i modifikuar në një farë mënyre.
IdentityServer. ADFS nuk është rruga jonë, ne po shkojmë për Open Source.
Le të kalojmë nëpër komponentët.
Kutia Magjike
Përbëhet nga katër pjesë.
Linux Ndërtoni agjent. Linux, sepse po e kompilojmë për të—ka kuptim. Kjo pjesë u përfundua në tre hapa.
- Konfiguro punëtorët dhe jo vetëm, pasi pritej puna e shpërndarë në projekt.
- Instaloni .NET Core 1.x. Pse 1.x kur 2.0 është tashmë i disponueshëm në depon standarde? Sepse kur filluam zhvillimin, versioni stabil ishte 1.09 dhe u vendos që të bëhej projekti në bazë të tij.
- Git 2.x.
RPM-depo. Paketat RPM duheshin ruajtur diku. Ne duhej të përdornim të njëjtën depo RPM të korporatës që ishte e aksesueshme për të gjithë. Linux hosts. Kjo është ajo që bëmë. Serveri i repozitorit është i konfiguruar grep uebi i cili shkarkoi paketën e kërkuar RPM nga lokacioni i specifikuar. Versioni i paketës u raportua në webhook nga agjenti Build.
GitLab Ju lutem vini re: GitLab nuk përdoret nga zhvilluesit këtu, por nga departamenti i operacioneve për të kontrolluar versionet e aplikacioneve, versionet e paketave dhe statusin e të gjithave. Linux-makina dhe ruan recetën - të gjitha manifestimet e Kukullave.
kukull — zgjidh të gjitha çështjet e diskutueshme dhe jep saktësisht konfigurimin që duam nga Gitlab.
Ne fillojmë të zhytemi. Si funksionon dorëzimi i DLL në RPM?
Dorëzimi i DDL në RPM
Le të themi se kemi një rockstar të zhvillimit .NET. Ai përdor Visual Studio dhe krijon një degë lëshimi. Pas kësaj, ai e ngarkon atë në Git, dhe Git këtu është një entitet TFS, domethënë është depoja e aplikacionit me të cilën punon zhvilluesi.
Pas kësaj, TFS sheh se ka mbërritur një commit i ri. Cilin aplikacion? Cilësimet e TFS tregojnë se cilat burime ka secili Agjent Ndërtimi. Në këtë rast, ai sheh se po ndërtojmë një projekt .NET Core dhe zgjedh Linux Ndërtoni një agjent nga grupi.
Agjenti Build merr burimet dhe shkarkon të nevojshme varësi nga depoja .NET, npm, etj. dhe pas ndërtimit të vetë aplikacionit dhe paketimit pasues, dërgon paketën RPM në depo RPM.
Nga ana tjetër, ndodh si më poshtë. Inxhinieri i departamentit të operacioneve është i përfshirë drejtpërdrejt në prezantimin e projektit: ai ndryshon versionet e paketave Hiera në depon ku ruhet receta e aplikimit, pas së cilës Puppet aktivizohet Yum, merr paketën e re nga depoja dhe versioni i ri i aplikacionit është gati për t'u përdorur.
Gjithçka është e thjeshtë me fjalë, por çfarë ndodh brenda vetë agjentit Build?
RPM i paketimit DLL
Marrë burimet e projektit dhe ndërtimin e detyrës nga TFS. Ndërtimi i agjentit fillon ndërtimin e vetë projektit nga burimet. Projekti i montuar është në dispozicion si një grup Skedarët DLL, të cilat janë të paketuara në një arkiv zip për të reduktuar ngarkesën në sistemin e skedarëve.
Arkivi ZIP është hedhur tutje në drejtorinë e ndërtimit të paketës RPM. Më pas, skripti Bash inicializon variablat e mjedisit, gjen versionin Build, versionin e projektit, shtegun për në direktorinë e ndërtimit dhe ekzekuton RPM-build. Pasi të përfundojë ndërtimi, paketa publikohet në depo lokale, i cili ndodhet në agjentin Build.
Më pas, nga agjenti Build në server në depon e RPM Kërkesa JSON është dërguar duke treguar emrin e versionit dhe të ndërtimit. Webhook, për të cilin fola më herët, shkarkon pikërisht këtë paketë nga depoja lokale në agjentin Build dhe e vë në dispozicion për instalim asamblenë e re.
Pse kjo skemë e veçantë shpërndarjeje për depon RPM? Pse paketa e ndërtuar nuk mund të dërgohet menjëherë në depo? Ky është një kërkesë sigurie. Ky skenar kufizon mundësinë që persona të paautorizuar të ngarkojnë paketa RPM në një server të aksesueshëm publikisht. Linux- makina.
Versionimi i bazës së të dhënave
Në konsultimin për zhvillim, doli që djemtë janë më afër MS SQL, por në shumicën e rasteve jo-Windows Ne tashmë e përdornim gjerësisht PostgreSQL për disa projekte. Meqenëse kishim vendosur të hiqnim dorë nga softuerët me pagesë, filluam të përdornim PostgreSQL edhe këtu.
Në këtë pjesë dua t'ju tregoj se si e kemi versionuar bazën e të dhënave dhe si kemi zgjedhur midis Flyway dhe Entity Framework Core. Le të shohim të mirat dhe të këqijat e tyre.
Cons
Flyway shkon vetëm në një drejtim, ne nuk mund të tërhiqemi — ky është një disavantazh i rëndësishëm. Mund të krahasohet me Entity Framework Core në mënyra të tjera - nga perspektiva e komoditetit të zhvilluesit. Ju kujtohet se ne e bëmë këtë një përparësi kryesore dhe kriteri kryesor ishte të mos ndryshonim asgjë për Windows-zhvillimet.
Për Flyway us nevojitej një lloj mbështjellësinë mënyrë që djemtë të mos shkruajnë Pyetjet SQL. Ata janë shumë më afër funksionimit në terma të OOP. Ne shkruam udhëzime për të punuar me objektet e bazës së të dhënave, krijuam një pyetje SQL dhe e ekzekutuam atë. Versioni i ri i bazës së të dhënave është gati, i testuar - gjithçka është në rregull, gjithçka funksionon.
Entity Framework Core ka një minus - atë nën ngarkesa të rënda ndërton pyetje nënoptimale SQL, dhe tërheqja në bazën e të dhënave mund të jetë e rëndësishme. Por duke qenë se ne nuk kemi një shërbim me ngarkesë të lartë, ne nuk e llogarisim ngarkesën në qindra RPS, ne i pranuam këto rreziqe dhe ia deleguam problemin neve të ardhmes.
Rekuizitë
Bërthama e Kornizës së Entitetit punon jashtë kutisë dhe është e lehtë për t'u zhvilluar, dhe Flyway Integrohet lehtësisht në CI ekzistuese. Por ne e bëjmë atë të përshtatshëm për zhvilluesit :)
Procedura e përmbledhjes
Puppet sheh se një ndryshim në versionin e paketës po vjen, duke përfshirë atë që është përgjegjës për migrimin. Së pari, ai instalon një paketë që përmban skriptet e migrimit dhe funksionalitetin e lidhur me bazën e të dhënave. Pas kësaj, aplikacioni që punon me bazën e të dhënave riniset. Më pas vjen instalimi i komponentëve të mbetur. Rendi në të cilin instalohen paketat dhe lëshohen aplikacionet përshkruhet në manifestin e Kukullave.
Aplikacionet përdorin të dhëna të ndjeshme, të tilla si argumentet, fjalëkalimet e bazës së të dhënave, e gjithë kjo tërhiqet në konfigurimin nga Puppet Master, ku ruhen në formë të koduar.
Problemet e TFS
Pasi vendosëm dhe kuptuam se gjithçka po funksiononte vërtet për ne, vendosa të shikoja se çfarë po ndodhte me asambletë në TFS në tërësi për departamentin e zhvillimit të Win në projekte të tjera - nëse po ndërtonim/lëshonim shpejt apo jo, dhe zbuloi probleme të rëndësishme me shpejtësinë.
Një nga projektet kryesore merr 12-15 minuta për t'u mbledhur - kjo është një kohë e gjatë, nuk mund të jetosh kështu. Një analizë e shpejtë tregoi një ulje të tmerrshme në I/O, dhe kjo ishte në vargje.
Pasi e analizova komponent pas komponenti, identifikova tre vatra. Së pari - "Kaspersky antivirus", e cila është mbi të gjithë Windows Agjentët e ndërtimit skanojnë kodin burimor. I dyti është Windows Indeksues. Nuk u çaktivizua dhe gjithçka u indeksua në kohë reale në agjentët e Build gjatë procesit të vendosjes.
E treta - Instaloni Npm. Doli që në shumicën e tubacioneve ne përdorëm pikërisht këtë skenar. Pse është i keq? Procedura e instalimit Npm ekzekutohet kur formohet pema e varësisë paketë-kyç.json, ku regjistrohen versionet e paketave që do të përdoren për të ndërtuar projektin. E keqja është se instalimi Npm nxjerr çdo herë versionet më të fundit të paketave nga Interneti, dhe kjo kërkon shumë kohë në rastin e një projekti të madh.
Zhvilluesit ndonjëherë eksperimentojnë në një makinë lokale për të testuar se si funksionon një pjesë e caktuar ose e tërë projekti. Ndonjëherë doli që gjithçka ishte e freskët në vend, por ata e montuan atë, e rrokullisnin dhe asgjë nuk funksionoi. Ne fillojmë të kuptojmë se cili është problemi - po, versione të ndryshme të paketave me varësi.
vendim
- Burimet në përjashtimet AV.
- Çaktivizo indeksimin.
- Shko te npm ci.
Përparësitë e npm ci janë se ne Ne mbledhim pemën e varësisë një herë, dhe ne kemi mundësinë t'i ofrojmë zhvilluesit lista aktuale e paketave, me të cilën ai mund të eksperimentojë në nivel lokal sa të dojë. Kjo kursen kohë zhvilluesit që shkruajnë kodin.
konfiguracion
Tani pak për konfigurimin e depove. Historikisht ne përdorim Lidhje për menaxhimin e depove, duke përfshirë REPO e brendshme. Kjo depo e brendshme përmban të gjithë komponentët që ne përdorim për qëllime të brendshme, për shembull, monitorimin e shkruar vetë.
Ne gjithashtu përdorim NuGet, pasi ka caching më të mirë në krahasim me menaxherët e tjerë të paketave.
Result
Pasi optimizuam Build Agents, koha mesatare e ndërtimit u reduktua nga 12 minuta në 7.
Nëse numërojmë të gjitha makinat që mund të përdorim Windows, por e përkthyer në Linux Në këtë projekt, kursyem rreth 10,000 dollarë. Dhe kjo është vetëm për licencat; nëse merrni parasysh përmbajtjen, është edhe më shumë.
Planet
Për tremujorin e ardhshëm, ne kemi planifikuar të punojmë në optimizimin e shpërndarjes së kodit.
Kalimi në një imazh të para-ndërtuar Docker. TFS është një gjë interesante me shumë shtojca që ju lejojnë të integroheni në Pipeline, duke përfshirë montimin e bazuar në shkas të, të themi, një imazh Docker. Ne duam ta bëjmë këtë shkas për të njëjtin paketë-kyç.json. Nëse përbërja e komponentëve të përdorur për të ndërtuar projektin ndryshon disi, ne ndërtojmë një imazh të ri Docker. Më vonë përdoret për të vendosur kontejnerin me aplikacionin e montuar. Ky nuk është rasti tani, por ne po planifikojmë të kalojmë në një arkitekturë mikroservice në Kubernetes, e cila po zhvillohet në mënyrë aktive në kompaninë tonë dhe i ka shërbyer zgjidhjeve të prodhimit për një kohë të gjatë.
Përmbledhje
I bëj thirrje të gjithëve ta hedhin poshtë Windows, por nuk është sepse nuk di ta gatuaj. Arsyeja është se shumica e zgjidhjeve me burim të hapur janë Linux-grumbull. A je mirë kurseni në burimeSipas mendimit tim, e ardhmja qëndron te zgjidhjet me burim të hapur. Linux me një komunitet të fuqishëm.
Profili i folësit të Alexander Sinchinov .
është një konferencë mbi integrimin e proceseve të zhvillimit, testimit dhe funksionimit për profesionistë nga profesionistë. Ja pse projekti për të cilin foli Aleksandri? implementuar dhe funksionuar, dhe në ditën e shfaqjes pati dy publikime të suksesshme. Aktiv Në datat 27 dhe 28 maj do të ketë edhe më shumë raste të ngjashme nga praktikuesit. Ju ende mund të hidheni në karrocën e fundit dhe ose merrni kohën tuaj biletë. Na takoni në Skolkovo!
Burimi: www.habr.com
