Ne zhvilluam DevOps siç mundëm. Ishim 8 persona, dhe Vasia ishte më i miri në Windows. Papritmas, Vasia u largua, dhe unë mora detyrën për të sjellë një projekt të ri, i cili ofron zhvillim për Windows. Kur i shpërndava të gjithë stek-un e zhvillimit për Windows mbi tryezë, e kuptova se situata ishte e vështirë...
Kështu fillon historia Aleksandër Sinçinov në . Kur specialisti kryesor i Windows u largua nga kompania, Aleksandri u pyet se çfarë duhet të bënte tani. Të kalonte në Linux, sigurisht! Aleksandri do të tregojë se si arriti të krijojë një precedent dhe të transferojë një pjesë të zhvillimit për Windows në Linux përmes një projekti të realizuar me 100,000 përdorues të fundit.
Si e lehtë dhe e natyrshme të dorëzosh një projekt në RPM duke përdorur TFS, Puppet, Linux .NET core? Si të mbash versionimin e DB-së së projektit, nëse zhvilluesit për herë të parë dëgjojnë fjalët Postgres dhe Flyway, dhe afati është pasnesër? Si të integrosh me Docker? Si t'i motivosh zhvilluesit .NET të heqin dorë nga Windows dhe smoothies për Puppet dhe Linux? Si të zgjidhësh konfliktet ideologjike nëse nuk ka energji, dëshira ose burime për të mbajtur Windows në prodhim? Në lidhje me këtë, si dhe rreth Web Deploy, testimit, CI, praktikave të përdorimit të TFS në projektet ekzistuese, dhe sigurisht, për këmbanat e thyera dhe zgjidhjet që funksionojnë, në transkriptin e raportit të Aleksandrit.
Pra, Vasya u largua, detyra është për mua, zhvilluesit presin me tulla me padurim. Kur kuptova përfundimisht se nuk mund ta ktheja Vasya - fillova punën. Fillimisht, vlerësova përqindjen e VM Windows në parku tonë. Numri ishte në dëm të Windows.
Duke qenë se ne po zhvillojmë aktivisht DevOps, kuptova se duhej të ndryshoja diçka në qasjen për nxjerrjen e një aplikacioni të ri. Zgjidhja ishte një - sa më shumë që është e mundur, të kalojmë gjithçka në Linux. Google më ndihmoi - në atë kohë .Net ishte portuar nën Linux, dhe kuptova se kjo ishte zgjidhja!
Pse .NET core në lidhje me Linux?
Kjo kishte disa arsye. NdĂ«rmjet 'tĂ« paguash' dhe 'tĂ« mos paguash' shumica do tĂ« zgjedhin tĂ« dytĂ«n â si dhe unĂ«. Licenca pĂ«r MSDB kushton rreth 1 000 $, mirĂ«mbajtja e parkut tĂ« makinave virtuale Windows matet nĂ« qindra dollarĂ«. PĂ«r njĂ« kompani tĂ« madhe, kĂ«to janĂ« shpenzime tĂ« mĂ«dha. Prandaj, kursimi â arsyeja e parĂ«. Nuk Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja, por njĂ« nga ato tĂ« rĂ«ndĂ«sishme.
Makinat virtuale Windows konsumojnĂ« mĂ« shumĂ« burime se sa homologĂ«t e tyre Linux â ato janĂ« tĂ« r heavy. Duke marrĂ« parasysh madhĂ«sinĂ« e njĂ« kompanie tĂ« madhe, ne zgjodhĂ«m Linux.
Sistemi thjesht integret në CI ekzistues. Ne e konsiderojmë veten DevOps progresivë, përdorim Bamboo, Jenkins dhe GitLab CI, prandaj pjesa më e madhe e punës sonë bëhet në Linux.
Arsyeja e fundit Ă«shtĂ« mirĂ«mbajtja e lehtĂ«. Na duhej tĂ« ulja e pragut tĂ« hyrjes pĂ«r 'mirĂ«mbajtĂ«sit' â djemtĂ« qĂ« kuptojnĂ« pjesĂ«n teknike, sigurojnĂ« vazhdimĂ«sinĂ« dhe mbajnĂ« shĂ«rbimet nga linja e dytĂ«. Ata tashmĂ« ishin tĂ« njohur me stakun Linux, kĂ«shtu qĂ« u ishte shumĂ« mĂ« e lehtĂ« tĂ« kuptonin produktin e ri, ta mbĂ«shtesin dhe ta mirĂ«mbajnĂ«, sesa tĂ« shpenzonin burime shtesĂ« pĂ«r tĂ« kuptuar njĂ« funksionalitet tĂ« ngjashĂ«m tĂ« softuerit pĂ«r platformĂ«n Windows.
KĂ«rkesat
E para dhe më e rëndësishmja është lehtësia e zgjidhjes së re për zhvilluesit. Jo të gjithë ishin të gatshëm për ndryshime, veçanërisht pas përmendjes së fjalës Linux. Zhvilluesit duan Visual Studio të tyre të dashur, TFS me teste automatike për ndërtimet dhe smoothie. Si ndodh dorëzimi në prodhim - për ta nuk ka rëndësi. Kështu, ne vendosëm të mos ndryshojmë procesin e zakonshëm dhe të lëmë gjithçka të paprekur për zhvillimin në Windows.
Projekti i ri duhet të integrohet në CI ekzistuese. Rails ishin tashmë në vend dhe gjithë puna duhej të kryhej duke pasur parasysh parametrat e sistemit të menaxhimit të konfigurimit, standardet e pranueshme të dorëzimit dhe sistemet e monitorimit.
Thjeshtësia në mbështetje dhe operim, si kushte për një prag minimal hyrjeje për të gjithë pjesëmarrësit e rinj nga departamente të ndryshme dhe departamenti i mbështetjes.
Afati - dje.
Grupi i zhvillimit të Win
Me çfarë po punonte ekipi i Windows?
Tani mund tĂ« them me siguri se IdentityServer4 ështĂ« njĂ« alternativĂ« e shkĂ«lqyer falas pĂ«r ADFS me funksionalitete tĂ« ngjashme, ose se Entity Framework Core â njĂ« parajsĂ« pĂ«r zhvilluesit, ku mund tĂ« mos shqetĂ«soheni pĂ«r shkruarjen e skripteve SQL, por tĂ« pĂ«rshkruani kĂ«rkesat nĂ« bazĂ«n e tĂ« dhĂ«nave nĂ« terma OOP. Por atĂ«herĂ«, gjatĂ« diskutimit tĂ« planit tĂ« veprimit, e shikoja kĂ«tĂ« stivĂ« si njĂ« shkrim tĂ« lashtĂ« sumerian duke njohur vetĂ«m PostgreSQL dhe Git.
NĂ« atĂ« kohĂ« ne po pĂ«rdornim aktivisht Puppet si sistem pĂ«r menaxhimin e konfiguracionit. NĂ« shumicĂ«n e projekteve tona ne pĂ«rdornim GitLab CI, Elastic, balanconim shĂ«rbime me ngarkesĂ« tĂ« lartĂ« duke pĂ«rdorur HAProxy, vĂ«zhgonim gjithçka me Zabbix, lidhĂ«si Grafana dhe Prometheus, Jaeger, dhe gjithçka kjo funksiononte nĂ«Â HP me ESXi nĂ«Â VMware. TĂ« gjithĂ« e njohin â klasika e zhanrit.
Le të shohim dhe të përpiqemi të kuptojmë se çfarë ndodhi përpara se të nisnim të gjitha këto ndërhyrje.
ĂfarĂ« ishte
TFS â Ă«shtĂ« njĂ« sistem mjaft i fuqishĂ«m, i cili jo vetĂ«m qĂ« dĂ«rgon kodin nga zhvilluesi nĂ« makinĂ« pĂ«rfundimtare tĂ« prodhimit, por gjithashtu ka njĂ« grup pĂ«r integrim shumĂ« fleksibĂ«l me shĂ«rbime tĂ« ndryshme â pĂ«r tĂ« siguruar CI nĂ« nivel multipllatform.
MĂ« parĂ«, kĂ«to ishin vetĂ«m dritare tĂ« thjeshta. TFS pĂ«rdorte disa agjentĂ« tĂ« ndĂ«rtimit, mbi tĂ« cilĂ«t mblidheshin shumĂ« projekte. Ădo agjent kishte 3-4 punĂ«torĂ«, pĂ«r tĂ« ndarĂ« detyrat dhe optimizuar procesin. Pastaj, sipas planeve tĂ« lĂ«shimit, TFS dĂ«rgonte ndĂ«rtimin e ri nĂ« serverin Windows tĂ« aplikacioneve.
ĂfarĂ« dĂ«shironim tĂ« arrijmĂ«
Për dërgimin dhe zhvillimin përdorim TFS, ndërsa aplikacioni ekzekutohet në serverin e aplikacioneve Linux, dhe ndodhet ndonjë magji mes tyre. Ky Magic Box është thelbi i punës së ardhshme. Para se ta analizojmë atë në pjesë, do të bëj një hap në anë dhe do të them disa fjalë rreth aplikacionit.
Projekt
Aplikacioni ofron funksionalitet për menaxhimin e kartave të parapaguara.
Klienti
Ekzistonte dy lloje përdoruesish. I parë ka qasje, duke u autorizuar me një certifikatë SSL SHA-2. Një i dytë kishte qasje me përdorues dhe fjalëkalim.
HAProxy
Pas kësaj, kërkesa e klientit kalonte në HAProxy, e cila vendoste detyrat vijues:
- autorizimi fillestar;
- terminimi i SSL;
- rregullimi i kërkesave HTTP;
- transmetimi i kërkesave.
Kontrolli i certifikatës së klientit ndodhte nëpërmjet zinxhirit. Ne jemi authority dhe mund ta lejojmë këtë, pasi e japim vetë certifikatën klientëve të shërbimit.
Kujdesuni për pikën e tretë, do të rikthehemi te ajo më vonë.
Backend
Planifikonim të bënim backend-in në Linux. Backend-i komunikon me DB, ngarkon listën e nevojshme të privilegjeve dhe pastaj, në varësi të privilegjeve që ka përdoruesi i autorizuar, ofron akses për nënshkrimin e dokumenteve financiare dhe dërgimin e tyre për ekzekutim, ose gjenerimin e ndonjë raporti.
Kursimi me HAProxy
PĂ«rveç dy konteksteve, pĂ«r tĂ« cilat kaloi çdo klient, ekzistonte edhe konteksti identity. IdentityServer4 pikĂ«risht lejon tĂ« autorizohet, Ă«shtĂ« njĂ« alternativĂ« e fuqishme dhe falas pĂ«r ADFS â ShĂ«rbimet Federale tĂ« DrejtorisĂ« Aktive.
KĂ«rkesa nĂ« identity pĂ«rpunoheshin nĂ« disa hapa. Hapi i parĂ« - nĂ« C â ai merret ekskluzivisht me detyrat DNS. kalonte nĂ« backend, i cili shkĂ«mbeu tĂ« dhĂ«nat me kĂ«tĂ« server dhe kontrolloi pĂ«r prani tĂ« tokenit pĂ«r klientin. NĂ«se nuk e gjeti - kĂ«rkesa kthehej prapa nĂ« kontekstin nga i cili erdhi, por tashmĂ« me ridrejtim, dhe me ridrejtim shkonte nĂ« identity.
Hapi i dytë - kërkesa shkonte në faqen e autorizimit në IdentityServer, ku klienti regjistrohej, dhe në bazën e të dhënave të IdentityServer shfaqej ai tokeni i shumëpritur.
Hapi i tretë - klienti ridrejtohej mbrapsht në kontekst, nga i cili erdhi.
IdentityServer4 ka një karakteristikë: përgjigjen ndaj kërkesës prapa e kthen me HTTP. Siç e konfigurim serverin, siç e shqyrtuam dokumentacionin, por çdo herë merrnim kërkesën fillestare të klientit me URL, e cila erdhi me HTTPS, ndërsa IdentityServer ktheu të njëjtin kontekst, por me HTTP. Ishim të shokuar! Dhe e çuam gjithë këtë përmes kontekstit identity në HAProxy, dhe në headra na duhej të modifikonim protokollin HTTP në HTTPS.
ĂfarĂ« Ă«shtĂ« pĂ«rmirĂ«simi dhe ku kemi kursyer?
Kemi kursyer para, duke përdorur një zgjidhje falas për autorizimin e grupit të përdoruesve, burimet, pasi nuk e nxorëm IdentityServer4 si një nod të veçantë në një segment të veçantë, por e përdorëm së bashku me backendin në të njëjtin server, ku funksionon backendi i aplikacionit.
Si duhet të punojë
Pra, siç e premtoj - Magic Box. Ne tashmë e kuptojmë se po lëvizim me siguri drejt Linux. Le të formulojmë detyrat specifike që kërkonin zgjidhje.
Manifestet Puppet. Për të dorëzuar dhe menaxhuar konfigurimin e shërbimit dhe aplikacionit, duhej të shkruheshin receta të shkëlqyera. Një laps i vogël tregon qartë se si u realizua kaq shpejt dhe me cilësi.
Mënyra e dërgimit. Standarti është RPM. Të gjithë e kuptojnë se në Linux nuk ka mënyrë tjetër, por projekti pas ndërtimit përbënte një grup skedash ekzekutive DLL. Ishin rreth 150, projekti ishte mjaft i rëndë. Zgjidhja e vetme harmonike ishte të paketosh këtë binar në RPM dhe më pas të shpalosësh aplikacionin prej tij.
Versionimi. Na duhej të lëshonim shumë shpesh dhe duhej të zgjidhim mënyrën se si të formonim emrin e paketës. Ky është një çështje niveli integrimi me TFS. Agjenti Build ishte në Linux. Kur TFS dërgon një detyrë për përpunuesin - punëtor - në Agjentin Build, ai gjithashtu i kalon një grup variablash, të cilat kalojnë në ambientin e procesit të përpunuesit. Në këto variabla ambienti kalohen emri Build, emri i versionit dhe variabla të tjera. Më shumë rreth kësaj në seksionin 'ndërtimi i paketës RPM'.
Konfigurimi i TFS kishte të bënte me konfigurimin e Pipeline. Më parë ne mbledhim të gjitha projektet Windows mbi agjentët Windows, por tani kemi një agjent Linux - Build-agentin, i cili duhet të përfshihet në grupin e ndërtimit, të pasurohet me disa artefakte, të thuhet se çfarë lloj projektesh do të ndërtohen në këtë Build-agent dhe si të modifikohet ndonjë mënyrë Pipeline-in.
IdentityServer. ADFS nuk është rruga jonë, ne mbështesim Open Source.
Le të kalojmë nëpër komponentët.
Magic Box
Konsiston në katër pjesë.
Linux Build-agent. Linux, sepse ne e ndërtuam për të - logjike. Kjo pjesë u realizua në tre hapa.
- Konfiguroni punëtorët dhe jo vetëm një, pasi ishte parashikuar një punë e shpërndarë mbi projektin.
- Instaloni .NET Core 1.x. Pse pikërisht 1.x, kur 2.0 është tashmë në depozitën standarde? Sepse, kur filluam zhvillimin, versioni stabil ishte 1.09, dhe ishte vendosur që projekti të bëhej nën të.
- Git 2.x.
RPM-repository. RPM-paketet duhej të ruheshin diku. U parashikua që ne do të përdorim të njëjtin RPM-repozitorin korporativ, i cili është i disponueshëm për të gjitha host-et Linux. Kështu vepruam. Në serverin e repositorit është konfiguruar webhook i cili shkarkonte paketën RPM të kërkuar nga vendi i caktuar. Versioni i paketës i raportuar Build-agentit.
GitLab. Kujdes! GitLab kĂ«tu pĂ«rdoret jo nga zhvilluesit, por nga departamenti i operacioneve pĂ«r menaxhimin e versioneve tĂ« aplikacionit, versioneve tĂ« paketave, monitorimin e gjendjes sĂ« tĂ« gjitha makinave Linux dhe nĂ« tĂ« ruhet receta â tĂ« gjitha manifestet e Puppet.
Puppet â zgjidh tĂ« gjitha çëshjet e kontestueshme dhe dĂ«rgon pikĂ«risht atĂ« konfigurim qĂ« duam, nga GitLab.
Po fillojmë të thellohemi. Si ndodh dorëzimi i DLL në RPM?
Dorëzimi i DDL në RPM
Supozoni se kemi një yll të zhvillimit në .NET. Ai përdor Visual Studio dhe krijon një degë lëshimi. Pas kësaj e ngarkon atë në Git, dhe Git këtu është një entitet TFS, domethënë ky është një repository aplikacioni me të cilin punon zhvilluesi.
Pas kësaj, TFS sheh se ka mbërritur një komit i ri. Cili aplikacion? Në konfigurimet e TFS ka një etiketë se me cilat burime disponon ndonjë Build-agent. Në këtë rast ai sheh se po mbledhim një projekt .NET Core dhe zgjedh Build-agent Linux nga pool-i.
Build-agent merr kodin burimor, shkarkon të nevojshmet varësi nga repository .NET, npm etj. dhe pas ndërtimit të aplikacionit dhe paketimit përkatës dërgon paketën RPM në repository-në RPM.
Nga ana tjetër ndodhin këto. Inxhinieri i departamentit të operacioneve merret drejtpërdrejt me lançimin e projektit: ndryshon versionet e pakove në Hiera në depo, ku ruhet receta e aplikacionit, pas së cilës Puppet aktivizon Yum, e merr paketën e re nga depoja, dhe versioni i ri i aplikacionit është gati për t'u përdorur.
Me fjalë, gjithçka duket e thjeshtë, por çfarë po ndodh brenda në vetë Build-agentin?
Paketimi DLL RPM
Janë marrë burimet e projektit dhe detyra për ndërtimin e tij nga TFS. Build-agenti nisi ndërtimin e projektit nga burimet.Projekti i ndërtuar është i disponueshëm si një shumëllojshmëri të skedarëve DLL, të cilat janë paketuar në një arkiv zip për të ulur ngarkesën në sistemin e skedarëve.
Arkivi ZIP hidhet në direktorinë e ndërtimit të paketës RPM. Pastaj, një skript Bash inicializon variablat e mjedisit, gjen versionin e Build, versionin e projektit, rrugën deri në direktorinë e ndërtimit dhe nis RPM-build. Pas përfundimit të ndërtimit, paketa publikohet në depon lokale, e cila ndodhet në Build-agent.
Më pas, nga Build-agenti në serverin e depo RPM dërgohet një kërkesë JSON. me versionit dhe ndërtimin. Webhook, për të cilin kam folur më parë, shkarkon këtë paketë nga depoja lokale në agentin e Ndërtimit dhe e bën ndërtimin e ri të disponueshëm për instalim.
Pse këtë skemë të dorëzimit të paketave në depozitin RPM? Pse nuk mund të dërgohet direkt paketa e ndërtuar në depo? Arsyetimi është se kjo është një kusht për sigurimin. Ky skenar kufizon mundësinë e ngarkimit të paautorizuar të paketave RPM nga persona të tretë në serverin që është i aksesueshëm për të gjitha makinat Linux.
Versionimi i DB
Në konsultimin me zhvilluesit u zbulua se djemtë preferonin MS SQL, por në shumicën e projekteve non-Windows tashmë e kishim përdorur PostgreSQL. Duke vendosur të heqim dorë nga çdo gjë paguese, filluam të përdorim PostgreSQL edhe këtu.
Në këtë pjesë dëshiroj të tregoj se si realizuam versionimin e DB dhe si zgjodhëm midis Flyway dhe Entity Framework Core. Le të shqyrtojmë përparësitë dhe mangësitë e tyre.
Kundrat
Flyway ecĂ«n vetĂ«m nĂ« njĂ« drejtim, ne nuk mund tĂ« kthehemi mbrapa â Ă«shtĂ« njĂ« disavantazh i rĂ«ndĂ«sishĂ«m. Mund tĂ« krahasohet me Entity Framework Core nĂ« aspekte tĂ« tjera â nga pikĂ«pamja e lehtĂ«sisĂ« pĂ«r zhvilluesit. Ju e dini se ne e kemi vendosur kĂ«tĂ« nĂ« krye tĂ« prioriteteve, dhe kritere themelore ishte qĂ« tĂ« mos ndryshonim asgjĂ« pĂ«r zhvillimin nĂ« Windows.
PĂ«r Flyway na duhej njĂ« lloj mbĂ«shtetjeje, nĂ« mĂ«nyrĂ« qĂ« ekipi tĂ« mos shkruante kĂ«rkesa SQL. Ata janĂ« shumĂ« mĂ« tĂ« afrueshĂ«m tĂ« operojnĂ« nĂ« terma OOP. Shkruan udhĂ«zime pĂ«r punimin me objektet e DB, u formua kĂ«rkesa SQL dhe u ekzekutua. Versioni mĂ« i ri i DB Ă«shtĂ« gati, u testua â gjithçka funksionon.
Entity Framework Core ka njĂ« disavantazh â nĂ« ngarkesa tĂ« mĂ«dha, ai ndĂ«rton kĂ«rkesa SQL jo optimale, dhe rĂ«nia nĂ« DB mund tĂ« jetĂ« e konsiderueshme. Por, duke qenĂ« se nuk kemi njĂ« shĂ«rbim me ngarkesĂ« tĂ« lartĂ«, nuk e llogarisim ngarkesĂ«n nĂ« qindra RPS, ne e pranuam kĂ«tĂ« risk dhe ia deleguam problemin vetes nĂ« tĂ« ardhmen.
PĂ«rfitimet
Entity Framework Core punon jashtë kutisë dhe është i përshtatshëm për zhvillimin, ndërsa Flyway integrohet lehtësisht në CI ekzistues. Por ne po bëjmë gjithçka për t'i bërë gjërat më të lehta zhvilluesve :)
Procedura e kaluar
Puppet sheh se po vjen një ndryshim në versionet e pakove, mes të cilave, ajo që është përgjegjëse për migrimin. Së pari instalon paketën që përmban skriptet e migrimit dhe funksionalitetin e lidhur me DB. Pas kësaj, aplikacioni që punon me DB restartohet. Më pas vazhdon instalimi i komponenteve të tjera. Renditja e instalimit të pakove dhe nisjes së aplikacioneve përshkruhet në manifestin e Puppet.
Aplikacionet përdorin të dhëna të ndjeshme, siç janë tokenat, fjalëkalimet për DB, dhe të gjitha këto tërhiqen në konfigurimin nga Puppet master, ku ato ruhen në formë të enkriptuar.
Problemet TFS
Pas qĂ« u siguruam dhe kuptuam se gjithçka funksionon, vendosa tĂ« shoh se çfarĂ« ndodh me ndĂ«rtimet nĂ« TFS nĂ« pĂ«rgjithĂ«si pĂ«r departamentin e zhvillimit Win pĂ«r projekte tĂ« tjera â nĂ«se po grumbullohemi/shtyjmĂ« shpejt, dhe zbulova probleme tĂ« mĂ«dha me shpejtĂ«sinĂ«.
NjĂ« nga projektet kryesore grumbullohet pĂ«r 12-15 minuta â kjo Ă«shtĂ« shumĂ«, nuk mund tĂ« jetojmĂ« kĂ«shtu. NjĂ« analizĂ« e shpejtĂ« tregoi njĂ« rĂ«nie tĂ« frikshme nĂ« I/O, dhe kjo ndodh nĂ« masiva.
Pas analizĂ«s sĂ« pĂ«rbĂ«rĂ«sve, identifikuam tre epiqendra. E para â «Kaspersky antivirus», i cili skanon kodin nĂ« tĂ« gjithĂ« agjentĂ«t Windows Build. i dyti â Windows Indeksuesi. Ai nuk ishte çaktivizuar, dhe nĂ« agjentĂ«t Build po indeksohej gjithçka nĂ« kohĂ« reale gjatĂ« procesit tĂ« shpĂ«rndarjes.
I treti â Npm install. Doli se nĂ« shumicĂ«n e Pipelines ne e pĂ«rdorim kĂ«tĂ« skenar. ĂfarĂ« Ă«shtĂ« e keqja? Procedura Npm install aktivizohet gjatĂ« formimit tĂ« pemĂ«s sĂ« varĂ«sive nĂ«Â package-lock.json, ku regjistrohen versionet e paketave qĂ« do tĂ« pĂ«rdoren pĂ«r ndĂ«rtimin e projektit. Problemi Ă«shtĂ« se Npm install çdo herĂ« tĂ«rheq versionet e azhurnuara tĂ« paketave nga interneti, dhe kjo merr shumĂ« kohĂ« nĂ« rastin e njĂ« projekti tĂ« madh.
Zhvilluesit ndonjĂ«herĂ« eksperimentohet nĂ« makinĂ«n lokale pĂ«r tĂ« verifikuar funksionimin e njĂ« pjesĂ« tĂ« veçantĂ« ose tĂ«rĂ« projektit. Ndodh ndonjĂ«herĂ« qĂ« lokalisht gjithçka funksionon mirĂ«, por kur e ndĂ«rtuam, nuk punonte asgjĂ«. FillojmĂ« tĂ« kuptojmĂ« se çfarĂ« Ă«shtĂ« problemi â po, versionet e ndryshme tĂ« paketave me varĂ«si.
Zgjidhja
- Burimet në përjashtime AV.
- Ăaktivizimi i indeksimit.
- Kalim në npm ci.
Pikat e forta tĂ« npm ci janĂ« se ne ndĂ«rtojmĂ« pemĂ«n e varĂ«sive njĂ« herĂ«, dhe kemi mundĂ«sinĂ« tâi ofrojmĂ« zhvilluesit njĂ« listĂ« tĂ« azhurnuar paketash, me tĂ« cilin mund tĂ« eksperimentohet pa kufizime nĂ« nivel lokal. Kjo kursehet kohĂ« pĂ«r zhvilluesit qĂ« shkruajnĂ« kod.
Konfigurimi
Tani pak për konfigurimin e repositorit. Historikisht ne përdorim Nexus për menaxhimin e repositorive, duke përfshirë REPO të brendshme. Në këtë repositor të brendshëm, janë dërguar të gjithë komponentët që ne përdorim për qëllime të brendshme, siç janë monitorimet e zhvilluara nga ne vetë.
Ne gjithashtu përdorim NuGet, pasi ai është më i efektshëm në ruajtjen e paketave krahasuar me menaxherët e tjerë të paketave.
Rezultati
Pas optimizimit të agjentëve Build, koha mesatare e ndërtimit u ul nga 12 minuta në 7.
NĂ«se llogarisim tĂ« gjitha makinat qĂ« do tĂ« mund tĂ« pĂ«rdornim pĂ«r Windows, por qĂ« kaluam nĂ« Linux nĂ« kĂ«tĂ« projekt, ne kursejmĂ« rreth $10,000. Dhe kjo Ă«shtĂ« vetĂ«m pĂ«r licencat, e nĂ«se pĂ«rfshijmĂ« kostot e tjera â Ă«shtĂ« mĂ« shumĂ«.
Planet
Në kuadrin e katërti të ardhshëm e kemi planifikuar punën mbi optimizimin e shpërndarjes së kodit.
Kalimi nĂ« imazhin Docker tĂ« paratĂ«suar. TFS Ă«shtĂ« njĂ« gjĂ« e shkĂ«lqyer me shumĂ« plugina qĂ« lejojnĂ« integrimin nĂ« Pipeline, duke pĂ«rfshirĂ« edhe ndĂ«rtimin pĂ«rmes njĂ« trigger-i, pĂ«r shembull, imazhit Docker. Ky trigger ne duam ta bĂ«jmĂ« pĂ«r atĂ« tĂ« njĂ«jtin package-lock.json. NĂ«se ndonjĂ«herĂ« ndryshon pĂ«rbĂ«rja e komponenteve qĂ« pĂ«rdoren pĂ«r ndĂ«rtimin e projektit â ne ndĂ«rtuam njĂ« Docker image tĂ« ri. Ky i fundit pĂ«rdoret mĂ« pas pĂ«r dislokimin e njĂ« konteineri me aplikacionin e ndĂ«rtuar. Aktualisht, nuk e kemi kĂ«tĂ«, por planifikojmĂ« tĂ« kalojmĂ« nĂ« njĂ« arkitekturĂ« mikrosistemesh nĂ« Kubernetes, e cila Ă«shtĂ« duke u zhvilluar aktivisht nĂ« kompaninĂ« tonĂ« dhe ka mbajtur prej kohĂ«sh zgjidhje produksioni.
Curriculum Vitae
I bëj thirrje të gjithëve të heqin dorë nga Windows, por kjo nuk është sepse unë nuk di ta përgatis atë. Arsyeja është se shumica e zgjidhjeve Opensource janë stoku Linux. Do të kursoni mirë në burimet. Në mendimin tim, e ardhmja është me zgjidhje Open Source në Linux me një komunitet të fuqishëm.
Profili i folësit Aleksandër Sinçinov .
 â kjo Ă«shtĂ« njĂ« konferencĂ« pĂ«r integrimin e proceseve tĂ« zhvillimit, testimit dhe operimit pĂ«r profesionistĂ« nga profesionistĂ«t. PikĂ«risht pĂ«r kĂ«tĂ« arsye projekti, pĂ«r tĂ« cilin tregoi Aleksandri, Ă«shtĂ« realizuar dhe funksionon, ndĂ«rsa nĂ« ditĂ«n e fjalimit u realizuan dy lĂ«shime tĂ« suksesshme. NĂ«Â mĂ« 27 dhe 28 maj do tĂ« ketĂ« edhe mĂ« shumĂ« raste tĂ« ngjashme nga praktikanĂ«t. Mund tĂ« hipni nĂ« vagonin e fundit dhe ose ngadalĂ« bileti. Takemi nĂ« Skolkovo!
Burimi: habr.com
