U rapportu parlerà di alcune pratiche DevOps, ma da u puntu di vista di u sviluppatore. Di genere, tutti l'ingegneri chì si uniscenu à DevOps anu digià parechji anni di sperienza amministrativa sottu a so cintura. Ma questu ùn significa micca chì ùn ci hè micca locu per u sviluppatore quì. A più spessu, i sviluppatori sò occupati à riparà "u prossimu bug criticu urgente di u ghjornu", è ùn anu micca u tempu di fà ancu un sguardu rapidu à u campu DevOps. In l'intelligenza di l'autore, DevOps hè, prima, u sensu cumunu. Siconda, hè una opportunità per esse più efficace. Sè vo site un sviluppatore, avete u sensu cumunu è vulete esse più efficace cum'è un ghjucatore di squadra, stu rapportu hè per voi.
Lasciami presentà, ammettu cumplettamente chì ci sò persone in a stanza chì ùn mi cunnosci micca. Mi chjamu Anton Boyko, sò un Microsoft Azure MVP. Cosa hè MVP? Questu hè Model-View-Presenter. Model-View-Presenter hè esattamente mè.
Inoltre, aghju attualmente u postu di architettu di suluzione in Ciklum. È pocu pocu aghju compru un duminiu cusì bellu, è aghju aghjurnatu u mo email, chì di solitu mostra in presentazioni. Pudete scrive à mè à: me [dog] byokoant.pro. Pudete email cù e dumande. Di solitu li rispondi. L'unicu hè chì ùn vogliu micca riceve dumande per email chì riguardanu dui temi : a pulitica è a religione. Pudete scrive à mè nantu à tuttu u restu per email. Passarà un pocu di tempu, risponderaghju.
Uni pochi parolle nantu à sè stessu:
- Sò in questu campu dapoi 10 anni.
- Aghju travagliatu in Microsoft.
- Sò u babbu fundatore di a cumunità ucraina Azure, chì avemu fundatu in qualchì locu in 2014. È l'avemu sempre è l'avemu sviluppatu.
- Sò ancu u babbu di u fundatore di a cunferenza Azure, chì avemu ospitu in Ucraina.
- Aghju ancu aiutu à urganizà u Global Azure Bootcamp in Kiev.
- Comu aghju dettu, sò un Microsoft Azure MVP.
- Parlu in cunferenze abbastanza spessu. Mi piace veramente parlà à e cunferenze. In l'annu passatu, aghju pussutu fà circa 40 volte. Se passate per l'Ucraina, Bielorussia, Pulonia, Bulgaria, Svezia, Danimarca, Paesi Bassi, Spagna o dà o pigliate un altru paese in Europa, allora hè abbastanza pussibule chì quandu andate à una cunferenza chì hà un tema di nuvola in u so flussu, pudete vede chì sò nantu à a lista di parlanti.
- Sò ancu un fan di Star Trek.
Parlemu un pocu di Agenda. A nostra Agenda hè assai simplice:
- Parleremu di ciò chì DevOps hè. Parlemu perchè questu hè impurtante. Nanzu, DevOps era una chjave chì avete scrittu annantu à u vostru curriculum vitae è hà ricevutu immediatamente + $ 500 in salariu. Avà avete bisognu di scrive, per esempiu, blockchain in u vostru curriculum vitae per ottene + 500 dollars à u vostru salariu.
- È dopu, quandu avemu capitu un pocu di ciò chì questu hè, parlemu di ciò chì sò e pratiche DevOps. Ma micca tantu in u cuntestu di DevOps in generale, ma di quelli pratichi DevOps chì puderanu esse di interessu à i sviluppatori. Vi dicu perchè puderanu esse d'interessu per voi. Vi dicu perchè duvete fà questu in tuttu è cumu pò aiutà vi sperienze menu dolore.
Un ritrattu tradiziunale chì parechje persone mostranu. Questu hè ciò chì succede in parechji prughjetti. Questu hè quandu avemu dipartimenti di sviluppu è operazioni chì sustenenu u nostru software. E sti dipartimenti ùn cumunicanu micca cù l'altri.
Forse, se ùn erate micca capaci di sente cusì chjaramente in i dipartimenti DevOps è operazioni, pudete fà una analogia cù i dipartimenti Dev è QA. Ci sò persone chì sviluppanu software è ci sò persone QA chì sò cattivi da u puntu di vista di i sviluppatori. Per esempiu, aghju impegnatu u mo codice meraviglioso à u repository, è ci hè un cane à pusà quì chì mi torna stu codice è dice chì u vostru codice hè male.
Tuttu chistu succede perchè e persone ùn si cumunicanu micca cù l'altri. È si lancianu qualchì pacchettu, qualchì applicazione l'un à l'altru attraversu qualchì muru di malintesi è pruvate à fà qualcosa cun elli.
Hè precisamente stu muru chì a cultura DevOps hè pensata à distrughje, i.e. furzà a ghjente à cumunicà cù l'altri è almenu capisce ciò chì e diverse persone in u prugettu facenu è perchè u so travagliu hè impurtante.
È quandu parlemu di DevOps, qualchissia vi diciarà chì DevOps hè quandu u prughjettu hà integrazione cuntinua; qualcunu dicerà chì DevOps hè se u prughjettu implementa a pratica di "infrastruttura cum'è codice"; qualcunu diciarà chì u primu passu à DevOps hè a ramificazione di e caratteristiche, i bandieri di funziunalità.
Essenzialmente, questu hè tuttu veru in u so modu. Ma questi sò solu l'ultime pratiche chì avemu. Prima di passà à sti pratichi, vi suggerenu di vede sta diapositiva, chì mostra e tappe 3 di implementà a metodulugia Dev-Ops in u vostru prughjettu, in a vostra cumpagnia.
Questa slide hà ancu un secondu nome non ufficiale. Pudete cercà in ligna per sapè ciò chì sò i 3 Musketeers di DevOps. Hè pussibule chì truverete stu articulu. Perchè 3 moschettieri ? Sottu si dice: persone, prucessi è prudutti, i.e. PPP - Porthos, Porthos è Porthos. Eccu i 3 moschettieri di DevOps. Questu articulu descrive in più detail perchè questu hè impurtante è ciò chì implica.
Quandu avete principiatu à implementà una cultura DevOps, hè assai impurtante chì hè implementata in l'ordine seguente.
In principiu, avete bisognu di parlà cù e persone. È avete bisognu di spiegà à e persone ciò chì hè è cumu si ponu uttene qualchì benefiziu da questu.
A nostra cunferenza hè chjamata DotNet Fest. E cum'è l'urganizatori m'hà dettu, avemu principarmenti invitatu un publicu di sviluppatori quì, cusì speru chì a maiò parte di e persone in a sala sò implicati in u sviluppu.
Parleremu di e persone, parleremu di ciò chì i sviluppatori volenu fà ogni ghjornu. Chì volenu più ? Vulenu scrive un novu codice, utilizate frameworks novi, creanu novi funziunalità. Ciò chì i sviluppatori volenu menu? Fix vechji bugs. Spergu chì d'accordu cun mè. Questu hè ciò chì i sviluppatori volenu. Vulenu scrive novi funziunalità, ùn volenu micca risolve i bug.
U nùmeru di bug chì un sviluppatore particulari pruduci dipende da quantu sò dritti i so braccia è quantu crescenu da e so spalle, è micca da i so butt. Ma in ogni casu, quandu avemu un grande prughjettu, qualchì volta succede chì hè impussibile di seguità di tuttu, per quessa, saria bellu per noi di utilizà qualchi approcci chì ci aiutanu à scrive un codice più stabile è di qualità più altu.
Chì volenu più QA? Ùn sò micca s'ellu sò in a sala. Hè difficiuli di dì chì vogliu un QA, perchè ùn aghju mai statu unu. È senza offensione à i picciotti, si dicerà chì spergu chì ùn aghju mai. Ma micca per u mutivu chì mi cunsiderà u so travagliu senza significatu è inutile, ma perchè ùn mi cunsiderà micca una persona chì puderia fà stu travagliu in modu efficiente, per quessa ùn aghju micca ancu pruvà à fà. Ma da ciò chì aghju capitu, ciò chì QA ùn piace u più hè di travaglià in a matina, cuntinueghja à eseguisce qualchì tipu di teste di regressione, pisendu nantu à i stessi bug chì anu signalatu à i sviluppatori 3 sprints fà è dicendu: "Quandu vulete , Monsieur D 'Artagnan, ripara stu bug.' E monsieur d'Artagnan li rispondi : « Iè, iè, iè, l'aghju digià riparatu. E cumu succede chì aghju correttu un bug è fattu 5 in a strada.
E persone chì sustenenu sta suluzione in a pruduzzione volenu chì sta suluzione funziona senza bugs, per ùn avè micca bisognu di reboot u servitore ogni vennari, quandu tutti i persone nurmali vanu à u bar. I sviluppatori dispiegati u venneri, l'amministratori si sentenu finu à u sabbatu, circannu di ottene sta implementazione è riparata.
È quandu spiegà à e persone chì sò destinati à risolve i stessi prublemi, pudete passà à formalizà i prucessi. Hè assai impurtante. Perchè? Perchè quandu dicemu "furmalizazione", hè impurtante per voi di discrive cumu i vostri prucessi si trovanu almenu in un locu nantu à un napkin. Avete bisognu di capisce chì sè, per esempiu, implementate in un ambiente QA o un ambiente di produzzione, allora sempre succede in questu ordine; in queste tappe, eseguimu, per esempiu, teste di unità automatiche è teste UI. Dopu a implementazione, verificamu s'ellu hè andatu bè o male. Ma avete digià una lista chjara di l'azzioni chì deve esse ripetuta una volta è una volta quandu avete implementatu à a produzzione.
È solu quandu i vostri prucessi sò formalizzati, avete principiatu à selezziunà i prudutti chì vi aiutanu à automatizà sti prucessi.
Sfurtunatamente, vecu assai spessu chì questu succede in reverse. Appena qualcunu sente a parolla "DevOps", suggerisce immediatamente l'installazione di Jenkins, perchè crede chì appena installate Jenkins, avarà DevOps. Hanu installatu Jenkins, leghje l'articuli "Cumu" nantu à u situ web di Jenkins, anu pruvatu à inserisce i prucessi in questi How to articuli, è dopu ghjuntu à a ghjente è hà piegatu a ghjente, dicendu chì u libru dice chì avete bisognu di fà cusì. cusì facemu cusì.
Ùn hè micca chì Jenkins hè un cattivu strumentu. Ùn vogliu micca dì chì in ogni modu. Ma questu hè solu unu di i prudutti. E quale pruduttu utilizate deve esse a vostra ultima decisione, è micca u vostru primu. U vostru pruduttu ùn deve esse guidatu da l'implementazione di a cultura è l'approcciu. Questu hè assai impurtante per capiscenu, per quessa, aghju passatu tantu tempu nantu à sta slide è spiegà tuttu questu per tantu tempu.
Parlemu di e pratiche DevOps in generale. Chì sò? Chì ghjè a diffarenza ? Cumu pruvà li? Perchè sò impurtanti?
A prima pratica chì pudete avè intesu parlà hè chjamata Integrazione Continua. Forsi qualchissia nantu à u prugettu hà Integrazione Continua (CI).
U prublema più grande hè chì u più spessu quandu dumandu à una persona: "Avete CI nantu à u prugettu?" è ellu dice: "Iè", allora quandu mi dumandu ciò chì face, mi descriva assolutamente tuttu u prucessu d'automatizazione. Questu ùn hè micca veramente veru.
In fatti, a pratica di CI hè solu destinata à integrà u codice chì e diverse persone scrivenu in un tipu di basa di codice unicu. Eccu tuttu.
Inseme à CI, ci sò di solitu altre pratiche in u caminu - cum'è Implementazione Continua, Gestione di Liberazione, ma ne parlemu più tardi.
CI stessu ci dice chì e diverse persone scrivenu codice è questu codice deve esse integratu continuamente in una sola basa di codice.
Chì ci dà questu è perchè hè impurtante? Se avemu DotNet, allora hè bonu, hè una lingua compilata, pudemu cumpilà a nostra applicazione. S'ellu compile, allora questu hè digià un bonu signu. Questu ùn significa micca nunda, ma hè u primu signu bonu chì pudemu almenu cumpilà.
Allora pudemu eseguisce qualchi teste, chì hè ancu una pratica separata. I testi sò tutti verdi - questu hè u sicondu bonu signu. Ma dinò, questu ùn significa nunda.
Ma perchè fà questu? Tutte e pratiche chì parraraghju oghje portanu apprussimatamente u listessu valore, vale à dì circa i stessi benefici è sò ancu misurati apprussimatamente u listessu modu.
Prima, vi permette di accelerà a consegna. Cumu questu permette di accelerà a spedizione? Quandu facemu qualchì novu cambiamenti à a nostra basa di codice, pudemu immediatamente pruvà à fà qualcosa cù stu codice. Ùn aspittemu micca chì ghjovi vene perchè ghjovi l'avemu liberatu à QA Environment, u facemu quì è quì.
Vi dicu una storia trista di a mo vita. Era assai tempu fà, quandu era sempre ghjovanu è bellu. Avà sò digià ghjovanu, bellu è intelligente, è modestu. Qualchì tempu fà era in un prughjettu. Avemu avutu una grande squadra di circa 30 sviluppatori. È avemu avutu un grande, grande prughjettu di l'Intrapresa chì hà sviluppatu per circa 10 anni. È avemu avutu diverse rami. In u repositoriu avemu avutu un ramu in quale i sviluppatori caminavanu. È ci era un ramu chì mostrava a versione di u codice chì hè in pruduzzione.
U ramu di pruduzzione era 3 mesi daretu à u ramu chì era dispunibule per i sviluppatori. Chì significa questu? Questu significa chì quandu aghju avutu un bug in qualchì locu chì và à a produzzione per culpa di i sviluppatori, perchè l'anu permessu, è per via di a culpa di QA, perchè l'anu guardatu, allora questu significa chì si riceve un compitu per l'hotfix per a produzzione, allora aghju da rinvià i mo cambiamenti di codice 3 mesi fà. Aghju da ricurdà ciò ch'e aghju avutu 3 mesi fà è pruvate à riparà quì.
Se ùn avete micca avutu sta sperienza, pudete pruvà à u vostru prughjettu di casa. A cosa principal hè, ùn pruvate micca in un cummerciale. Scrivite un paru di linee di codice, scurdate di elli per sei mesi, è dopu vultate è pruvate à spiegà rapidamente ciò chì sò e linee di codice è cumu pudete riparà o ottimisimu. Hè una sperienza assai, assai eccitante.
Se avemu una pratica di Integrazione Continua, allora questu ci permette di verificà cù una quantità di arnesi automatizati ghjustu quì è avà, appena aghju scrittu u mo codice. Questu ùn mi darà micca a stampa completa, ma quantunque, sguasserà almenu alcuni di i risichi. È s'ellu ci hè un bug potenziale, l'aghju da sapè avà, vale à dì, literalmente in un paru di minuti. Ùn aghju micca bisognu di retrocede 3 mesi. Solu bisognu di retrocede 2 minuti. Una bona macchina di caffè ùn avarà mancu tempu per fà u caffè in 2 minuti, cusì hè bellu bellu.
Questu hà u valore chì si pò esse ripetutu tempu dopu volta in ogni prughjettu, i.e. micca solu quellu chì avete stallatu. Pudete ripetiri tramindui a pratica stessa è u CI stessu serà ripetutu per ogni novu cambiamentu chì fate à u prugettu. Questu permette di ottimisà e risorse perchè u vostru squadra travaglia in modu più efficace. Ùn averete più una situazione induve un bug vene à voi da u codice chì avete travagliatu 3 mesi fà. Ùn averete più u cambiamentu di u cuntestu quandu site à pusà è passanu e prime duie ore per pruvà à capisce ciò chì hè accadutu allora è entra in l'essenza di u cuntestu prima di cumincià à curreghje qualcosa.
Cumu pudemu misurà u successu o fallimentu di sta pratica? Se rapportate à u big boss ciò chì avemu implementatu nantu à u prughjettu CI, sente bla bla bla. L'avemu implementatu, OK, ma perchè, chì ci hà purtatu à noi, cumu a misuramu, cumu l'implementemu currettamente o incorrectamente?
U primu hè chì, grazia à CI, pudemu implementà più è più spessu, è più spessu precisamente perchè u nostru codice hè potenzalmentu più stabile. In u listessu modu, u nostru tempu per truvà un errore hè ridutta è u tempu per correggerà stu errore hè ridutta precisamente perchè avemu ricevutu una risposta da u sistema ghjustu quì è avà, ciò chì hè sbagliatu cù u nostru codice.
Un'altra pratica chì avemu hè a pratica di Testing Automation, chì più spessu vene cù a pratica CI. Vannu a manu.
Cosa hè impurtante di capisce quì? Hè impurtante di capisce chì i nostri testi sò diffirenti. È ogni teste automatizatu hè destinatu à risolve i so prublemi. Avemu, per esempiu, teste di unità chì ci permettenu di pruvà un modulu separatamente, i.e. Cumu travaglia in un vacuum? Questu hè bonu.
Avemu dinò testi d'integrazione chì ci permettenu di capiscenu cumu i diversi moduli s'integranu cù l'altri. Hè ancu bè.
Pudemu avè testi d'automatizazione UI chì ci permettenu di verificà quantu u travagliu cù l'UI risponde à certi requisiti stabiliti da u cliente, etc.
I testi specifichi chì eseguite ponu influenzà a frequenza di eseguite. I testi di unità sò generalmente scritti brevi è chjuchi. È ponu esse lanciati regularmente.
Se parlemu di testi d'automatizazione UI, allora hè bonu se u vostru prughjettu hè chjucu. I vostri testi d'automatizazione di l'UI ponu piglià un pocu tempu. Ma di solitu una prova d'automatizazione UI hè qualcosa chì dura parechje ore nantu à un grande prughjettu. È hè bonu s'ellu hè uni pochi d'ore. L'unicu cosa hè chì ùn ci hè nunda di eseguisce per ogni custruzzione. Hè sensu per eseguisce di notte. È quandu tutti sò ghjunti à u travagliu in a matina: i testatori è i sviluppatori, anu ricivutu un tipu di rapportu chì avemu eseguitu l'autotest di l'UI di notte è ottene sti risultati. È quì, una ora di travagliu di un servitore chì verificarà chì u vostru pruduttu risponde à certi requisiti serà assai più prezzu di una ora di travagliu di u stessu ingegnere QA, ancu s'ellu hè un ingegnere QA Junior chì travaglia per l'alimentariu è grazie. Tuttu u listessu, una ora di funziunamentu di a macchina serà più prezzu. Hè per quessa chì hè sensu d'investisce in questu.
Aghju un altru prughjettu chì aghju travagliatu. Avemu avutu duie settimane di sprint nantu à stu prughjettu. U prughjettu era grande, impurtante per u settore finanziariu, è ùn pudia micca esse sbagliatu. È dopu un sprint di duie settimane, u ciculu di sviluppu hè statu seguitu da un prucessu di teste, chì hà pigliatu altre 4 settimane. Pruvate imagine a scala di a tragedia. Scrivemu u codice per duie simane, dopu facemu à CodeFreeze, u pacchetemu in una nova versione di l'applicazione, è u stendemu à i tester. Testers a prova per altre 4 settimane, i.e. Mentre a prova, avemu u tempu di preparà duie versioni più per elli. Questu hè un casu veramente tristu.
È li avemu dettu chì sè vo vulete esse più pruduttivu, hè sensu per voi per implementà e pratiche di Testing Automatizatu, perchè questu hè ciò chì vi ferisce quì, avà.
Praticà u Impulsu Cuntinuu. Grande, avete fattu custruisce. Questu hè digià bonu. U vostru codice hè cumpilatu. Avà saria bellu di implementà sta custruzzione in qualchì ambiente. Dicemu in un ambiente per i sviluppatori.
Perchè hè impurtante? Prima, pudete vede quantu avete successu cù u prucessu di implementazione stessu. Aghju scontru prughjetti cum'è questu, quandu dumandu: "Cumu implementate una nova versione di l'applicazione?", i picciotti mi dicenu: "Avemu assemblatu è imballatu in un archiviu zip. Mandemu à l'amministratore per mail. L'amministratore scarica è espansione stu archiviu. È tuttu l'uffiziu cumencia à pricà chì u servitore ripiglià a nova versione ".
Cuminciamu cù qualcosa simplice. Per esempiu, anu scurdatu di mette CSS in l'archiviu o si sò scurdatu di cambià l'hashtag in u nome di u schedariu java-script. È quandu facemu una dumanda à u servitore, u navigatore pensa chì hà digià stu schedariu java-script è decide di ùn scaricà micca. È ci era una versione vechja, qualcosa mancava. In generale, ci ponu esse assai prublemi. Per quessa, a pratica di u Cuntinuu Deployment permette di pruvà almenu ciò chì succede si pigliate una maghjina di riferimentu pulita è l'avete caricata in un ambiente novu completamente pulitu. Pudete vede induve questu porta.
Inoltre, quandu avete integrate u codice trà l'altri, i.e. trà u cumandamentu, questu permette ancu di vede cumu si vede nantu à l'UI.
Unu di i prublemi chì si trovanu induve assai vanilla java-script hè utilizatu hè chì dui sviluppatori dichjaravanu bruscamente una variabile cù u listessu nome in l'ughjettu di a finestra. È dopu, secondu a vostra furtuna. Quale u schedariu java-script hè sguassatu secondu, soprascriverà i cambiamenti di l'altru. Hè ancu assai eccitante. Entri: una cosa travaglia per una persona, un altru ùn funziona micca per un altru. È hè "meraviglioso" quandu tuttu esce in produzzione.
A prussima pratica chì avemu hè a pratica di Restaurazione Automatica, vale à dì torna à a versione precedente di l'applicazione.
Perchè hè questu impurtante per i sviluppatori? Ci sò sempre quelli chì si ricordanu di l'anni 90 distanti, distanti, quandu l'urdinatori eranu grandi è i prugrammi eranu chjuchi. È l'unicu modu per u sviluppu web era attraversu PHP. Ùn hè micca chì PHP hè una lingua cattiva, ancu s'ellu hè.
Ma u prublema era diversu. Quandu avemu implementatu una nova versione di u nostru situ php, cumu l'avemu implementatu? A maiò spessu avemu apertu Far Manager o qualcosa altru. È caricate sti schedari à FTP. È avemu capitu di colpu chì avemu avutu un picculu bug, per esempiu, avemu scurdatu di mette un puntu e virgola o scurdatu di cambià a password per a basa di dati, è ci hè una password per a basa di dati, chì hè nantu à l'ospitu lucale. È decidemu di cunnette rapidamente à FTP è edità i fugliali quì. Questu hè solu u focu! Questu hè ciò chì era populari in l'anni 90.
Ma, sè ùn avete micca guardatu u calendariu, l'anni 90 eranu quasi 30 anni fà. Avà tuttu succede un pocu sfarente. E pruvate d'imaginà a scala di a tragedia quandu vi dicenu: "Avemu implementatu à a produzzione, ma qualcosa ùn hè andatu male. Eccu u vostru login FTP è password, cunnettate à a produzzione è riparate rapidamente quì ". Sè vo site Chuck Norris, questu funzionerà. Se no, allora risicate chì, se fate un bug, fate più 10. Hè precisamente per quessa chì sta pratica di rinvià à a versione precedente permette di ottene assai.
Ancu s'è qualcosa di male hè ghjuntu in pruduzzione in qualchì locu, allora hè male, ma micca fatale. Pudete retrocede à a versione precedente chì avete. Chjamate una copia di salvezza, se hè più faciule per percive in quella terminologia. Pudete retrocede à sta versione precedente, è l'utilizatori puderanu ancu travaglià cù u vostru pruduttu, è avete un tempu di buffer adattatu. Pudete tranquillamente, senza fretta, piglià tuttu questu è pruvà in u locu, riparà, è poi carica una nova versione. Hè veramente sensu di fà questu.
Avà pruvemu à unisce in qualchì modu e duie pratiche precedenti. Averemu un terzu chjamatu Release Management.
Quandu parlemu di u Cuntinuu Deployment in a so forma classica, dicemu chì duvemu tirà u codice da qualchì ramu da u repository, compilà è implementà. Hè bonu se avemu u listessu ambiente. Se avemu parechji ambienti, questu significa chì avemu da tirà u codice ogni volta, ancu da u listessu cummit. U tiraremu fora ogni volta, a custruiremu ogni volta è l'avemu implementatu in un novu ambiente. Prima, questu hè u tempu, perchè per custruisce un prughjettu, se tenete un grande è vinutu da l'anni 90, pò piglià parechje ore.
D’altronde, ci hè un’altra tristezza. Quandu custruite, ancu nantu à a listessa macchina, custruite e stesse fonti, ùn avete sempre guarantisci chì sta macchina hè in u stessu statu chì era durante l'ultima custruzzione.
Diciamu chì qualcunu hè ghjuntu è aghjurnatu DotNet per voi o, à u cuntrariu, qualchissia hà decisu di sguassà qualcosa. È dopu avete una dissonanza cognitiva chì da questu impegnu duie settimane fà custruiamu una custruzzione è tuttu andava bè, ma avà pare chì a listessa macchina, u listessu cummit, u listessu codice chì avemu pruvatu à custruisce, ma ùn hè micca travagliatu. . Avete da trattà cun questu per un bellu pezzu è ùn hè micca un fattu chì avete da capisce. À u minimu, vi sguassate assai i vostri nervi.
Dunque, a pratica di Release Management suggerisce l'introduzione di una astrazione addiziale chjamata un repository d'artefacti o una galleria o una biblioteca. Pudete chjamà ciò chì vulete.
L'idea principale hè chì appena avemu qualchì tipu di impegnu, per dì, in un ramu chì simu pronti à implementà in i nostri diversi ambienti, cullemu l'applicazioni da questu impegnu è tuttu ciò chì avemu bisognu per questa applicazione, l'imballemu. in un archiviu zip è salvallu in qualchì almacenamentu affidabile. È da questu almacenamentu pudemu uttene stu archiviu zip in ogni mumentu.
Allora u pigliemu è u implementemu automaticamente in l'ambiente dev. Corsemu quì, è se tuttu hè bonu, allora ci sparghjemu à u palcuscenicu. Se tuttu hè bè, allora implementemu u stessu archiviu à a pruduzzione, i stessi binari, compilati una sola volta.
Inoltre, quandu avemu una galeria cum'è questu, ci aiuta ancu à affruntà i risichi chì avemu indirizzatu nantu à l'ultima slide quandu avemu parlatu di rollback à a versione precedente. Se avete implementatu accidintali qualcosa di sbagliatu, pudete sempre piglià qualsiasi altra versione precedente da questa galleria è dispiegà in questi ambienti in u listessu modu. Questu permette di rinvià facilmente à a versione precedente se qualcosa va male.
Ci hè un altru grande pratica. Tù è tutti capiscenu chì quandu avemu retrocede e nostre applicazioni à una versione precedente, questu pò significà chì avemu ancu bisognu di l'infrastruttura di a versione precedente.
Quandu parlemu di l'infrastruttura virtuale, assai persone pensanu chì questu hè qualcosa chì l'amministratori stallanu. È se avete bisognu, per dì, per uttene un novu servitore nantu à quale vulete pruvà una nova versione di a vostra applicazione, allora deve scrive un bigliettu à l'amministratori o devops. Devops piglià 3 settimane per questu. È dopu à 3 settimane vi diceranu chì avemu stallatu una macchina virtuale per voi, cù un core, dui gigabyte di RAM è un servitore Windows senza DotNet. Dite: "Ma vulia DotNet". Iddi: "Ok, torna in 3 settimane".
L'idea hè chì utilizendu l'Infrastruttura cum'è pratiche di Codice, pudete trattà a vostra infrastruttura virtuale cum'è una altra risorsa.
Forse, se qualchissia di voi sviluppa applicazioni in DotNet, pudete avè intesu parlà di una biblioteca chjamata Entity Framework. È pudete ancu avè intesu chì Entity Framework hè unu di l'approcciu chì Microsoft hè attivamente spinta. Per travaglià cù una basa di dati, questu hè un approcciu chjamatu Code First. Questu hè quandu descrive in codice cumu vulete chì a vostra basa di dati pare. E poi implementate l'applicazione. Cunnette à a basa di dati, ellu stessu determina quali tavule sò quì è quali tavule ùn sò micca, è crea tuttu ciò chì avete bisognu.
Pudete fà u listessu cù a vostra infrastruttura. Ùn ci hè micca differenza trà s'ellu avete bisognu di una basa di dati per un prughjettu o s'ellu avete bisognu di un servitore Windows per un prughjettu. Hè solu una risorsa. È pudete automatizà a creazione di sta risorsa, pudete automatizà a cunfigurazione di sta risorsa. Dunque, ogni volta chì vulete pruvà un novu cuncettu, un novu approcciu, ùn avete micca bisognu di scrive un bigliettu à i devops, pudete simpricimenti implementà una infrastruttura isolata per sè stessu da mudelli pronti, da scripts pronti è implementà. quì tutti i vostri esperimenti. Pudete sguassate questu, uttene qualchi risultati è rappurtate più nantu à questu.
A prussima pratica, chì esiste ancu è hè ancu impurtante, ma chì pocu persone utilizanu, hè u Monitoring Performance di l'Applicazione.
Vuliu dì solu una cosa nantu à u Monitoring Performance di l'Applicazione. Cosa hè u più impurtante di sta pratica? Questu hè ciò chì u Monitoraghju di Prestazione di l'Applicazione hè quasi uguale à riparà un appartamentu. Questu ùn hè micca un statu finali, hè un prucessu. Avete bisognu di fà regularmente.
In un bonu modu, saria bonu per realizà u Monitoraghju di u Prestazione di l'Applicazione in quasi ogni custruzzione, ancu s'è, cum'è capite, questu ùn hè micca sempre pussibule. Ma, à u minimu, deve esse realizatu per ogni liberazione.
Perchè hè impurtante? Perchè s'è vo sperimentà subitu una calata in u rendiment, allura vi tocca à capisce chjaramente perchè. Se u vostru squadra hà, per esempiu, sprints di duie settimane, allora almenu una volta ogni duie simane duvete implementà a vostra applicazione à un servitore separatu, induve avete un processore chjaramente fissatu, RAM, dischi, etc. È eseguite quelli stessi testi di rendiment. . Avete u risultatu. Vede cumu hè cambiatu da u sprint precedente.
È s'è scuprete chì u drawdown hè cascatu bruscamente in qualchì locu, significarà chì era solu per via di i cambiamenti chì sò accaduti in l'ultime duie settimane. Questu permetterà di identificà è risolve u prublema assai più veloce. È dinò, queste sò quasi i stessi metrichi per quale pudete misurà quantu successu l'avete fattu.
A prussima pratica chì avemu hè a pratica di Gestione di cunfigurazione. Ci sò assai pochi chì piglianu questu seriu. Ma crede mi, questu hè veramente una cosa assai seria.
Ci hè stata una storia divertente recentemente. I picciotti sò ghjunti à mè è mi dissenu: "Aiutateci à fà un auditu di sicurezza di a nostra applicazione". Avemu guardatu u codice inseme per un bellu pezzu, m'anu dettu di l'applicazione, disegnu diagrammi. È più o minus tuttu era logicu, capiscibile, sicuru, ma ci era unu MA ! Anu avutu i schedarii di cunfigurazione in u so cuntrollu di fonte, cumpresi quelli di a produzzione cù a basa di dati IP, cù logins è password per cunnette à queste basa di dati, etc.
E dicu: "Ragazzi, va bè, avete chjusu u vostru ambiente di produzzione cù un firewall, ma u fattu chì avete u login è a password per a basa di dati di produzzione ghjustu in u cuntrollu di a fonte è qualsiasi sviluppatore pò leghje hè digià un grande risicu di sicurezza. . È ùn importa quantu hè super sicura a vostra applicazione da u puntu di vista di u codice, se a lasciate in u cuntrollu di a fonte, allora ùn passerete mai alcuna verificazione in ogni locu. Hè ciò chì parlu.
Gestione di a cunfigurazione. Pudemu avè diverse cunfigurazioni in diversi ambienti. Per esempiu, pudemu avè diversi logins è password per basa di dati per QA, demo, ambiente di produzzione, etc.
Sta cunfigurazione pò ancu esse automatizata. Hè sempre esse separatu da l'applicazione stessa. Perchè? Perchè avete custruitu l'applicazione una volta, è dopu l'applicazione ùn importa micca se cunnette à u servitore SQL per via di una tale è una IP o una tale IP, deve travaglià u listessu. Dunque, s'ellu di colpu unu di voi hè sempre hardcoding a stringa di cunnessione in u codice, allora ricordate chì vi truveraghju è punisci se vi truvate in u stessu prughjettu cun mè. Questu hè sempre postu in una cunfigurazione separata, per esempiu, in web.config.
E sta cunfigurazione hè digià gestita separatamente, vale à dì questu hè esattamente u mumentu quandu un sviluppatore è un amministratore ponu vene à pusà in a stessa stanza. È u sviluppatore pò dì: "Fighjate, quì sò i binari di a mo applicazione. Iddi travaglianu. L'applicazione hà bisognu di una basa di dati per travaglià. Quì accantu à i binari ci hè un schedariu. In questu schedariu, stu campu hè rispunsevule per u login, questu hè per a password, questu hè per l'IP. Impulsa in ogni locu ". È hè simplice è chjaru per l'amministratore. Puderà implementà veramente in ogni locu gestendu sta cunfigurazione.
È l'ultima pratica chì mi piacerebbe parlà hè una pratica chì hè assai, assai ligata à i nuvuli. È porta u massimu effettu si travaglia in u nuvulu. Questu hè a rimozione automatica di u vostru ambiente.
Sò chì ci sò parechje persone in questa cunferenza da e squadre cù quale travagliu. È cù tutte e squadre chì travaglianu, usemu sta pratica.
Perchè? Di sicuru, saria fantasticu se ogni sviluppatore avia una macchina virtuale chì travaglia 24/7. Ma forsi questu hè una nutizia per voi, forse ùn avete micca attentu, ma u sviluppatore stessu ùn travaglia micca 24/7. Un sviluppatore di solitu travaglia 8 ore à ghjornu. Ancu s'ellu vene à travaglià prima, hà un grande pranzu durante u quale si va à a palestra. Lasciate esse 12 ore à ghjornu quandu u sviluppatore usa veramente queste risorse. Sicondu a nostra legislazione, avemu 5 di 7 ghjorni in una settimana chì sò cunsiderati ghjorni di travagliu.
In cunsiquenza, in i ghjorni di settimana sta macchina ùn deve micca travaglià 24 ore, ma solu 12, è in u weekend sta macchina ùn deve micca travaglià in tuttu. Sembra chì tuttu hè assai simplice, ma chì hè impurtante di dì quì? Implementendu sta pratica simplice nantu à stu prugramma di basa, permette di riduce u costu di mantene questi ambienti da 70%, vale à dì chì avete pigliatu u prezzu di u vostru dev, QA, demo, ambiente è divisu per 3.
A quistione hè, chì fà cù u restu di i soldi? Per esempiu, i sviluppatori devenu cumprà ReSharper s'ellu ùn anu micca digià. O fate un cocktail party. Sè avete avutu prima un ambiente in quale sia dev sia QA pasturavanu, è questu hè, avà pudete fà 3 sfarenti chì seranu isolati, è a ghjente ùn interferiscenu micca l'una cù l'altru.
In quantu à a diapositiva cù a misurazione di u rendiment cuntinuu, cumu pudemu paragunà u rendiment si avemu avutu 1 records in a basa di dati in u prugettu, dui mesi dopu ci sò un milione? Cumu capisce perchè è quale hè u puntu di misurà u rendiment?
Questa hè una bona quistione, perchè duvete sempre misurà u rendiment nantu à e stesse risorse. Vale à dì, fate un novu codice, misurate u rendimentu nantu à u novu codice. Per esempiu, avete bisognu di pruvà diverse scenarii di rendiment, dicemu chì vulete pruvà cumu l'applicazione funziona nantu à una carica ligera, induve ci sò 1 000 utilizatori è a dimensione di a basa di dati hè 5 gigabyte. Avete misuratu è avete i numeri. Dopu piglià un altru scenariu. Per esempiu, 5 000 utilizatori, dimensione di basa di dati 1 terabyte. Avemu ricevutu i risultati è ricurdati di elli.
Cosa hè impurtante quì? L'impurtante quì hè chì sicondu u scenariu, u voluminu di dati, u numeru di utilizatori simultanei, etc., pudete curriri in certi limiti. Per esempiu, à u limitu di una carta di rete, o à u limitu di un discu duru, o à u limitu di capacità di processore. Questu hè ciò chì hè impurtante per voi per capiscenu. In diverse scenarii si scontra in certi limiti. È avete bisognu di capiscenu i numeri quandu li colpi.
Parlemu di a misurazione di u rendiment in un ambiente di prova speciale? Questu hè, questu ùn hè micca produzzione?
Iè, questu ùn hè micca produzzione, questu hè un ambiente di prova, chì hè sempre u listessu per pudè paragunà cù e misurazioni precedenti.
Capiscu grazie!
Se ùn ci sò micca dumande, pensu chì pudemu finisce. Grazie!
Source: www.habr.com