Binuo namin ang DevOps sa abot ng aming makakaya. May 8 sa amin, at si Vasya ang pinaka-cool sa Windows. Biglang umalis si Vasya, at nagkaroon ako ng gawain na maglunsad ng isang bagong proyekto na ibinibigay ng pag-unlad ng Windows. Nang itapon ko ang buong Windows development stack sa mesa, napagtanto ko na ang sitwasyon ay masakit...
Ganito nagsimula ang kwento Alexandra Sinchinova sa . Nang umalis sa kumpanya ang nangungunang espesyalista sa Windows, nag-isip si Alexander kung ano ang gagawin ngayon. Lumipat sa Linux, siyempre! Sasabihin sa iyo ni Alexander kung paano niya nagawang gumawa ng precedent at ilipat ang bahagi ng Windows development sa Linux gamit ang halimbawa ng isang nakumpletong proyekto para sa 100 end user.
Paano madali at walang kahirap-hirap maghatid ng proyekto sa RPM gamit ang TFS, Puppet, Linux .NET core? Paano susuportahan ang bersyon ng isang database ng proyekto kung marinig ng development team ang mga salitang Postgres at Flyway sa unang pagkakataon, at ang deadline ay kinabukasan? Paano isama sa Docker? Paano mag-udyok sa mga developer ng .NET na talikuran ang Windows at smoothies pabor sa Puppet at Linux? Paano malutas ang mga salungatan sa ideolohiya kung walang lakas, o pagnanais, o mga mapagkukunan upang mapanatili ang Windows sa produksyon? Tungkol dito, pati na rin ang tungkol sa Web Deploy, pagsubok, CI, tungkol sa mga kasanayan sa paggamit ng TFS sa mga umiiral na proyekto, at, siyempre, tungkol sa mga sirang saklay at mga solusyon sa pagtatrabaho, sa transcript ng ulat ni Alexander.
Kaya, umalis si Vasya, ang gawain ay nasa akin, ang mga developer ay naghihintay nang walang pasensya sa mga pitchforks. Nang sa wakas ay napagtanto kong hindi na maibabalik si Vasya, bumaba ako sa negosyo. Upang magsimula, tinasa ko ang porsyento ng mga Win VM sa aming fleet. Ang marka ay hindi pabor sa Windows.
Dahil aktibo kaming gumagawa ng DevOps, napagtanto ko na may kailangang baguhin sa diskarte sa paghahatid ng bagong application. Mayroon lamang isang solusyon - kung maaari, ilipat ang lahat sa Linux. Tinulungan ako ng Google - sa oras na iyon ang .Net ay nai-port na sa Linux, at napagtanto ko na ito ang solusyon!
Bakit .NET core kasabay ng Linux?
Mayroong ilang mga dahilan para dito. Sa pagitan ng "magbayad ng pera" at "hindi magbayad", pipiliin ng karamihan ang pangalawa - tulad ko. Ang isang lisensya para sa MSDB ay nagkakahalaga ng humigit-kumulang $1; ang pagpapanatili ng isang fleet ng Windows virtual machine ay nagkakahalaga ng daan-daang dolyar. Para sa isang malaking kumpanya ito ay isang malaking gastos. kaya lang ipon - unang dahilan. Hindi ang pinakamahalaga, ngunit isa sa mga makabuluhan.
Ang mga virtual machine ng Windows ay kumukuha ng mas maraming mapagkukunan kaysa sa kanilang mga kapatid sa Linux - mabigat sila. Dahil sa laki ng malaking kumpanya, pinili namin ang Linux.
Ang sistema ay isinama lamang sa umiiral na CI. Itinuturing namin ang aming sarili na mga progresibong DevOps, gumagamit kami ng Bamboo, Jenkins at GitLab CI, kaya karamihan sa aming trabaho ay tumatakbo sa Linux.
Ang huling dahilan ay maginhawang saliw. Kinailangan naming ibaba ang hadlang sa pagpasok para sa mga "escorts"βang mga lalaking nakakaunawa sa teknikal na bahagi, tinitiyak ang tuluy-tuloy na serbisyo, at nagpapanatili ng mga serbisyo mula sa pangalawang linya. Pamilyar na sila sa Linux stack, kaya mas madali para sa kanila na maunawaan, suportahan at mapanatili ang isang bagong produkto kaysa gumastos ng karagdagang mga mapagkukunan upang maunawaan ang parehong pag-andar ng software para sa Windows platform.
Kinakailangan sa
Unang una sa lahat - kaginhawaan ng bagong solusyon para sa mga developer. Hindi lahat ng mga ito ay handa para sa pagbabago, lalo na pagkatapos ng salitang Linux ay binibigkas. Gusto ng mga developer ang kanilang paboritong Visual Studio, ang TFS na may mga autotest para sa mga assemblies at smoothies. Kung paano nangyayari ang paghahatid sa produksyon ay hindi mahalaga sa kanila. Samakatuwid, nagpasya kaming huwag baguhin ang karaniwang proseso at iwanan ang lahat na hindi nagbabago para sa pagbuo ng Windows.
Kailangan ng bagong proyekto isama sa umiiral na CI. Ang mga riles ay naroon na at ang lahat ng trabaho ay kailangang gawin na isinasaalang-alang ang mga parameter ng sistema ng pamamahala ng pagsasaayos, tinatanggap na mga pamantayan sa paghahatid at mga sistema ng pagsubaybay.
Dali ng suporta at operasyon, bilang isang kondisyon para sa minimum na limitasyon ng pagpasok para sa lahat ng mga bagong kalahok mula sa iba't ibang dibisyon at departamento ng suporta.
Deadline - kahapon.
Win Development Group
Ano ang ginagawa ng Windows team noon?
Ngayon ay buong kumpiyansa kong masasabi iyon IdentityServer4 ay isang cool na libreng alternatibo sa ADFS na may katulad na mga kakayahan, o ano Entity Framework Core - isang paraiso para sa isang developer, kung saan hindi mo kailangang mag-abala sa pagsulat ng mga SQL script, ngunit ilarawan ang mga query sa database sa mga terminong OOP. Ngunit pagkatapos, sa panahon ng talakayan ng plano ng aksyon, tiningnan ko ang stack na ito na parang Sumerian cuneiform, na kinikilala lamang ang PostgreSQL at Git.
Sa oras na iyon kami ay aktibong gumagamit Puppet bilang isang sistema ng pamamahala ng pagsasaayos. Sa karamihan ng aming mga proyekto ay ginamit namin GitLab CI, Nababanat, balanseng mga serbisyong may mataas na karga gamit ang HAProxy sinusubaybayan ang lahat ng may Zabbix, ligaments grafana ΠΈ Promiteyus, Snayper, at ang lahat ng ito ay umiikot sa mga piraso ng bakal HP c ESXi sa VMware. Alam ng lahat ito - isang klasiko ng genre.
Tingnan natin at subukang maunawaan kung ano ang nangyari bago natin simulan ang lahat ng mga interbensyon na ito.
Anong nangyari
Ang TFS ay isang medyo makapangyarihang sistema na hindi lamang naghahatid ng code mula sa developer hanggang sa panghuling production machine, ngunit mayroon ding set para sa napaka-flexible na pagsasama sa iba't ibang serbisyo - upang magbigay ng CI sa cross-platform na antas.
Dati, ito ay mga solidong bintana. Gumamit ang TFS ng ilang ahente ng Build, na ginamit para mag-assemble ng maraming proyekto. Ang bawat ahente ay may 3-4 na manggagawa upang iparallelize ang mga gawain at i-optimize ang proseso. Pagkatapos, ayon sa mga plano sa pagpapalabas, inihatid ng TFS ang bagong lutong Build sa Windows application server.
Ano ang nais nating makamit?
Ginagamit namin ang TFS para sa paghahatid at pagpapaunlad, at pinapatakbo ang application sa isang server ng Linux Application, at mayroong ilang uri ng mahika sa pagitan nila. Ito Magic box at nariyan ang asin ng gawain sa hinaharap. Bago ko ito paghiwalayin, tumabi ako at magsasabi ng ilang salita tungkol sa aplikasyon.
Proyekto
Ang application ay nagbibigay ng functionality para sa paghawak ng mga prepaid card.
Kliente
Mayroong dalawang uri ng mga gumagamit. Muna nakakuha ng access sa pamamagitan ng pag-log in gamit ang SSL SHA-2 certificate. U ang pangalawa nagkaroon ng access gamit ang login at password.
HAProxy
Pagkatapos ang kahilingan ng kliyente ay napunta sa HAProxy, na nalutas ang mga sumusunod na problema:
- pangunahing awtorisasyon;
- Pagwawakas ng SSL;
- pag-tune ng mga kahilingan sa HTTP;
- mga kahilingan sa broadcast.
Ang sertipiko ng kliyente ay na-verify sa kahabaan ng chain. Kami - kapangyarihan at kakayanin namin ito, dahil kami mismo ang naglalabas ng mga sertipiko sa mga kliyente ng serbisyo.
Bigyang-pansin ang ikatlong punto, babalikan natin ito mamaya.
backend
Pinlano nilang gawin ang backend sa Linux. Nakikipag-ugnayan ang backend sa database, naglo-load ng kinakailangang listahan ng mga pribilehiyo at pagkatapos, depende sa kung anong mga pribilehiyo ang mayroon ang awtorisadong user, ay nagbibigay ng access upang pumirma sa mga dokumentong pinansyal at ipadala ang mga ito para sa pagpapatupad, o bumuo ng ilang uri ng ulat.
Pagtitipid gamit ang HAProxy
Bilang karagdagan sa dalawang konteksto na na-navigate ng bawat kliyente, mayroon ding konteksto ng pagkakakilanlan. IdentityServer4 pinapayagan ka lang na mag-log in, ito ay isang libre at malakas na analogue para sa ADFS - Mga Aktibong Serbisyo sa Directory ng Federation.
Ang kahilingan sa pagkakakilanlan ay naproseso sa ilang hakbang. Unang hakbang - kostumer pumasok sa backend, na nakipag-ugnayan sa server na ito at sinuri ang pagkakaroon ng isang token para sa kliyente. Kung hindi ito natagpuan, ibinalik ang kahilingan sa konteksto kung saan ito nanggaling, ngunit may pag-redirect, at sa pag-redirect ay napunta ito sa pagkakakilanlan.
Pangalawang hakbang - natanggap ang kahilingan sa pahina ng pahintulot sa IdentityServer, kung saan nakarehistro ang kliyente, at ang pinakahihintay na token ay lumitaw sa database ng IdentityServer.
Ikatlong hakbang - ang kliyente ay na-redirect pabalik sa kontekstong pinanggalingan nito.
Ang IdentityServer4 ay may tampok: ibinabalik nito ang tugon sa kahilingan sa pagbabalik sa pamamagitan ng HTTP. Gaano man kami nahirapan sa pagse-set up ng server, gaano man namin naliwanagan ang aming sarili sa dokumentasyon, sa tuwing nakatanggap kami ng paunang kahilingan ng kliyente na may URL na dumating sa pamamagitan ng HTTPS, at ibinalik ng IdentityServer ang parehong konteksto, ngunit sa HTTP. Nagulat kami! At inilipat namin ang lahat ng ito sa pamamagitan ng konteksto ng pagkakakilanlan sa HAProxy, at sa mga header kailangan naming baguhin ang HTTP protocol sa HTTPS.
Ano ang improvement at saan ka nakatipid?
Nakatipid kami ng pera sa pamamagitan ng paggamit ng libreng solusyon para sa pagpapahintulot sa isang pangkat ng mga user, mga mapagkukunan, dahil hindi namin inilagay ang IdentityServer4 bilang isang hiwalay na node sa isang hiwalay na segment, ngunit ginamit ito kasama ng backend sa parehong server kung saan tumatakbo ang backend ng application. .
Paano ito dapat gumana
Kaya, tulad ng ipinangako ko - Magic Box. Nauunawaan na namin na garantisadong kami ay tutungo sa Linux. Bumuo tayo ng mga tiyak na gawain na nangangailangan ng mga solusyon.
Puppet manifests. Upang maihatid at mapamahalaan ang configuration ng serbisyo at application, kailangang magsulat ng mga cool na recipe. Ang isang rolyo ng lapis ay mahusay na nagpapakita kung gaano kabilis at kahusay ito ginawa.
Paraan ng paghahatid. Ang pamantayan ay RPM. Naiintindihan ng lahat na sa Linux hindi mo magagawa nang wala ito, ngunit ang proyekto mismo, pagkatapos ng pagpupulong, ay isang hanay ng mga maipapatupad na DLL file. Mayroong tungkol sa 150 sa kanila, ang proyekto ay medyo mahirap. Ang tanging maayos na solusyon ay i-package ang binary na ito sa RPM at i-deploy ang application mula dito.
Pag-bersyon. Kailangan naming i-release nang madalas, at kailangan naming magpasya kung paano bubuo ang pangalan ng package. Ito ay isang katanungan ng antas ng pagsasama sa TFS. Nagkaroon kami ng build agent sa Linux. Kapag ang TFS ay nagpadala ng isang gawain sa isang handler - manggagawa - sa Build agent, ipinapasa din nito ang isang grupo ng mga variable na napupunta sa kapaligiran ng proseso ng handler. Ang mga variable ng kapaligiran na ito ay naglalaman ng pangalan ng Build, pangalan ng bersyon, at iba pang mga variable. Magbasa pa tungkol dito sa seksyong "Pagbuo ng RPM package".
Pag-set up ng TFS bumaba sa pag-set up ng Pipeline. Dati, kinolekta namin ang lahat ng proyekto ng Windows sa mga ahente ng Windows, ngunit ngayon ay may lumalabas na ahente ng Linux - isang ahente ng Build, na kailangang isama sa grupo ng build, na pinayaman ng ilang artifact, at sinabi kung anong uri ng mga proyekto ang itatayo sa ahente ng Build na ito. , at kahit papaano ay baguhin ang Pipeline.
IdentityServer. ADFS ay hindi ang aming paraan, kami ay pupunta para sa Open Source.
Tingnan natin ang mga bahagi.
Magic box
Binubuo ng apat na bahagi.
ahente ng Linux Build. Linux, dahil binuo namin ito - ito ay lohikal. Ang bahaging ito ay ginawa sa tatlong hakbang.
- I-configure ang mga manggagawa at hindi nag-iisa, dahil ang ipinamahagi na gawain sa proyekto ay inaasahan.
- I-install ang .NET Core 1.x. Bakit 1.x kapag ang 2.0 ay magagamit na sa karaniwang repositoryo? Dahil noong sinimulan namin ang pag-develop, ang stable na bersyon ay 1.09, at napagpasyahan na gawin ang proyekto batay dito.
- Git 2.x.
RPM-imbakan. Ang mga pakete ng RPM ay kailangang maimbak sa isang lugar. Ipinapalagay na gagamitin namin ang parehong corporate RPM repository na available sa lahat ng Linux host. Ganun ang ginawa nila. Ang repository server ay na-configure web hook na nag-download ng kinakailangang RPM package mula sa tinukoy na lokasyon. Ang bersyon ng package ay iniulat sa webhook ng ahente ng Build.
GitLab. Pansin! Ang GitLab dito ay hindi ginagamit ng mga developer, ngunit ng operations department upang kontrolin ang mga bersyon ng application, mga bersyon ng package, subaybayan ang status ng lahat ng Linux machine, at iniimbak nito ang recipe - lahat ng Puppet manifests.
Puppet β niresolba ang lahat ng kontrobersyal na isyu at naghahatid ng eksaktong configuration na gusto namin mula sa Gitlab.
Nagsisimula kaming mag-dive. Paano gumagana ang paghahatid ng DLL sa RPM?
Paghahatid ng DDL sa RPM
Sabihin nating mayroon tayong .NET development rock star. Gumagamit ito ng Visual Studio at lumilikha ng isang sangay ng paglabas. Pagkatapos nito, ina-upload ito sa Git, at ang Git dito ay isang entity ng TFS, iyon ay, ito ay ang application repository kung saan gumagana ang developer.
Pagkatapos nito, nakita ng TFS na may dumating na bagong commit. Aling app? Sa mga setting ng TFS mayroong isang label na nagsasaad kung anong mga mapagkukunan ang mayroon ang isang partikular na ahente ng Build. Sa kasong ito, nakikita niya na gumagawa kami ng .NET Core na proyekto at pumipili ng ahente ng Linux Build mula sa pool.
Ang ahente ng Build ay tumatanggap ng mga mapagkukunan at nagda-download ng kinakailangan dependencies mula sa .NET repository, npm, atbp. at pagkatapos buuin ang application mismo at ang kasunod na packaging, ipapadala ang RPM package sa RPM repository.
Sa kabilang banda, ang mga sumusunod ay nangyayari. Direktang kasangkot ang operations department engineer sa paglulunsad ng proyekto: binago niya ang mga bersyon ng mga package sa Hiera sa repository kung saan naka-imbak ang recipe ng application, pagkatapos nito ay nag-trigger ang Puppet Yum, kinukuha ang bagong package mula sa repository, at handa nang gamitin ang bagong bersyon ng application.
Ang lahat ay simple sa mga salita, ngunit ano ang nangyayari sa loob mismo ng Build agent?
Packaging DLL RPM
Nakatanggap ng mga mapagkukunan ng proyekto at bumuo ng gawain mula sa TFS. Bumuo ng ahente nagsisimula sa pagbuo ng proyekto mismo mula sa mga mapagkukunan. Ang binuong proyekto ay magagamit bilang isang set DLL file, na naka-package sa isang zip archive upang bawasan ang pagkarga sa file system.
Ang ZIP archive ay itinapon sa RPM package build directory. Susunod, sinisimulan ng Bash script ang mga variable ng kapaligiran, hinahanap ang bersyon ng Build, ang bersyon ng proyekto, ang landas patungo sa direktoryo ng build, at pinapatakbo ang RPM-build. Kapag kumpleto na ang build, mai-publish ang package sa lokal na imbakan, na matatagpuan sa ahente ng Build.
Susunod, mula sa Build agent hanggang sa server sa RPM repository Ipinadala ang kahilingan ng JSON na nagpapahiwatig ng pangalan ng bersyon at build. Ang Webhook, na napag-usapan ko kanina, ay nagda-download ng mismong paketeng ito mula sa lokal na imbakan sa ahente ng Build at ginagawang magagamit ang bagong pagpupulong para sa pag-install.
Bakit ang partikular na scheme ng paghahatid ng package sa RPM repository? Bakit hindi ko maipadala agad ang naka-assemble na pakete sa repositoryo? Ang katotohanan ay ito ay isang kondisyon para sa pagtiyak ng kaligtasan. Nililimitahan ng sitwasyong ito ang posibilidad ng mga hindi awtorisadong tao na mag-upload ng mga RPM packages sa isang server na naa-access sa lahat ng Linux machine.
Pag-bersyon ng database
Sa isang konsultasyon sa pangkat ng pag-unlad, lumabas na ang mga lalaki ay mas malapit sa MS SQL, ngunit sa karamihan ng mga proyektong hindi Windows ginagamit na namin ang PostgreSQL nang buong lakas. Dahil napagpasyahan na naming iwanan ang lahat ng binayaran, sinimulan naming gamitin ang PostgreSQL dito rin.
Sa bahaging ito gusto kong sabihin sa iyo kung paano namin nilagyan ng bersyon ang database at kung paano namin pinili sa pagitan ng Flyway at Entity Framework Core. Tingnan natin ang kanilang mga kalamangan at kahinaan.
Cons
Isang paraan lang ang pupuntahan ng Flyway, kami hindi tayo makakabalik - ito ay isang makabuluhang kawalan. Maaari mo itong ihambing sa Entity Framework Core sa ibang mga paraan - sa mga tuntunin ng kaginhawaan ng developer. Naaalala mo na inilalagay namin ito sa unahan, at ang pangunahing pamantayan ay hindi baguhin ang anuman para sa pagbuo ng Windows.
Para sa amin ng Flyway ilang uri ng pambalot ang kailanganpara hindi magsulat ang mga lalaki Mga query sa SQL. Mas malapit sila sa pagpapatakbo sa mga tuntunin ng OOP. Nagsulat kami ng mga tagubilin para sa pagtatrabaho sa mga object ng database, nakabuo ng isang SQL query at naisakatuparan ito. Ang bagong bersyon ng database ay handa na, nasubok - lahat ay maayos, lahat ay gumagana.
Ang Entity Framework Core ay may minus - sa ilalim ng mabibigat na pagkarga nito bumubuo ng mga suboptimal na query sa SQL, at ang drawdown sa database ay maaaring maging makabuluhan. Ngunit dahil wala kaming serbisyong may mataas na karga, hindi namin kinakalkula ang pagkarga sa daan-daang RPS, tinanggap namin ang mga panganib na ito at ipinagkatiwala ang problema sa hinaharap sa amin.
Pros
Entity Framework Core gumagana sa labas ng kahon at madaling i-develop, at Flyway Madaling isinasama sa umiiral na CI. Ngunit ginagawa namin itong maginhawa para sa mga developer :)
Roll-up na pamamaraan
Nakikita ng puppet na may paparating na pagbabago sa bersyon ng package, kasama ang isa na responsable para sa paglipat. Una, nag-i-install ito ng package na naglalaman ng mga migration script at functionality na nauugnay sa database. Pagkatapos nito, ang application na gumagana sa database ay restart. Susunod ay ang pag-install ng mga natitirang bahagi. Ang pagkakasunud-sunod kung saan naka-install ang mga pakete at inilunsad ang mga application ay inilarawan sa manifest ng Puppet.
Gumagamit ang mga application ng sensitibong data, tulad ng mga token, mga password sa database, lahat ng ito ay nakuha sa config mula sa Puppet master, kung saan naka-imbak ang mga ito sa naka-encrypt na form.
Mga problema sa TFS
Pagkatapos naming magpasya at mapagtanto na ang lahat ay talagang gumagana para sa amin, nagpasya akong tingnan kung ano ang nangyayari sa mga pagtitipon sa TFS sa kabuuan para sa departamento ng pag-unlad ng Win sa iba pang mga proyekto - kung kami ay nagtatayo/naglalabas nang mabilis o hindi, at nakatuklas ng mga makabuluhang problema sa bilis.
Ang isa sa mga pangunahing proyekto ay tumatagal ng 12-15 minuto upang mag-assemble - iyon ay mahabang panahon, hindi ka mabubuhay nang ganoon. Ang isang mabilis na pagsusuri ay nagpakita ng isang kahila-hilakbot na drawdown sa I/O, at ito ay sa mga array.
Pagkatapos pag-aralan ito ng bahagi sa pamamagitan ng bahagi, nakilala ko ang tatlong foci. Una - "Kaspersky antivirus", na nag-scan ng mga source sa lahat ng Windows Build agent. Pangalawa - Windows Indexer. Hindi ito na-disable, at lahat ay na-index nang real time sa mga ahente ng Build sa panahon ng proseso ng pag-deploy.
pangatlo - Pag-install ng Npm. Lumalabas na sa karamihan ng Pipelines ginamit namin ang eksaktong senaryo na ito. Bakit siya masama? Ang pamamaraan ng pag-install ng Npm ay pinapatakbo kapag nabuo ang dependency tree package-lock.json, kung saan ang mga bersyon ng mga pakete na gagamitin sa pagbuo ng proyekto ay naitala. Ang downside ay ang pag-install ng Npm ay kumukuha ng mga pinakabagong bersyon ng mga pakete mula sa Internet sa bawat oras, at ito ay tumatagal ng maraming oras sa kaso ng isang malaking proyekto.
Minsan nag-eeksperimento ang mga developer sa isang lokal na makina upang subukan kung paano gumagana ang isang partikular na bahagi o buong proyekto. Minsan lumalabas na ang lahat ay cool na lokal, ngunit binuo nila ito, inilunsad ito, at walang gumana. Nagsisimula kaming malaman kung ano ang problema - oo, iba't ibang mga bersyon ng mga pakete na may mga dependency.
desisyon
- Mga pinagmulan sa AV exception.
- Huwag paganahin ang pag-index.
- Pumunta sa npm ci.
Ang mga pakinabang ng npm ci ay tayo Kinokolekta namin ang dependency tree nang isang beses, at nakakakuha kami ng pagkakataong ibigay ang developer kasalukuyang listahan ng mga pakete, kung saan maaari siyang mag-eksperimento nang lokal hangga't gusto niya. Ito nakakatipid ng oras mga developer na nagsusulat ng code.
Configuration
Ngayon ng kaunti tungkol sa pagsasaayos ng imbakan. Makasaysayang ginagamit natin Koneksyon para sa pamamahala ng mga repositoryo, kabilang ang Panloob na REPO. Ang panloob na imbakan na ito ay naglalaman ng lahat ng mga sangkap na ginagamit namin para sa mga panloob na layunin, halimbawa, self-written na pagsubaybay.
Ginagamit din namin NuGet, dahil mayroon itong mas mahusay na pag-cache kumpara sa ibang mga manager ng package.
Resulta
Pagkatapos naming i-optimize ang Build Agents, ang average na oras ng build ay binawasan mula 12 minuto hanggang 7.
Kung bibilangin namin ang lahat ng machine na maaari sana naming gamitin para sa Windows, ngunit lumipat sa Linux sa proyektong ito, nakatipid kami ng humigit-kumulang $10. At iyon ay sa mga lisensya lamang, at higit pa kung isasaalang-alang namin ang nilalaman.
Mga Plano
Para sa susunod na quarter, nagplano kaming magtrabaho sa pag-optimize ng paghahatid ng code.
Lumipat sa isang prebuild na larawan ng Docker. Ang TFS ay isang cool na bagay na may maraming mga plugin na nagbibigay-daan sa iyong isama sa Pipeline, kasama ang trigger-based na pagpupulong ng, halimbawa, isang imahe ng Docker. Gusto naming gawin itong trigger para sa parehong isa package-lock.json. Kung magbabago ang komposisyon ng mga bahaging ginamit sa pagbuo ng proyekto, bumuo kami ng bagong imahe ng Docker. Ito ay ginagamit sa ibang pagkakataon upang i-deploy ang lalagyan na may naka-assemble na application. Hindi ito ang kaso ngayon, ngunit pinaplano naming lumipat sa isang arkitektura ng microservice sa Kubernetes, na aktibong umuunlad sa aming kumpanya at naghahatid ng mga solusyon sa produksyon sa loob ng mahabang panahon.
Buod
Hinihikayat ko ang lahat na itapon ang Windows, ngunit hindi ito dahil hindi ako marunong magluto nito. Ang dahilan ay ang karamihan sa mga solusyon sa Opensource ay Linux stack. ayos ka lang ba makatipid sa mga mapagkukunan. Sa aking opinyon, ang hinaharap ay kabilang sa mga solusyon sa Open Source sa Linux na may isang malakas na komunidad.
Profile ng tagapagsalita ni Alexander Sinchinov .
ay isang kumperensya sa pagsasama-sama ng mga proseso ng pag-unlad, pagsubok at pagpapatakbo para sa mga propesyonal ng mga propesyonal. Kaya pala ang project na pinag-usapan ni Alexander? ipinatupad at gumagana, at sa araw ng pagtatanghal mayroong dalawang matagumpay na paglabas. Naka-on Sa Mayo 27 at 28 ay magkakaroon pa ng mga katulad na kaso mula sa mga practitioner. Maaari ka pa ring tumalon sa huling karwahe at o maglaan ng oras tiket. Kilalanin kami sa Skolkovo!
Pinagmulan: www.habr.com