La raporto parolos pri iuj DevOps-praktikoj, sed el la vidpunkto de programisto. Kutime, ĉiuj inĝenieroj kiuj aliĝas al DevOps jam havas plurajn jarojn da administra sperto sub sia zono. Sed ĉi tio ne signifas, ke ĉi tie ne estas loko por la programisto. Pli ofte ol ne, programistoj estas okupataj ripari "la sekvan urĝe kritikan cimon de la tago", kaj ili ne havas tempon eĉ rapide rigardi la kampon DevOps. Laŭ la kompreno de la aŭtoro, DevOps estas, unue, komuna racio. Due, ĝi estas ŝanco esti pli efika. Se vi estas programisto, havas prudenton kaj volas esti pli efika kiel teamludanto, ĉi tiu raporto estas por vi.
Mi prezentu min, mi plene konfesas, ke estas homoj en la ĉambro, kiuj ne konas min. Mi nomiĝas Anton Boyko, mi estas Microsoft Azure MVP. Kio estas MVP? Ĉi tio estas Model-View-Presenter. Model-View-Presenter estas ĝuste mi.
Krome, mi nuntempe okupas la postenon de solvo-arkitekto ĉe Ciklum. Kaj ĵus mi aĉetis al mi tiel belan domajnon, kaj mi ĝisdatigis mian retpoŝton, kiun mi kutime montras ĉe prezentoj. Vi povas skribi al mi ĉe: mi [hundo] byokoant.pro. Vi povas retpoŝti min kun demandoj. Mi kutime respondas al ili. La sola afero estas, ke mi ne ŝatus ricevi retpoŝte demandojn, kiuj rilatas al du temoj: politiko kaj religio. Vi povas skribi al mi pri ĉio alia retpoŝte. Iom da tempo pasos, mi respondos.
Kelkaj vortoj pri mi mem:
- Mi estas en ĉi tiu kampo jam de 10 jaroj.
- Mi laboris ĉe Microsoft.
- Mi estas la fondinto de la ukraina Azure-komunumo, kiun ni fondis ie en 2014. Kaj ni ankoraŭ havas ĝin kaj disvolvas ĝin.
- Mi ankaŭ estas la patro de la fondinto de la Azure-konferenco, kiun ni gastigas en Ukrainio.
- Mi ankaŭ helpas organizi la Tutmondan Azure Bootcamp en Kyiv.
- Kiel mi diris, mi estas Microsoft Azure MVP.
- Mi parolas en konferencoj sufiĉe ofte. Mi tre amas paroli ĉe konferencoj. Dum la pasinta jaro mi povis rezulti ĉirkaŭ 40 fojojn. Se vi pasas preter Ukrainio, Belorusio, Pollando, Bulgario, Svedio, Danio, Nederlando, Hispanio aŭ donas aŭ prenas alian landon en Eŭropo, tiam estas tute eble, ke kiam vi iras al konferenco kiu havas nuban temon en sia fluo, vi eble vidos, ke mi estas en la listo de parolantoj.
- Mi ankaŭ estas ŝatanto de Star Trek.
Ni parolu iomete pri Tagordo. Nia Tagordo estas tre simpla:
- Ni parolos pri kio estas DevOps. Ni parolu kial ĉi tio estas grava. Antaŭe, DevOps estis ŝlosilvorto, kiun vi skribis en via vivresumo kaj tuj ricevis + $ 500 en salajro. Nun vi devas skribi, ekzemple, blokĉenon en via vivresumo por akiri +500 dolarojn al via salajro.
- Kaj tiam, kiam ni komprenos iomete pri kio ĉi tio estas, ni parolos pri kio estas DevOps-praktikoj. Sed ne tiom en la kunteksto de DevOps ĝenerale, sed pri tiuj DevOps-praktikoj, kiuj povus interesi programistojn. Mi diros al vi kial ili povus interesi vin. Mi diros al vi kial vi devus fari ĉi tion entute kaj kiel ĝi povas helpi vin sperti malpli da doloro.
Tradicia bildo, kiun multaj homoj montras. Ĉi tio okazas en multaj projektoj. Jen kiam ni havas evoluajn kaj operaciajn fakojn, kiuj subtenas nian programaron. Kaj ĉi tiuj fakoj ne komunikas inter si.
Eble, se vi ne povis senti ĝin tiel klare en la DevOps kaj operaciaj fakoj, vi povas desegni analogion kun la Dev kaj QA-fakoj. Estas homoj kiuj disvolvas programaron kaj estas homoj de QA kiuj estas malbonaj el la vidpunkto de la programistoj. Ekzemple, mi transdonas mian mirindan kodon al la deponejo, kaj tie sidas iu kanajlo, kiu resendas ĉi tiun kodon al mi kaj diras, ke via kodo estas malbona.
Ĉio ĉi okazas ĉar homoj ne komunikas inter si. Kaj ili ĵetas kelkajn pakaĵojn, iun aplikon al unu la alian tra iu muro de miskompreno kaj provas fari ion kun ili.
Ĝuste ĉi tiun muron DevOps-kulturo estas dizajnita por detrui, t.e. devigi homojn komuniki inter si kaj almenaŭ kompreni kion faras malsamaj homoj en la projekto kaj kial ilia laboro estas grava.
Kaj kiam ni parolas pri DevOps, iu diros al vi, ke DevOps estas kiam la projekto havas kontinuan integriĝon; iu diros, ke DevOps estas se la projekto efektivigas la praktikon "infrastrukturo kiel kodo"; iu diros, ke la unua paŝo al DevOps estas trajtobranĉigo, trajto flagoj.
Esence, ĉi tio estas vera laŭ sia propra maniero. Sed ĉi tiuj estas nur la finfinaj praktikoj, kiujn ni havas. Antaŭ ol pluiri al ĉi tiuj praktikoj, mi sugestas rigardi ĉi tiun lumbildon, kiu montras la 3-ŝtupojn de efektivigado de Dev-Ops-metodaro en via projekto, en via kompanio.
Ĉi tiu glito ankaŭ havas duan neoficialan nomon. Vi povas serĉi interrete por ekscii, kio estas la 3 Musketistoj de DevOps. Eblas, ke vi trovos ĉi tiun artikolon. Kial 3 Musketistoj? Sube ĝi diras: homoj, procezoj kaj produktoj, t.e. PPP - Porthos, Porthos kaj Porthos. Jen la 3 muskedistoj de DevOps. Ĉi tiu artikolo priskribas pli detale kial ĉi tio estas grava kaj kion ĝi implicas.
Kiam vi komencas efektivigi DevOps-kulturon, estas tre grave ke ĝi estas efektivigita en la sekva ordo.
Komence vi devas paroli kun homoj. Kaj vi devas klarigi al homoj kio ĝi estas kaj kiel ili povas akiri iujn avantaĝojn de ĝi.
Nia konferenco nomiĝas DotNet Fest. Kaj kiel la organizantoj diris al mi, ni ĉefe invitis publikon de programistoj ĉi tie, do mi esperas, ke la plej multaj el la homoj en la salono okupiĝas pri evoluo.
Ni parolos pri homoj, ni parolos pri tio, kion programistoj volas fari ĉiutage. Kion ili plej volas? Ili volas skribi novan kodon, uzi novajn kadrojn, krei novajn funkciojn. Kion malplej volas programistoj? Ripari malnovajn erarojn. Mi esperas, ke vi konsentas kun mi. Jen kion volas la programistoj. Ili volas skribi novajn funkciojn, ili ne volas ripari erarojn.
La nombro da cimoj, kiujn certa programisto produktas, dependas de kiom rektaj estas liaj brakoj kaj kiom ili kreskas de liaj ŝultroj, kaj ne de liaj pugopoŝoj. Sed tamen, kiam ni havas grandan projekton, foje okazas, ke estas neeble konservi trakon de ĉio, do estus bone por ni uzi iujn alirojn, kiuj helpos nin skribi pli stabilan kaj pli altkvalitan kodon.
Kion QA plej volas? Mi ne scias ĉu ili estas en la halo. Estas malfacile por mi diri, ke mi volas QA, ĉar mi neniam estis tia. Kaj neniu ofendo al la infanoj, oni diros, ke mi esperas, ke mi neniam faros. Sed ne pro tio, ke mi konsideras ilian laboron sensenca kaj senutila, sed ĉar mi ne konsideras min homo, kiu povus efike fari ĉi tiun laboron, do mi eĉ ne provos fari ĝin. Sed laŭ tio, kion mi komprenas, tio, kion QA plej ne ŝatas, funkcias matene, konstante farante ian regresajn provojn, tretante la samajn erarojn, kiujn ili raportis al la programistoj antaŭ 3 sprintoj, kaj dirante: “Kiam vi volas. , Sinjoro D 'Artagnan, riparu ĉi tiun cimon.' Kaj sinjoro D'Artagnan respondas al li: "Jes, jes, jes, mi jam riparis ĝin." Kaj kiel okazas, ke mi riparis unu cimon kaj faris 5 survoje.
La homoj, kiuj subtenas ĉi tiun solvon en produktado, volas, ke ĉi tiu solvo funkciu sen cimoj, por ke ili ne devas rekomenci la servilon ĉiun vendredon, kiam ĉiuj normalaj homoj iras al la trinkejo. La programistoj deplojitaj vendrede, la administrantoj sidas ĝis sabato, provante akiri ĉi tiun disfaldiĝon kaj ripari.
Kaj kiam vi klarigas al homoj, ke ili celas solvi la samajn problemojn, vi povas daŭrigi formaligi la procezojn. Ĝi estas tre grava. Kial? Ĉar kiam ni diras "formaligo", estas grave por vi priskribi kiel viaj procezoj okazas almenaŭ ie sur buŝtuko. Vi devas kompreni, ke se vi, ekzemple, disvastiĝas al QA-medio aŭ produktadmedio, tiam ĝi ĉiam okazas en ĉi tiu ordo; en ĉi tiuj stadioj ni faras, ekzemple, aŭtomatajn unutestojn kaj UI-testojn. Post deplojo, ni kontrolas ĉu la deplojo iris bone aŭ malbone. Sed vi jam havas klaran liston de agoj, kiuj devas esti ripetitaj denove kaj denove kiam vi deplojas al produktado.
Kaj nur kiam viaj procezoj estas formaligitaj, vi komencas elekti produktojn, kiuj helpos vin aŭtomatigi ĉi tiujn procezojn.
Bedaŭrinde, mi tre ofte vidas tion okazi inverse. Tuj kiam iu aŭdas la vorton "DevOps", ili tuj sugestas instali Jenkins, ĉar ili kredas, ke tuj kiam ili instalos Jenkins, ili havos DevOps. Ili instalis Jenkins, legis la artikolojn "Kiel al" en la retejo de Jenkins, provis enŝtopi procezojn en ĉi tiujn artikolojn Kiel fari, kaj poste venis al homoj kaj klinis homojn, dirante, ke la libro diras, ke vi devas fari ĝin tiel, do ni faru ĝin tiel.
Ne estas ke Jenkins estas malbona ilo. Mi neniel intencas diri tion. Sed ĉi tio estas nur unu el la produktoj. Kaj kiu produkto vi uzas devus esti via lasta decido, kaj neniel via unua. Via produkto ne devus esti pelita de la efektivigo de kulturo kaj aliroj. Ĉi tio estas tre grave kompreni, tial mi pasigas tiom da tempo sur ĉi tiu glito kaj klarigas ĉion ĉi tiom longe.
Ni parolu pri DevOps-praktikoj ĝenerale. Kio ili estas? Kio estas la diferenco? Kiel provi ilin? Kial ili estas gravaj?
La unua praktiko, pri kiu vi eble aŭdis, nomiĝas Kontinua Integriĝo. Eble iu en la projekto havas Daŭran Integriĝon (CI).
La plej granda problemo estas, ke plej ofte kiam mi demandas homon: "Ĉu vi havas CI en la projekto?" kaj li diras: "Jes", tiam kiam mi demandas, kion li faras, li priskribas al mi absolute la tutan aŭtomatigan procezon. Ĉi tio ne estas tute vera.
Fakte, la praktiko de CI nur celas integri la kodon, kiun malsamaj homoj skribas en ia ununura koda bazo. Tio estas ĉio.
Kune kun CI, estas kutime aliaj praktikoj survoje - kiel Daŭra Deplojo, Liberiga Administrado, sed pri tio ni parolos poste.
CI mem diras al ni, ke malsamaj homoj skribas kodon kaj ĉi tiu kodo devas esti senĉese integrita en ununuran kodon.
Kion ĉi tio donas al ni kaj kial ĝi estas grava? Se ni havas DotNet, tiam tio estas bona, ĝi estas kompilita lingvo, ni povas kompili nian aplikaĵon. Se ĝi kompilas, tiam ĉi tio jam estas bona signo. Ĉi tio ankoraŭ nenion signifas, sed ĝi estas la unua bona signo, ke ni povas almenaŭ kompili.
Tiam ni povas fari kelkajn provojn, kio ankaŭ estas aparta praktiko. La testoj estas ĉiuj verdaj - ĉi tiu estas la dua bona signo. Sed denove, ĉi tio signifas nenion.
Sed kial vi farus ĉi tion? Ĉiuj praktikoj, pri kiuj mi parolos hodiaŭ, portas proksimume la saman valoron, t.e. proksimume la samajn avantaĝojn kaj ankaŭ estas mezuritaj proksimume same.
Unue, ĝi permesas vin akceli liveron. Kiel ĉi tio permesas vin akceli liveron? Kiam ni faras iujn novajn ŝanĝojn al nia koda bazo, ni povas tuj provi fari ion kun ĉi tiu kodo. Ni ne atendas ĝis venos ĵaŭdo ĉar ĵaŭde ni liberigas ĝin al QA Environment, ni faras ĝin ĝuste ĉi tie kaj ĝuste ĉi tie.
Mi rakontos al vi unu malĝojan historion el mia vivo. Estis antaŭ longe, kiam mi estis ankoraŭ juna kaj bela. Nun mi jam estas juna, bela kaj saĝa, kaj modesta. Antaŭ iom da tempo mi estis en projekto. Ni havis grandan teamon de ĉirkaŭ 30 programistoj. Kaj ni havis grandan, grandan Enterprise-projekton, kiu disvolviĝis dum ĉirkaŭ 10 jaroj. Kaj ni havis malsamajn branĉojn. En la deponejo ni havis branĉon en kiu promenis programistoj. Kaj estis branĉo, kiu montris la version de la kodo, kiu estas en produktado.
La produktadbranĉo estis 3 monatoj malantaŭ la branĉo kiu estis havebla al programistoj. Kion ĉi tio signifas? Ĉi tio signifas, ke tuj kiam mi havas cimon ie, kiu iras al produktado pro la kulpo de la programistoj, ĉar ili permesis ĝin, kaj pro la kulpo de QA, ĉar ili rigardis ĝin, tiam tio signifas, ke se mi ricevas tasko por varmigo por produktado, tiam mi devas refari miajn kodŝanĝojn antaŭ 3 monatoj. Mi devas memori kion mi havis antaŭ 3 monatoj kaj provi ripari ĝin tie.
Se vi ankoraŭ ne havis ĉi tiun sperton, vi povas provi ĝin en via hejma projekto. La ĉefa afero estas, ne provu ĝin sur komerca. Skribu kelkajn liniojn de kodo, forgesu pri ili dum ses monatoj, kaj poste revenu kaj provu rapide klarigi pri kio temas tiuj kodlinioj kaj kiel vi povas ripari aŭ optimumigi ilin. Ĝi estas tre, tre ekscita sperto.
Se ni havas Daŭran Integrigan praktikon, tiam ĉi tio permesas al ni kontroli ĝin per kelkaj aŭtomatigitaj iloj ĝuste ĉi tie kaj nun, tuj kiam mi skribis mian kodon. Ĉi tio eble ne donas al mi la plenan bildon, sed tamen ĝi forigos almenaŭ kelkajn el la riskoj. Kaj se estas ia ebla cimo, mi scios pri ĝi nun, tio estas, laŭvorte post kelkaj minutoj. Mi ne bezonos retroiri 3 monatojn. Mi nur bezonos retroiri 2 minutojn. Bona kafmaŝino eĉ ne havos tempon por fari kafon en 2 minutoj, do tio estas sufiĉe mojosa.
Ĉi tio havas la valoron, ke ĝi povas esti ripetita fojon post fojo en ĉiu projekto, t.e. ne nur tiu, sur kiu vi starigis ĝin. Vi povas ripeti kaj la praktikon mem kaj CI mem estos ripetita por ĉiu nova ŝanĝo, kiun vi faras al la projekto. Ĉi tio permesas al vi optimumigi rimedojn ĉar via teamo funkcias pli efike. Vi ne plu havos situacion kie cimo venas al vi de la kodo kun kiu vi laboris antaŭ 3 monatoj. Vi ne plu havos kuntekstŝanĝon kiam vi sidas kaj pasigas la unuajn du horojn provante kompreni kio okazis tiam kaj eniri la esencon de la kunteksto antaŭ ol vi komencas korekti ion.
Kiel ni povas mezuri la sukceson aŭ malsukceson de ĉi tiu praktiko? Se vi raportas al la granda estro tion, kion ni efektivigis en la CI-projekto, li aŭdas bla bla bla. Ni efektivigis ĝin, bone, sed kial, kion ĝi alportis al ni, kiel ni mezuras ĝin, kiom ĝuste aŭ malĝuste ni efektivigas ĝin?
La unua estas ke, danke al CI, ni povas deploji pli kaj pli ofte, kaj pli ofte ĝuste ĉar nia kodo estas eble pli stabila. De la sama maniero, nia tempo por trovi eraron estas reduktita kaj la tempo por korekti ĉi tiun eraron estas reduktita ĝuste pro tio, ke ni ricevas respondon de la sistemo ĝuste ĉi tie kaj nun, kio estas malbona kun nia kodo.
Alia praktiko, kiun ni havas, estas la praktiko pri Aŭtomatiga Testado, kiu plej ofte venas kun la praktiko CI. Ili iras man en mano.
Kion gravas kompreni ĉi tie? Gravas kompreni, ke niaj testoj estas malsamaj. Kaj ĉiu aŭtomatigita testo celas solvi siajn proprajn problemojn. Ni havas ekzemple unutestojn, kiuj ebligas al ni testi modulon aparte, t.e. Kiel ĝi funkcias en vakuo? Ĉi tio estas bona.
Ni ankaŭ havas integrigajn testojn, kiuj ebligas al ni kompreni kiel malsamaj moduloj integriĝas inter si. Ĝi ankaŭ estas bona.
Ni povas havi UI-aŭtomatigajn testojn, kiuj ebligas al ni kontroli kiom bone la laboro kun la UI plenumas iujn postulojn fiksitajn de la kliento, ktp.
La specifaj testoj, kiujn vi faras, povas influi kiom ofte vi rulas ilin. Unuaj testoj estas kutime skribitaj mallongaj kaj malgrandaj. Kaj ili povas esti lanĉitaj regule.
Se ni parolas pri UI-aŭtomatigaj testoj, tiam estas bone se via projekto estas malgranda. Viaj provoj pri aŭtomatigo de UI povas preni sufiĉan tempon. Sed kutime UI-aŭtomatiga provo estas io, kio daŭras plurajn horojn en granda projekto. Kaj estas bone, se estas kelkaj horoj. La nura afero estas, ke ne utilas ruli ilin por ĉiu konstruo. Estas senco kuri ilin nokte. Kaj kiam ĉiuj venis al laboro matene: kaj testistoj kaj programistoj, ili ricevis ian raporton, ke ni kuris la aŭtoteston de UI nokte kaj ricevis ĉi tiujn rezultojn. Kaj ĉi tie, horo da laboro de servilo, kiu kontrolos, ke via produkto plenumas iujn postulojn, estos multe pli malmultekosta ol horo da laboro de la sama QA-inĝeniero, eĉ se li estas Junior QA-inĝeniero, kiu laboras por manĝaĵo kaj dankon. Tamen, horo da maŝina funkciado estos pli malmultekosta. Tial estas senco investi en ĝi.
Mi havas alian projekton pri kiu mi laboris. Ni havis du-semajnajn spurtojn pri ĉi tiu projekto. La projekto estis granda, grava por la financa sektoro, kaj eraro ne povis esti farita. Kaj post du-semajna sprinto, la disvolva ciklo estis sekvita de testa procezo, kiu daŭris aliajn 4 semajnojn. Provu imagi la amplekson de la tragedio. Ni skribas kodon dum du semajnoj, poste ni faras ĝin al CodeFreeze, enpakas ĝin en novan version de la aplikaĵo kaj eldonas ĝin al testistoj. Testistoj provas ĝin dum pliaj 4 semajnoj, t.e. Dum ili provas ĝin, ni havas tempon por prepari du pliajn versiojn por ili. Ĉi tio estas vere malĝoja kazo.
Kaj ni diris al ili, ke se vi volas esti pli produktiva, estas senco por vi efektivigi Aŭtomatigitajn Testadajn praktikojn, ĉar ĉi tio estas kio doloras vin ĝuste ĉi tie, nun.
Praktiku Daŭran Deplojon. Bonege, vi jam konstruis. Ĉi tio jam estas bona. Via kodo kompilis. Nun estus bone deploji ĉi tiun konstruon sur iu medio. Ni diru en medio por programistoj.
Kial ĝi estas grava? Unue, vi povas rigardi kiom sukcesa vi estas kun la deploja procezo mem. Mi renkontis projektojn kiel ĉi, kiam mi demandas: "Kiel vi disvastigas novan version de la aplikaĵo?", la infanoj diras al mi: "Ni kunmetas ĝin kaj pakas ĝin en zip-arkivon. Ni sendas ĝin al la administranto per poŝto. La administranto elŝutas kaj vastigas ĉi tiun arkivon. Kaj la tuta oficejo komencas preĝi, ke la servilo prenu la novan version."
Ni komencu per io simpla. Ekzemple, ili forgesis meti CSS en la arkivon aŭ forgesis ŝanĝi la hashtag en la java-script dosiernomo. Kaj kiam ni faras peton al la servilo, la retumilo opinias, ke ĝi jam havas ĉi tiun java-script-dosieron kaj decidas ne elŝuti ĝin. Kaj estis malnova versio, io mankis. Ĝenerale, povas esti multaj problemoj. Tial, la praktiko de Daŭra Deplojo permesas vin almenaŭ testi kio okazus se vi prenus puran referencan bildon kaj alŝutus ĝin al tute pura nova medio. Vi povas vidi kien ĉi tio kondukas.
Ankaŭ, kiam vi integras kodon inter si, t.e. inter la komando, ĉi tio ebligas al vi ankaŭ vidi kiel ĝi aspektas en la UI.
Unu el la problemoj, kiuj okazas kie multe da vanila java-skripto estas uzata, estas, ke du programistoj senpripense deklaris variablon kun la sama nomo en la fenestra objekto. Kaj tiam, depende de via sorto. Kies java-script-dosiero estas eltirita sekundon, anstataŭigos la ŝanĝojn de la alia. Ĝi ankaŭ estas tre ekscita. Vi eniras: unu afero funkcias por unu persono, alia ne funkcias por alia. Kaj ĝi estas "mirinda" kiam ĉio aperas en produktado.
La sekva praktiko, kiun ni havas, estas la praktiko de Aŭtomata Restarigo, nome reveni al la antaŭa versio de la aplikaĵo.
Kial ĉi tio estas grava por programistoj? Ankoraŭ ekzistas tiuj, kiuj memoras la malproksimajn, malproksimajn 90-ajn, kiam komputiloj estis grandaj kaj programoj estis malgrandaj. Kaj la sola vojo al TTT-evoluo estis per PHP. Ne estas ke PHP estas malbona lingvo, kvankam ĝi estas.
Sed la problemo estis alia. Kiam ni deplojis novan version de nia php-ejo, kiel ni deplojis ĝin? Plej ofte ni malfermis Far Manager aŭ ion alian. Kaj alŝutis ĉi tiujn dosierojn al FTP. Kaj ni subite rimarkis, ke ni havis ian malgrandan, malgrandan cimon, ekzemple, ni forgesis meti punktokomon aŭ forgesis ŝanĝi la pasvorton por la datumbazo, kaj estas pasvorto por la datumbazo, kiu estas sur la loka gastiganto. Kaj ni decidas rapide konekti al FTP kaj redakti la dosierojn ĝuste tie. Ĉi tio estas nur fajro! Ĉi tio estis populara en la 90-aj jaroj.
Sed, se vi ne rigardis la kalendaron, la 90-aj jaroj estis antaŭ preskaŭ 30 jaroj. Nun ĉio okazas iom alie. Kaj provu imagi la amplekson de la tragedio kiam ili diras al vi: "Ni deplojiĝis al produktado, sed io misfunkciis tie. Jen via FTP-ensaluto kaj pasvorto, konektu al produktado kaj rapide riparu ĝin tie." Se vi estas Chuck Norris, tio funkcios. Se ne, tiam vi riskas, ke se vi riparas unu cimon, vi faros pliajn 10. Ĝuste tial ĉi tiu praktiko reveni al la antaŭa versio permesas vin atingi multon.
Eĉ se io malbona iel eniris prodon ie, tiam ĝi estas malbona, sed ne fatala. Vi povas reveni al la antaŭa versio, kiun vi havas. Nomu ĝin rezerva, se estas pli facile percepti ĝin en tiu terminologio. Vi povas reveni al ĉi tiu antaŭa versio, kaj uzantoj ankoraŭ povos labori kun via produkto, kaj vi havos taŭgan bufran tempon. Vi povas trankvile, sen hasto, preni ĉion ĉi kaj testi ĝin loke, ripari ĝin, kaj poste alŝuti novan version. Ĝi vere havas sencon fari ĉi tion.
Nun ni provu kombini iel la du antaŭajn praktikojn kune. Ni ricevos trian nomitan Release Management.
Kiam ni parolas pri Kontinua Deplojo en ĝia klasika formo, ni diras, ke ni devas tiri kodon de iu branĉo el la deponejo, kompili ĝin kaj disfaldi ĝin. Estas bone, se ni havas la saman medion. Se ni havas plurajn mediojn, tio signifas, ke ni devas tiri la kodon ĉiufoje, eĉ de la sama komit. Ni eltiros ĝin ĉiufoje, ni konstruos ĝin ĉiufoje kaj ni deplojos ĝin al nova medio. Unue, ĉi tio estas tempo, ĉar por konstrui projekton, se vi havas grandan kaj venis de la 90-aj jaroj, tiam ĝi povas daŭri plurajn horojn.
Krome, estas alia malĝojo. Kiam vi konstruas, eĉ sur la sama maŝino, vi konstruos la samajn fontojn, vi ankoraŭ ne havas garantion, ke ĉi tiu maŝino estas en la sama stato kiel ĝi estis dum la lasta konstruo.
Ni diru, ke iu eniris kaj ĝisdatigis DotNet por vi aŭ, male, iu decidis forigi ion. Kaj tiam vi havas kognan disonancon, ke de ĉi tiu komito antaŭ du semajnoj ni konstruis konstruon kaj ĉio estis bona, sed nun ŝajnas la sama maŝino, la sama komit, la sama kodo, kiun ni provas konstrui, sed ĝi ne funkcias. . Vi traktos ĉi tion dum longa tempo kaj ne estas fakto, ke vi eltrovos ĝin. Almenaŭ, vi multe difektos viajn nervojn.
Tial, Release Management-praktiko sugestas enkonduki plian abstraktadon nomitan artefakto-deponejo aŭ galerio aŭ biblioteko. Vi povas nomi ĝin kiel ajn vi volas.
La ĉefa ideo estas, ke tuj kiam ni havas iun specon de kommit tie, ekzemple, en branĉo, kiun ni pretas disfaldi al niaj malsamaj medioj, ni kolektas aplikojn de ĉi tiu kommit kaj ĉion, kion ni bezonas por ĉi tiu aplikaĵo, ni pakas ĝin. en zip-arkivon kaj konservu ĝin en iu fidinda stokado. Kaj de ĉi tiu stokado ni povas ricevi ĉi tiun zip-arkivon iam ajn.
Tiam ni prenas ĝin kaj aŭtomate deplojas ĝin al la dev-medio. Ni vetkuras tie, kaj se ĉio estas bona, tiam ni deplojiĝas al la scenejo. Se ĉio estas bona, tiam ni deplojas la saman arkivon al produktado, la samajn binarojn, kompilitaj ĝuste unufoje.
Krome, kiam ni havas galerion kiel ĉi tio, ĝi ankaŭ helpas nin trakti la riskojn, kiujn ni traktis sur la lasta diapozitivo kiam ni parolis pri retroiro al la antaŭa versio. Se vi hazarde deplojis ion malĝustan, vi ĉiam povas preni ajnan alian antaŭan version de ĉi tiu galerio kaj maldeploji ĝin al ĉi tiuj medioj en la sama maniero. Ĉi tio ebligas al vi facile reveni al la antaŭa versio se io misfunkcias.
Estas alia bonega praktiko. Vi kaj mi ĉiuj komprenas, ke kiam ni retroiras niajn aplikojn al antaŭa versio, tio povas signifi, ke ni ankaŭ bezonas la infrastrukturon de la antaŭa versio.
Kiam ni parolas pri virtuala infrastrukturo, multaj homoj pensas, ke ĉi tio estas io, kiun administrantoj starigas. Kaj se vi bezonas, ekzemple, akiri novan servilon sur kiu vi volas testi novan version de via aplikaĵo, tiam vi devas skribi bileton al la administrantoj aŭ devopoj. Devops daŭros 3 semajnojn por ĉi tio. Kaj post 3 semajnoj ili diros al vi, ke ni instalis virtualan maŝinon por vi, kun unu kerno, du gigabajtoj da RAM kaj Vindoza servilo sen DotNet. Vi diras: "Sed mi volis DotNet." Ili: "Bone, revenu post 3 semajnoj."
La ideo estas, ke uzante Infrastrukturon kiel Kodajn praktikojn, vi povas trakti vian virtualan infrastrukturon kiel nur alian rimedon.
Eble, se iu el vi disvolvas aplikojn en DotNet, vi eble aŭdis pri biblioteko nomata Entity Framework. Kaj vi eble eĉ aŭdis, ke Entity Framework estas unu el la aliroj, kiujn Microsoft aktive puŝas. Por labori kun datumbazo, ĉi tio estas aliro nomita Code First. Jen kiam vi priskribas en kodo kiel vi volas ke via datumbazo aspektu. Kaj tiam vi deplojas la aplikaĵon. Ĝi konektas al la datumbazo, ĝi mem determinas kiuj tabeloj estas tie kaj kiuj tabeloj ne estas, kaj kreas ĉion, kion vi bezonas.
Vi povas fari la samon kun via infrastrukturo. Ne estas diferenco inter ĉu vi bezonas datumbazon por projekto aŭ ĉu vi bezonas Vindozan servilon por projekto. Ĝi estas nur rimedo. Kaj vi povas aŭtomatigi la kreadon de ĉi tiu rimedo, vi povas aŭtomatigi la agordon de ĉi tiu rimedo. Sekve, ĉiufoje kiam vi volas testi iun novan koncepton, iun novan aliron, vi ne bezonos skribi bileton al devopoj, vi povas simple disfaldi por vi izolan infrastrukturon el pretaj ŝablonoj, el pretaj skriptoj kaj efektivigi ĝin. tie ĉiuj viaj eksperimentoj. Vi povas forigi ĉi tion, akiri kelkajn rezultojn kaj raporti plu pri ĝi.
La sekva praktiko, kiu ankaŭ ekzistas kaj ankaŭ gravas, sed kiun malmultaj homoj uzas, estas Aplika Performance Monitoring.
Mi volis diri nur unu aferon pri Aplika Efikeco-Monitorado. Kio estas plej grava pri ĉi tiu praktiko? Jen kio Aplika Efikeco Monitorado estas proksimume la sama kiel ripari apartamenton. Ĉi tio ne estas fina stato, ĝi estas procezo. Vi devas fari ĝin regule.
En bona maniero, estus bone efektivigi Aplikan Efikecon Monitoradon sur preskaŭ ĉiu konstruo, kvankam, kiel vi komprenas, ĉi tio ne ĉiam eblas. Sed, minimume, ĝi devas esti efektivigita por ĉiu eldono.
Kial ĝi estas grava? Ĉar se vi subite spertas malpliiĝon de rendimento, tiam vi devas klare kompreni kial. Se via teamo havas, ekzemple, du-semajnajn spurtojn, tiam almenaŭ unufoje ĉiun duan semajnon vi devus deploji vian aplikaĵon al iu aparta servilo, kie vi havas klare fiksitan procesoron, RAM, diskojn, ktp. Kaj rulu tiujn la samajn agadotestojn. . Vi ricevas la rezulton. Vidu kiel ĝi ŝanĝiĝis de la antaŭa spurto.
Kaj se vi ekscios, ke la malaltiĝo akre malsupreniris ien, tio signifos, ke ĝi estis nur pro la ŝanĝoj, kiuj okazis dum la lastaj du semajnoj. Ĉi tio permesos vin identigi kaj solvi la problemon multe pli rapide. Kaj denove, ĉi tiuj estas proksimume la samaj metrikoj per kiuj vi povas mezuri kiom sukcese vi faris ĝin.
La sekva praktiko, kiun ni havas, estas la praktiko pri Agordo-Administrado. Estas tre malmultaj kiuj prenas ĉi tion serioze. Sed kredu min, ĉi tio fakte estas tre serioza afero.
Estis amuza rakonto lastatempe. La uloj venis al mi kaj diris: "Helpu nin fari sekurecan revizion de nia aplikaĵo." Ni longe rigardis la kodon kune, ili rakontis al mi pri la aplikaĵo, desegnis diagramojn. Kaj pli aŭ minus ĉio estis logika, komprenebla, sekura, sed estis unu SED! Ili havis agordajn dosierojn en sia fontkontrolo, inkluzive de tiuj de produktado kun la IP-datumbazo, kun ensalutoj kaj pasvortoj por konekti al ĉi tiuj datumbazoj, ktp.
Kaj mi diras: "Kaj, bone, vi fermis vian produktadmedion per fajroŝirmilo, sed la fakto, ke vi havas la ensaluton kaj pasvorton por la produktada datumbazo ĝuste en la fontkontrolo kaj ĉiu programisto povas legi ĝin, jam estas grandega sekureca risko. . Kaj kiom ajn supersekura estas via aplikaĵo el koda vidpunkto, se vi lasas ĝin en fontkontrolo, tiam vi neniam preterpasos ajnan revizion ie ajn." Pri tio mi parolas.
Administrado de agordo. Ni povas havi malsamajn agordojn en malsamaj medioj. Ekzemple, ni povas havi malsamajn ensalutojn kaj pasvortojn por datumbazoj por QA, demo, produktadmedio, ktp.
Ĉi tiu agordo ankaŭ povas esti aŭtomatigita. Ĝi ĉiam devas esti aparta de la aplikaĵo mem. Kial? Ĉar vi konstruis la aplikaĵon unufoje, kaj tiam la aplikaĵo ne zorgas ĉu vi konektas al la SQL-servilo per tia kaj tia IP aŭ tia kaj tia IP, ĝi devus funkcii same. Sekve, se subite iu el vi ankoraŭ malmola kodas la konektan ĉenon en la kodo, tiam memoru, ke mi trovos vin kaj punos vin se vi trovos vin en la sama projekto kun mi. Ĉi tio ĉiam estas metita en apartan agordon, ekzemple en web.config.
Kaj ĉi tiu agordo jam estas administrita aparte, tio estas ĝuste la momento, kiam programisto kaj administranto povas veni kaj sidi en la sama ĉambro. Kaj la programisto povas diri: "Vidu, jen la binaroj de mia aplikaĵo. Ili laboras. La aplikaĵo bezonas datumbazon por funkcii. Ĉi tie apud la binaroj estas dosiero. En ĉi tiu dosiero, ĉi tiu kampo respondecas pri la ensaluto, ĉi tio estas por la pasvorto, ĉi tio estas por la IP. Deploji ĝin ie ajn." Kaj ĝi estas simpla kaj klara al la administranto. Li povas deploji ĝin vere ie ajn per administrado de ĉi tiu agordo.
Kaj la lasta praktiko, pri kiu mi ŝatus paroli, estas praktiko tre, tre rilata al nuboj. Kaj ĝi alportas maksimuman efikon se vi laboras en la nubo. Ĉi tio estas Aŭtomata forigo de via medio.
Mi scias, ke estas pluraj homoj ĉe ĉi tiu konferenco el la teamoj kun kiuj mi laboras. Kaj kun ĉiuj teamoj kun kiuj mi laboras, ni uzas ĉi tiun praktikon.
Kial? Kompreneble, estus bonege, se ĉiu programisto havus virtualan maŝinon, kiu funkcius 24/7. Sed eble ĉi tio estas novaĵo por vi, eble vi ne atentis, sed la programisto mem ne funkcias 24/7. Programisto kutime laboras 8 horojn tage. Eĉ se li venas al laboro frue, li havas grandan tagmanĝon dum kiu li iras al la gimnazio. Estu 12 horoj tage kiam la programisto efektive uzas ĉi tiujn rimedojn. Laŭ nia leĝaro, ni havas 5 el 7 tagoj en semajno kiuj estas konsiderataj labortagoj.
Sekve, dum labortagoj ĉi tiu maŝino ne devus funkcii 24 horojn, sed nur 12, kaj semajnfine ĉi tiu maŝino tute ne devus funkcii. Ŝajnus, ke ĉio estas tre simpla, sed kion gravas diri ĉi tie? Realigante ĉi tiun simplan praktikon en ĉi tiu baza horaro, ĝi permesas vin redukti la koston de konservado de ĉi tiuj medioj je 70%, t.e. vi prenis la prezon de via dev, QA, demo, medio kaj dividis ĝin per 3.
La demando estas, kion fari kun la resto de la mono? Ekzemple, la programistoj devus aĉeti ReSharper se ili ne jam faris. Aŭ havu koktelon. Se vi antaŭe havis unu medion en kiu kaj dev kaj QA paŝtis, kaj jen ĝi, nun vi povas fari 3 malsamajn, kiuj estos izolitaj, kaj homoj ne malhelpos unu la alian.
Koncerne la diapozitivon kun kontinua agado-mezurado, kiel ni povas kompari rendimenton se ni havis 1 rekordojn en la datumbazo en la projekto, du monatojn poste estas miliono? Kiel kompreni kial kaj kio estas la signifo de mezuri rendimenton?
Ĉi tio estas bona demando, ĉar vi ĉiam devus mezuri rendimenton per la samaj rimedoj. Tio estas, vi eligas novan kodon, vi mezuras rendimenton sur la nova kodo. Ekzemple, vi devas testi malsamajn agadoscenarojn, ni diru, ke vi volas testi kiel la aplikaĵo funkcias sur malpeza ŝarĝo, kie estas 1 uzantoj kaj la datumbazo grandeco estas 000 gigabajtoj. Vi mezuris ĝin kaj ricevis la nombrojn. Poste ni prenas alian scenaron. Ekzemple, 5 uzantoj, datumbazo grandeco 5 terabajto. Ni ricevis la rezultojn kaj memoris ilin.
Kio gravas ĉi tie? La grava afero ĉi tie estas, ke depende de la scenaro, la volumo de datumoj, la nombro da samtempaj uzantoj, ktp., vi povas renkonti certajn limojn. Ekzemple, ĝis la limo de retkarto, aŭ ĝis la limo de malmola disko, aŭ ĝis la limo de procesoraj kapabloj. Jen kio gravas por vi kompreni. En malsamaj scenaroj vi renkontas certajn limojn. Kaj vi devas kompreni la nombrojn kiam vi trafas ilin.
Ĉu ni parolas pri mezurado de rendimento en speciala testa medio? Tio estas, ĉi tio ne estas produktado?
Jes, ĉi tio ne estas produktado, ĉi tio estas testa medio, kiu ĉiam estas la sama, por ke vi povu kompari ĝin kun antaŭaj mezuradoj.
Komprenita dankon!
Se ne estas demandoj, mi pensas, ke ni povas fini. Dankon!
fonto: www.habr.com