Ne kemi zhvilluar DevOps sa kemi mundur. Ishim 8 persona, dhe Vasja ishte më i shkëlqyeri për Windows. Papritmas Vasja iku, dhe unë mora një sfidë për të nxjerrë në pah një projekt të ri që ofron zhvillim për Windows. Kur hodha në tryezë të gjithë grackën e zhvillimit për Windows, e kuptova se situata ishte e dhimbshme...
Kështu fillon historia Aleksandër Sinçinov në . Kur eksperti kryesor i Windows u largua nga kompania, Aleksandri u pyet se çfarë të bënte tani. Të kalonte në Linux, sigurisht! Aleksandri do të tregojë se si arriti të krijonte një precedent dhe të transferonte një pjesë të zhvillimit për Windows në Linux, duke ilustruar me një projekt të realizuar për 100,000 përdorues të fundit.
Si të dërgosh lehtësisht dhe në mënyrë pa stres projektin në RPM, duke përdorur TFS, Puppet, Linux .NET core? Si të mbash versionimin e DB të projektit, kur zhvilluesit e parë dëgjojnë fjalët Postgres dhe Flyway, dhe data e fundit është nesër? Si të integrosh me Docker? Si të motivojnë zhvilluesit .NET të braktisin Windows-in dhe smoothies për Puppet dhe Linux? Si të zgjidhësh konflikte ideologjike, kur nuk ke as forcë, as dëshirë dhe as burime për të mbështetur Windows në prodhim? Për këtë, si dhe për Web Deploy, testimin, CI, praktikat e përdorimit të TFS në projektet ekzistuese, dhe natyrisht, për këmbët e thyera dhe zgjidhjet që funksionojnë, në transkriptin e fjalimit të Aleksandrit.
Pra, Vasja iku, detyra është në duar të mia, zhvilluesit presin me kazma me padurim. Kur e kuptova përfundimisht se Vasja nuk do të kthehej, fillova punën. Së pari vlerësova përqindjen e Win VM në paradin tonë. Numri nuk ishte në favor të Windows.
Duke qenë se ne po zhvillojmë aktivisht DevOps, e kuptova se duhej të ndryshonim qasjen për lansimin e aplikacionit të ri. Zgjidhja ishte një - sa më shumë që ishte e mundur, të kalonim gjithçka në Linux. Google më ndihmoi - në atë kohë, .Net ishte tashmë portuar në Linux, dhe e kuptova se kjo ishte zgjidhja!
Pse .NET core me Linux?
PĂ«r kĂ«tĂ« kishte disa arsye. NdĂ«rmjet "tĂ« paguash" dhe "tĂ« mos paguash" shumica do tĂ« zgjedhin tĂ« dytĂ«n - si unĂ«. Licenca pĂ«r MSDB kushton rreth 1,000 $, mbĂ«shtetje e parkut tĂ« makinave virtuale Windows arrin qindra dollarĂ«. PĂ«r njĂ« kompani tĂ« madhe, kĂ«to janĂ« shpenzime tĂ« mĂ«dha. Prandaj kursimi â Ă«shtĂ« arsyeja e parĂ«. Nuk Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja, por Ă«shtĂ« njĂ« nga mĂ« tĂ« rĂ«ndĂ«sishmet.
Makinat virtuale Windows ndjekin më shumë burime se vëllezërit e tyre nga Linux - janë më të rheavy. Duke marrë parasysh shkallën e madhe të kompanisë, ne zgjodhëm Linux.
Sistemi thjesht integrohet në CI-në ekzistuese. Ne e shohim veten si DevOps progresiv, përdorim Bamboo, Jenkins dhe GitLab CI, prandaj pjesa më e madhe funksionon në Linux.
Arsyeja e fundit është shoqërimi i lehtë. Na nevojitej të ulte pragun e hyrjes për "shoqëruesit" - djemtë që kuptojnë pjesën teknike, sigurojnë vazhdimësinë dhe mbështesin shërbimet nga niveli i dytë. Ata tashmë ishin të njohur me stakun Linux, prandaj ishte shumë më e lehtë për ta të kuptonin produktin e ri, ta mbanin dhe ta shoqëronin, sesa të shpenzonin burime të tjera për të kuptuar funksionalitetin e 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ë prej tyre ishin të gatshëm për ndryshime, veçanërisht pas fjalës Linux. Zhvilluesit duan Visual Studio të tyren, TFS me teste automatike për ndërtimet dhe smuzi. Si ndodh shpërndarja në prodhim - nuk është e rëndësishme për ta. Prandaj vendosëm të mos ndryshonim procesin e zakonshëm dhe të lëmë gjithçka pa ndryshime për zhvillimin Windows.
Projekti i ri duhet të integrohet në CI-në ekzistuese. Railsat ishin tashmë atje dhe e gjithë puna duhej të kryhej duke marrë parasysh parametrat e sistemit të menaxhimit të konfigurimit, standardet e pranueshme të shpërndarjes dhe sistemet e monitorimit.
Thjeshtësia në mbështetje dhe operim, si kusht për pragun minimal të hyrjes për të gjithë pjesëmarrësit e rinj nga departamente të ndryshme dhe departamenti i mbështetjes.
Afati është - dje.
Grupi i zhvillimit Windows
Me çfarë ka punuar ekipi Windows?
Tani mund të them me siguri se IdentityServer4 është një alternativë e shkëlqyer falas për ADFS me mundësi të ngjashme, ose që Entity Framework Core është një parajsë për zhvilluesin, ku mund të shkruajë kërkesa në DB në termat e OOP pa u shqetësuar për shkruajtjen e skripteve SQL. Por atëherë, gjatë diskutimit të planit të veprimit, e shikoja këtë Stak si shkrim të vjetër, duke njohur vetëm PostgreSQL dhe Git.
Në atë kohë, ne aktivisht përdornim Puppet si sistem menaxhimi të konfiguracionit. Në shumicën e projekteve tona përdorim GitLab CI, Elastic, balancojmë shërbimet me ngarkesa të larta me ndihmën e HAProxy, monitorojmë gjithçka me ndihmën e Zabbix, lidhjeve Nëse tashmë e dini se çfarë është analiza e grupeve dhe se si ta bëni në SQL, kaloni menjëherë në seksionin e fundit. dhe Prometheus, Jaeger, dhe e gjithë kjo funksionon në harduerin HP c ESXi në VMware. Të gjithë e njohin - klasika e zhanrit.
Le të shohim dhe të përpiqemi të kuptojmë se çfarë ndodhi para se të nisim këto përzierje.
ĂfarĂ« ndodhi
TFS Ă«shtĂ« njĂ« sistem mjaft i fuqishĂ«m, i cili jo vetĂ«m qĂ« dĂ«rgon kodin nga zhvilluesi nĂ« makinerinĂ« pĂ«rfundimtare tĂ« prodhimit, por gjithashtu ka njĂ« paketĂ« pĂ«r njĂ« integrim shumĂ« fleksibĂ«l me shĂ«rbime tĂ« ndryshme â pĂ«r tĂ« siguruar CI nĂ« nivelin multi-platformĂ«.
Një herë, kishte vetëm dritare të pafundme. TFS përdorte disa agjentë Build, mbi të cilët grumbulloheshin shumë projekte. Në çdo agjent kishte 3-4 punëtorë për të bërë paralelizmin e detyrave dhe për të optimizuar procesin. Më pas, sipas planeve të lëshimit, TFS dorëzonte një Build të sapogatuar në serverin e aplikacioneve Windows.
ĂfarĂ« donim tĂ« arrinim
Për dërgimin dhe zhvillimin përdorim TFS, ndërsa aplikacionin e aktivizojmë në serverin e aplikacioneve Linux, dhe ndërmjet tyre ndodhin disa magji. Ky Magic Box është thelbi i punës së ardhshme. Para se ta ndajmë atë në pjesë, do të bëj një hap mënjanë dhe do të them dy fjalë mbi aplikacionin.
Projekti
Aplikacioni ofron funksionalitet për operimin e kartave të parapaguara.
Client
Ekzistuan dy lloje përdoruesish. First kishte akses duke u autorizuar me një certifikatë SSL SHA-2. Të të dytë kishte akses me emrin e përdoruesit dhe fjalëkalimin.
HAProxy
Më pas, kërkesa e klientit shkonte në HAProxy, i cili zgjidhte detyrat e mëposhtme:
- autorizimi fillestar;
- terminimi SSL;
- tuning i kërkesave HTTP;
- transmetimi i kërkesave.
Verifikimi i certifikatës së klientit bëhej nëpërmjet zinxhirit. Ne authority dhe mund ta lejojmë një gjë të tillë, pasi ne vetë lëshojmë certifikata për klientët e shërbimit.
Kujdes mbi pikën e tretë, do të kthehemi tek ajo më vonë.
Backend
Backend-in planifikonim ta bëmë në Linux. Backend-i bashkëvepronte me DB, ngarkonte listën e nevojshme të privilegjeve dhe më pas, në përputhje me privilegjet e përdoruesit të autorizuar, jepte 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, me tĂ« cilĂ«t ecin çdo klient, ekzistonte edhe konteksti identity. IdentityServer4 qĂ« pikĂ«risht lejon autorizimin, Ă«shtĂ« njĂ« alternativĂ« falas dhe e fuqishme pĂ«r ADFS â ShĂ«rbimet e FederatĂ«s sĂ« DrejtorisĂ« Aktivitetit.
KĂ«rkesa nĂ« identity pĂ«rpunoheshin nĂ« disa hapa. Hapi i parĂ« â klient shkonte nĂ« backend, i cili shkĂ«mbeu tĂ« dhĂ«na me kĂ«tĂ« server dhe kontrolloi pĂ«r praninĂ« e tokenit pĂ«r klientin. NĂ«se nuk e gjente - kĂ«rkesa kthehej mbrapsht nĂ« kontekstin nga i cili erdhi, por tashmĂ« me njĂ« ridrejtim, dhe me ridrejtim shkonte te 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 ridirektohej mbrapsht në kontekstin nga i cili erdhi.
IdentityServer4 ka një veçori: përgjigjja në kërkesën e kthimit e kthen nëpërmjet HTTP. Pavarësisht se si u përpoqa me konfigurimin e serverit, pavarësisht se sa përmenda dokumentacionin, çdo herë merrnim kërkesën fillestare të klientit me URL, e cila erdhi përmes HTTPS, ndërsa IdentityServer ktheu të njëjtin kontekst, por me HTTP. Ishim të shokuar! Dhe e kaluam gjithë këtë përmes kontekstit të identitetit te HAProxy, dhe në header-at dh obliged më modifikuar protokollin HTTP në HTTPS.
Cila është përmirësimi dhe ku kursyem?
Kursyem para, duke përdorur një zgjidhje falas për autorizimin e grupit të përdoruesve, burimet, pasi nuk e nxorrëm IdentityServer4 si një nod të veçantë në një segment të veçantë, por e përdorëm atë në përputhje me backend-in në të njëjtin server ku funksionon backend-i i aplikacionit.
Si duhet të punojë
Pra, siç e premtova - Magic Box. Tani e kuptojmë se sigurisht po i afrohemi Linux-it. Le të formulojmë detyrat specifike që kërkonin zgjidhje.
Manifestet Puppet. Për të shpërndarë dhe menaxhuar konfigurimin e shërbimit dhe aplikacionit, duhej të shkruhen receta të shkëlqyera. Rul me laps tregon qartë se sa shpejt dhe cilësisht u realizua kjo.
Metoda e shpërndarjes. Standardi është RPM. Të gjithë e dinë se në Linux nuk ka si të ndodhi pa të, por projekti vetë pas ndërtimit përbënte një grup DLL-skedash ekzekutiv. Ishin rreth 150; projekti është mjaft i rëndë. Zgjidhja e vetme harmonike është të paketosh këtë binar në RPM dhe të nisësh aplikacionin nga ajo.
Versionimi. Na nĂ«nĂ«n si do tĂ« lirohemi shumĂ« shpesh, dhe duhej tĂ« vendosnim se si do tĂ« formojmĂ« emrin e paketĂ«s. Ky Ă«shtĂ« njĂ« çështje qĂ« lidhet me integrimin me TFS. Build-agentin e kishim nĂ« Linux. Kur TFS dĂ«rgon njĂ« detyrĂ« nĂ« trajtuesin â worker â nĂ« Build-agent, ai i dĂ«rgon edhe njĂ« grup variablash, tĂ« cilat kalojnĂ« nĂ« ambientin e procesit tĂ« trajtuesit. NĂ« kĂ«to variabla ambienti kalon emri i Build, emri i versionit dhe variabla tĂ« tjera. MĂ« shumĂ« rreth kĂ«saj nĂ« seksionin 'ndĂ«rtimi i paketĂ«s RPM'.
Konfigurimi i TFS u pĂ«rqendrua nĂ« konfigurimin e Pipeline. MĂ« parĂ« ne ndĂ«rtuam tĂ« gjitha projektet Windows nĂ« agentĂ«t Windows, ndĂ«rsa tani po shfaqet agenti Linux â Build-agent, i cili duhet tĂ« pĂ«rfshihet nĂ« grupin e ndĂ«rtimit, tĂ« pasurohet me disa artefakte, tĂ« tregohet se çfarĂ« lloj projektesh do tĂ« ndĂ«rtohet nĂ« kĂ«tĂ« Build-agent, dhe si duhet modifikuar Pipeline.
IdentityServer. ADFS nuk është rruga jonë, mbështesim Open Source.
Le të kalojmë përmes komponenteve.
Magic Box
Përbëhet nga katër pjesë.
Linux Build-agent. Linux, sepse jemi duke ndĂ«rtuar pĂ«r tĂ« â logjikisht. Kjo pjesĂ« u realizua nĂ« tre hapa.
- Të konfiguroni worker-at dhe jo një, pasi parashikohej që të punohet në mënyrë të shpërndarë mbi projektin.
- Instaloni .NET Core 1.x. Pse pikërisht 1.x, kur tashmë është në dispozicion 2.0 në depozitën standarde? Sepse, kur filluam zhvillimin, versioni stabil ishte 1.09, dhe projekti u vendos të bëhej për të.
- Git 2.x.
RPM-depozita. RPM-paketat duhej të ruheshin diku. Parashikohej që ne do të përdorim të njëjtën depo të korporatës RPM, e cila është e qasshme për të gjitha hostet Linux. E bëmë kështu. Në serverin e depozitës është e vendosur webhook i cili shkarkonte paketën RPM të kërkuar nga vendi i caktuar. Versioni i paketës i raportohej webhook-ut nga Build-agent.
GitLab. Kujdes! GitLab kĂ«tu pĂ«rdoret jo nga zhvilluesit, por nga departamenti i operacioneve pĂ«r tĂ« kontrolluar versionet e aplikacionit, versionet e paketave, kontrollin e gjendjes sĂ« tĂ« gjitha makinerive Linux dhe aty ruhet receta â tĂ« gjitha manifestet e Puppet.
Puppet â zgjidh tĂ« gjitha momentet e kontestueshme dhe sjell pikĂ«risht atĂ« konfigurim qĂ« duam, nga GitLab.
Të fillojmë të zhytemi. Si ndodh dërgimi i DLL në RPM?
Dërgimi i DDL në RPM
Supozoni se kemi një rock star zhvillimi 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, dmth kjo është depoja e aplikacionit, me të cilin punon zhvilluesi.
Pas njĂ« moment, TFS sheh se njĂ« komit i ri ka arritur. ĂfarĂ« aplikacioni? NĂ« configurimet TFS ka njĂ« etiketĂ« qĂ« tregon se cilat burime ka ndonjĂ« Build-agent. NĂ« kĂ«tĂ« rast, ai sheh se po ndĂ«rtojmĂ« njĂ« projekt .NET Core dhe zgjidh njĂ« Build-agent Linux nga grupi.
Build-agent merr burimet, shkarkon të nevojshmet dependencies nga repository .NET, npm etj., dhe pas ndërtimit të vetë aplikacionit dhe paketimit të mëpasshëm dërgon paketën RPM në repository-në RPM.
Nga ana tjetër ndodhin gjërat e mëposhtme. Inxhinieri i departamentit të operacioneve merret drejtpërdrejt me përgatitjen e projektit: ndryshon versionet e paketave në Hiera në repository-në ku ruhet receta e aplikacionit, pas së cilës Puppet aktivizon Yum, merr paketën e re nga repository, dhe versioni i ri i aplikacionit është gati për t'u përdorur.
Me fjalë, gjithçka është e thjeshtë, por çfarë ndodh brenda Build-agentit?
Paketimi DLL RPM
Burimet e projektit janë marrë dhe ka një detyrë për ndërtim nga TFS. Build-agent fillon ndërtimin e vetë projektit nga burimet. Projekti i ndërtuar është i disponueshëm në formën e shumë fileve DLL, të cilat janë paketuar në një arkiv zip për të reduktuar ngarkesën në sistemin e skedarëve.
Arkivi ZIP hidhet në direktorinë e ndërtimit të paketës RPM. Pastaj, skripti Bash inicializon variablat e ambientit, gjen versionin e Build, versionin e projektit, rrugën e drejtorisë së ndërtimit dhe aktivizon RPM-build. Pas përfundimit të ndërtimit, paketa publikohet në repository-në lokale, e cila ndodhet në Build-agent.
Pastaj, nga Build-agent në serverin e RPM-repository-së dërgohet një kërkesë JSON me nënshkrimin e emrit të versionit dhe ndërtimit. Webhook, për të cilin kam folur më parë, tërheq këtë paketë nga repository-në lokale në Build-agent dhe e bën ndërtimin e ri të disponueshëm për instalim.
Pse pikĂ«risht ky skemĂ« e shpĂ«rndarjes sĂ« paketave nĂ« repository-nĂ« RPM? Pse nuk mund tĂ« dĂ«rgohet menjĂ«herĂ« paketa e ndĂ«rtuar nĂ« repository? ĂĂ«shtja Ă«shtĂ« se kjo Ă«shtĂ« njĂ« kusht pĂ«r sigurimin e sigurisĂ«. Ky skenar kufizon mundĂ«sinĂ« e ngarkimit tĂ« paautorizuar tĂ« pakove RPM nga persona tĂ« jashtĂ«m nĂ« serverin e cili Ă«shtĂ« i disponueshĂ«m pĂ«r tĂ« gjitha makinat Linux.
Versionimi i DB
Në një konsilium me zhvillimin doli se ekipi preferonte MS SQL, por në shumicën e projekteve non-Windows ne tashmë ishim duke përdorur PostgreSQL. Duke qënë se kemi vendosur të heqim dorë nga çdo gjë me pagesë, filluam të përdorim PostgreSQL edhe këtu.
Në këtë pjesë dua të flas për mënyrën se si ne realizuam versionimin e bazës së të dhënave dhe si vendosëm midis Flyway dhe Entity Framework Core. Le të shohim avantajet dhe disavantazhet e tyre.
Disavantazhet
Flyway shkon vetĂ«m nĂ« njĂ« drejtim, ne nuk mund tĂ« kthehemi prapa â kjo Ă«shtĂ« njĂ« disavantazh i rĂ«ndĂ«sishĂ«m. Krahasimi me Entity Framework Core mund tĂ« bĂ«het sipas parametrave tĂ« tjerĂ« â nga kĂ«ndvĂ«shtrimi i komoditetit pĂ«r zhvilluesin. Ju e mbani mend se ne e vendosĂ«m kĂ«tĂ« nĂ« qendĂ«r tĂ« vĂ«mendjes, dhe kriteri kryesor ishte tĂ« mos ndryshonim asgjĂ« pĂ«r zhvillimin nĂ« Windows.
PĂ«r Flyway na duhej njĂ« lloj mbĂ«shtjellĂ«s, qĂ« djemtĂ« tĂ« mos shkruanin kĂ«rkesa SQL. Ata janĂ« shumĂ« mĂ« afĂ«r tĂ« operojnĂ« nĂ« terma OOP. Krijuam udhĂ«zime pĂ«r tĂ« punuar me objektet e bazĂ«s sĂ« tĂ« dhĂ«nave, kĂ«rkesa SQL u formua dhe u ekzekutua. Versioni i ri i bazĂ«s sĂ« tĂ« dhĂ«nave Ă«shtĂ« gati, kaloi tĂ« gjitha testet â gjithçka Ă«shtĂ« nĂ« rregull, 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Ă« bazĂ«n e tĂ« dhĂ«nave mund tĂ« jetĂ« e konsiderueshme. Por, pasi shĂ«rbimi ynĂ« nuk Ă«shtĂ« me ngarkesĂ« tĂ« lartĂ«, ne nuk e matim ngarkesĂ«n me qindra RPS, pranuam kĂ«to rreziqe dhe deleguam problemin pĂ«r nĂ« tĂ« ardhmen.
Pikat pozitive
Entity Framework Core funksionon nga kutia dhe është i lehtë për zhvilluesit, ndërsa Flyway integrohet lehtësisht në CI e ekzistueshme. Por ne po bëjmë gjithçka të lehtë për zhvilluesit :)
Procedura e instalimit
Puppet sheh që po vjen një ndryshim versioni të paketave, përfshirë atë që është përgjegjës për migrimin. Fillimisht instalon paketën, ku ndodhen skriptet e migrimit dhe funksionaliteti i lidhur me bazën e të dhënave. Pas kësaj, aplikacioni që punon me bazën e të dhënave rindez. Më pas vazhdon instalimin e komponenteve të tjera. Renditja e instalimit të paketave dhe hapjes së aplikacioneve është e përshkruar në manifestin e Puppet.
Aplikacionet përdorin të dhëna të ndjeshme, siç janë tokenët, fjalëkalimet për bazën e të dhënave, të gjitha këto tërhiqen në konfigurimin me Puppet master, ku ato ruhen në formë të enkriptuar.
Problemet TFS
Pas pĂ«rcaktimit dhe kuptimit se gjithçka funksionon siç duhet, vendosa tĂ« shoh çfarĂ« po ndodhte me ndĂ«rtimet nĂ« TFS nĂ« pĂ«rgjithĂ«si pĂ«r departamentin e zhvillimit tĂ« Windows pĂ«r projekte tĂ« tjera â nĂ«se po ndĂ«rtojmĂ« / publikojmĂ« shpejt, dhe zbulova probleme tĂ« konsiderueshme me shpejtĂ«sinĂ«.
NjĂ« nga projektet kryesore ndĂ«rtohet pĂ«r 12-15 minuta â kjo Ă«shtĂ« shumĂ«, nuk mund tĂ« jetojmĂ« kĂ«shtu. NjĂ« analizĂ« e shpejtĂ« tregoi njĂ« rĂ«nien tĂ« tmerrshme nĂ« I/O, dhe kjo na masivizet.
Pas njĂ« analize komponenti pĂ«r komponent, identifikova tre pika tĂ« nxehta. E para â «Kaspersky antivirus», i cili skanon burimet nĂ« tĂ« gjitha agjentĂ«t Windows Build. Tjetri â Windows Indexer. Ai nuk ishte çaktivizuar dhe gjithçka u indeksua nĂ« kohĂ« reale nĂ« agjentĂ«t Build gjatĂ« procesit tĂ« shpĂ«rndarjes.
TĂ« tretin â Npm install. Doli se nĂ« shumicĂ«n e Pipelines ne pĂ«rdornim pikĂ«risht kĂ«tĂ« skenar. Cila Ă«shtĂ« e keqja? Procedura e Npm install fillon 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. Minus Ă«shtĂ« se Npm install çdo herĂ« merr versionet aktuale tĂ« paketave nga interneti, dhe kjo zĂ« kohĂ« tĂ« konsiderueshme nĂ« rastin e njĂ« projekti tĂ« madh.
Krijuesit ndonjĂ«herĂ« eksperimentojnĂ« nĂ« makinĂ«n lokale pĂ«r tĂ« kontrolluar funksionimin e njĂ« pjese tĂ« veçantĂ« ose tĂ« tĂ«rĂ« projektit. NdonjĂ«herĂ« ndodhte qĂ« lokalish everything is cool, por kur e ndĂ«rtuam, gjĂ«rat nuk funksiononin. FillojmĂ« tĂ« marrim vesh se cila Ă«shtĂ« problemi â aha, versionet e ndryshme tĂ« paketave me varĂ«si.
Zgjidhja
- Burimet në përjashtimet AV.
- Ăaktivizimi i indeksimit.
- Kalimi 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ë ofrojmë zhvilluesit një listë aktuale të paketave, me të cilën ai mund të eksperimentojë sa të dëshirojë lokalisht. Kjo kursehet kohë për zhvilluesit që shkruajnë kod.
Konfigurimi
Tani pak për konfigurimin e depozitës. Historikisht ne përdorim Nexus për menaxhimin e depozitave, duke përfshirë Internal REPO. Në këtë depo të brendshme dërgohen të gjitha komponentët që ne përdorim për qëllime të brendshme, për shembull, monitorimet e krijuara vetë.
Ne gjithashtu përdorim NuGet, pasi ai cache më mirë krahasuar me menaxherët e tjerë të paketave.
Rezultati
Pas optimizimit të agjentëve Build, koha mesatare e ndërtimit është ulur nga 12 minuta në 7.
NĂ«se llogaritim tĂ« gjitha makinat qĂ« mund tĂ« pĂ«rdornim pĂ«r Windows, por i kaluam nĂ« Linux nĂ« kĂ«tĂ« projekt, ne kursyem rreth $10,000. Dhe kjo Ă«shtĂ« vetĂ«m pĂ«r licencat, pĂ«r mĂ« tepĂ«r duke marrĂ« parasysh mbajtjen â mĂ« shumĂ«.
Planet
Për kvartalin e ardhshëm kemi planifikuar punën në optimizimin e shpërndarjes së kodit.
Kalimi nĂ« njĂ« imazh Docker tĂ« pregatitur. TFS Ă«shtĂ« njĂ« gjĂ« e shkĂ«lqyer me shumĂ« plugins qĂ« lejojnĂ« integrimin nĂ« Pipeline, duke pĂ«rfshirĂ« ndĂ«rtimin nĂ«pĂ«rmjet njĂ« nxitĂ«si, le tĂ« themi, imazhit Docker. Ky nxitĂ«s do tĂ« dojemi tĂ« bĂ«jmĂ« nĂ« atĂ« tĂ« djathĂ« package-lock.json. NĂ«se ndodhi qĂ« ndĂ«rron pĂ«rbĂ«rja e komponenteve qĂ« pĂ«rdoren pĂ«r ndĂ«rtimin e projektit â ne krijojmĂ« njĂ« imazh tĂ« ri Docker. MĂ« pas, ky imazh pĂ«rdoret pĂ«r tĂ« shpĂ«rndarĂ« njĂ« kontejner me aplikacionin e ndĂ«rtuar. Tani kjo nuk ekziston, por planifikojmĂ« tĂ« kalojmĂ« nĂ« njĂ« arkitekturĂ« mikroshĂ«rbimesh nĂ« Kubernetes, i cili po zhvillohet aktivisht nĂ« kompaninĂ« tonĂ« dhe pĂ«r shumĂ« kohĂ« ka shĂ«rbyer pĂ«r zgjidhje nĂ« prodhim.
CV
I bĂ«j thirrje tĂ« gjithĂ«ve tĂ« heqin dorĂ« nga Windows, por kjo nuk Ă«shtĂ« sepse nuk di ta pĂ«rgatis. Arsyeja Ă«shtĂ« se pjesa mĂ« e madhe e zgjidhjeve Opensource â kjo Ă«shtĂ« stogu Linux. Do tĂ« kurseni burime nĂ« mĂ«nyrĂ« tĂ« konsiderueshme.Sipas mendimit tim, e ardhmja Ă«shtĂ« te zgjidhjet Open Source mbi Linux me njĂ« komunitet tĂ« fuqishĂ«m.
Profili i folësit Aleksandër Sinçinov .
 është një konferencë mbi integrimin e proceseve të zhvillimit, testimit dhe funksionimit për profesionistë nga profesionistët. Pikërisht për këtë arsye, projekti, për të cilin foli Aleksandri, është realizuar dhe funkcional, dhe në ditën e prezantimit janë bërë dy lëshime të suksesshme. Në në 27 dhe 28 maj do të ketë edhe më shumë raste të ngjashme nga praktikuesit. Ka ende kohë për të hipur në vagoni i fundit dhe ose me qetësi bileti. Do të takohemi në Skolkovo!
Burimi: habr.com
