L'informe parlarà d'algunes pràctiques de DevOps, però des del punt de vista d'un desenvolupador. Normalment, tots els enginyers que s'uneixen a DevOps ja tenen diversos anys d'experiència administrativa al seu cinturó. Però això no vol dir que aquí no hi hagi lloc per al desenvolupador. Molt sovint, els desenvolupadors estan ocupats arreglant "el proper error crític urgent del dia" i no tenen temps ni tan sols per fer una ullada ràpida al camp DevOps. Segons l'autor, DevOps és, en primer lloc, sentit comú. En segon lloc, és una oportunitat per ser més efectius. Si ets desenvolupador, tens sentit comú i vols ser més eficaç com a jugador d'equip, aquest informe és per a tu.
Deixeu-me presentar-me, reconec plenament que hi ha gent a la sala que no em coneix. Em dic Anton Boyko, sóc MVP de Microsoft Azure. Què és MVP? Això és Model-View-Presenter. Model-View-Presenter sóc exactament jo.
A més, actualment ocupo el càrrec d'arquitecte de solucions a Ciklum. I fa poc que em vaig comprar un domini tan bonic i vaig actualitzar el meu correu electrònic, que normalment mostro a les presentacions. Podeu escriure'm a: me [dog] byokoant.pro. Podeu enviar-me un correu electrònic amb preguntes. Normalment els responc. L'única cosa és que no m'agradaria rebre per correu electrònic preguntes relacionades amb dos temes: política i religió. Podeu escriure'm sobre tota la resta per correu electrònic. Passarà un temps, et respondré.
Unes paraules sobre mi mateix:
- Fa 10 anys que estic en aquest camp.
- Vaig treballar a Microsoft.
- Sóc el pare fundador de la comunitat Azure d'Ucraïna, que vam fundar en algun lloc el 2014. I encara el tenim i l'estem desenvolupant.
- També sóc el pare del fundador de la conferència Azure, que organitzem a Ucraïna.
- També ajudo a organitzar el Global Azure Bootcamp a Kíev.
- Com he dit, sóc un MVP de Microsoft Azure.
- Parlo a conferències força sovint. M'agrada molt parlar a les conferències. Durant l'últim any vaig poder actuar unes 40 vegades. Si passes per Ucraïna, Bielorússia, Polònia, Bulgària, Suècia, Dinamarca, Països Baixos, Espanya o regales o prens un altre país d'Europa, aleshores és molt possible que quan vagis a una conferència que tingui el tema dels núvols al seu flux. , potser em veieu a la llista de ponents.
- També sóc fan de Star Trek.
Parlem una mica de l'Agenda. La nostra agenda és molt senzilla:
- Parlarem de què és DevOps. Parlem per què això és important. Anteriorment, DevOps era una paraula clau que vau escriure al vostre currículum i que vau rebre immediatament + 500 dòlars de sou. Ara heu d'escriure, per exemple, blockchain al vostre currículum per obtenir +500 dòlars al vostre sou.
- I després, quan entenguem una mica què és això, parlarem de quines són les pràctiques de DevOps. Però no tant en el context de DevOps en general, sinó sobre aquelles pràctiques de DevOps que poden ser d'interès per als desenvolupadors. Et diré per què et poden interessar. Us diré per què hauríeu de fer això i com us pot ajudar a experimentar menys dolor.
Una imatge tradicional que mostra molta gent. Això és el que passa en molts projectes. És quan tenim departaments de desenvolupament i operacions que donen suport al nostre programari. I aquests departaments no es comuniquen entre ells.
Potser, si no ho podríeu sentir tan clarament als departaments de DevOps i operacions, podeu fer una analogia amb els departaments de Dev i QA. Hi ha gent que desenvolupa programari i hi ha gent de control de qualitat que és dolenta des del punt de vista dels desenvolupadors. Per exemple, envio el meu meravellós codi al dipòsit, i hi ha un canalla assegut allà que em torna aquest codi i diu que el vostre codi és dolent.
Tot això passa perquè les persones no es comuniquen entre elles. I es llancen alguns paquets, alguna aplicació entre ells a través d'algun mur d'incomprensió i intenten fer alguna cosa amb ells.
És precisament aquest mur que la cultura DevOps està dissenyada per destruir, és a dir. obligar a les persones a comunicar-se entre elles i almenys entendre què fan les diferents persones del projecte i per què és important la seva feina.
I quan parlem de DevOps, algú et dirà que DevOps és quan el projecte té una integració contínua; algú dirà que DevOps és si el projecte implementa la pràctica "infraestructura com a codi"; algú dirà que el primer pas per a DevOps és la ramificació de funcions, les banderes de funcions.
Essencialment, tot això és cert a la seva manera. Però aquestes són només les pràctiques últimes que tenim. Abans de passar a aquestes pràctiques, suggereixo mirar aquesta diapositiva, que mostra les 3 etapes d'implementació de la metodologia Dev-Ops al vostre projecte, a la vostra empresa.
Aquesta diapositiva també té un segon nom no oficial. Podeu cercar en línia per esbrinar què són els 3 mosqueters de DevOps. És possible que trobeu aquest article. Per què 3 mosqueters? A sota diu: persones, processos i productes, és a dir. PPP – Porthos, Porthos i Porthos. Aquí teniu els 3 mosqueters de DevOps. Aquest article descriu amb més detall per què això és important i què implica.
Quan comenceu a implementar una cultura DevOps, és molt important que s'implementi en l'ordre següent.
Al principi cal parlar amb la gent. I cal explicar a la gent què és i com poden treure'n alguns beneficis.
La nostra conferència es diu DotNet Fest. I com em van dir els organitzadors, principalment vam convidar un públic de desenvolupadors aquí, així que espero que la majoria de la gent de la sala estigui involucrada en el desenvolupament.
Parlarem de la gent, parlarem del que volen fer els desenvolupadors cada dia. Què és el que més volen? Volen escriure un codi nou, utilitzar marcs nous, crear noves funcions. Què és el que menys volen els desenvolupadors? Arreglar errors antics. Espero que estigueu d'acord amb mi. Això és el que volen els desenvolupadors. Volen escriure noves característiques, no volen corregir errors.
El nombre d'errors que produeix un desenvolupador en particular depèn de com estiguin els braços rectes i de quant creixen de les seves espatlles, i no de les butxaques del cul. Però tanmateix, quan tenim un projecte gran, de vegades passa que és impossible fer un seguiment de tot, així que estaria bé que utilitzem alguns enfocaments que ens ajudin a escriure codi més estable i de més qualitat.
Què és el que més volen els QA? No sé si són al passadís. Em costa dir que vull un control de qualitat, perquè mai ho he estat. I sense ofendre els nois, es dirà que espero no ho faré mai. Però no perquè consideri la seva feina sense sentit i inútil, sinó perquè no em considero una persona que podria fer aquesta feina de manera eficient, així que ni tan sols intentaré fer-ho. Però pel que entenc, el que més no li agrada a QA és anar a treballar al matí, fent constantment algun tipus de proves de regressió, trepitjant els mateixos errors que van informar als desenvolupadors fa 3 sprints i dient: "Quan faràs? , Senyor D 'Artagnan, arregleu aquest error.' I el senyor d'Artagnan li respon: "Sí, sí, sí, ja ho he arreglat". I com passa que vaig solucionar un error i n'he fet 5 al llarg del camí.
Les persones que admeten aquesta solució en producció volen que aquesta solució funcioni sense errors, de manera que no hagin de reiniciar el servidor cada divendres, quan tota la gent normal va al bar. Els desenvolupadors desplegats divendres, els administradors s'asseuen fins dissabte, intentant que aquest desplegament estigui en marxa i arreglat.
I quan expliques a la gent que estan orientats a resoldre els mateixos problemes, pots passar a la formalització dels processos. És molt important. Per què? Perquè quan diem "formalització", és important que descriguis com es produeixen els teus processos almenys en algun lloc d'un tovalló. Heu d'entendre que si, per exemple, desplegueu a un entorn de control de qualitat o a un entorn de producció, sempre passa en aquest ordre; en aquestes etapes executem, per exemple, proves unitàries automàtiques i proves d'IU. Després del desplegament, comprovem si el desplegament ha anat bé o malament. Però ja teniu una llista clara d'accions que s'han de repetir una vegada i una altra quan desplegueu a producció.
I només quan els vostres processos estiguin formalitzats, comenceu a seleccionar productes que us ajudaran a automatitzar aquests processos.
Malauradament, sovint veig que això passa al revés. Tan bon punt algú escolta la paraula "DevOps", immediatament suggereix instal·lar Jenkins, perquè creu que tan bon punt instal·li Jenkins, tindrà DevOps. Van instal·lar Jenkins, van llegir els articles "Com fer-ho" al lloc web de Jenkins, van intentar introduir processos en aquests articles sobre Com fer-ho i després van arribar a la gent i es van inclinar, dient que el llibre diu que cal fer-ho d'aquesta manera. així que ho fem d'aquesta manera.
No és que Jenkins sigui una mala eina. No vull dir això de cap manera. Però aquest és només un dels productes. I quin producte utilitzeu hauria de ser la vostra última decisió, i de cap manera la primera. El vostre producte no ha de ser impulsat per la implementació de cultura i enfocaments. Això és molt important d'entendre, per això passo tant de temps en aquesta diapositiva i explico tot això durant tant de temps.
Parlem de les pràctiques de DevOps en general. Que són ells? Quina és la diferència? Com provar-los? Per què són importants?
La primera pràctica de la qual potser heu sentit parlar es diu Integració contínua. Potser algú del projecte té integració contínua (CI).
El problema més gran és que sovint quan pregunto a una persona: "Tens CI al projecte?" i em diu: "Sí", després quan li pregunto què fa, em descriu absolutament tot el procés d'automatització. Això no és del tot cert.
De fet, la pràctica de CI només té com a objectiu integrar el codi que diferents persones escriuen en algun tipus de base de codi únic. Això és tot.
Juntament amb CI, normalment hi ha altres pràctiques al llarg del camí, com ara el desplegament continu, la gestió de llançaments, però d'això en parlarem més endavant.
El mateix CI ens diu que diferents persones escriuen codi i aquest codi s'ha d'integrar contínuament en una única base de codi.
Què ens aporta això i per què és important? Si tenim DotNet, això està bé, és un llenguatge compilat, podem compilar la nostra aplicació. Si es compila, això ja és un bon senyal. Això encara no vol dir res, però és el primer bon senyal que almenys podem compilar.
A continuació, podem fer algunes proves, que també és una pràctica independent. Les proves són totes verdes: aquest és el segon bon senyal. Però de nou, això no vol dir res.
Però per què faries això? Totes les pràctiques de les quals parlaré avui tenen aproximadament el mateix valor, és a dir, aproximadament els mateixos beneficis i també es mesuren aproximadament de la mateixa manera.
En primer lloc, us permet accelerar el lliurament. Com això us permet accelerar el lliurament? Quan fem alguns canvis nous a la nostra base de codi, podem intentar immediatament fer alguna cosa amb aquest codi. No esperem fins que arribi el dijous perquè dijous el publiquem a QA Environment, ho fem aquí i aquí mateix.
Us explicaré una història trista de la meva vida. Va ser fa molt de temps, quan encara era jove i guapo. Ara ja sóc jove, bonica i intel·ligent, i modesta. Fa un temps vaig estar en un projecte. Teníem un gran equip d'uns 30 desenvolupadors. I vam tenir un gran i gran projecte d'Empresa que es va desenvolupar durant uns 10 anys. I teníem diferents branques. Al repositori teníem una branca on caminaven els desenvolupadors. I hi havia una branca que mostrava la versió del codi que està en producció.
La branca de producció va quedar 3 mesos per darrere de la branca que estava disponible per als desenvolupadors. Què vol dir això? Això vol dir que tan bon punt tinc un error en algun lloc que va a la producció per culpa dels desenvolupadors, perquè ho van permetre, i per culpa de QA, perquè ho van mirar, això vol dir que si rebo un tasca per a la correcció ràpida per a la producció, aleshores he de revertir els meus canvis de codi fa 3 mesos. He de recordar el que vaig tenir fa 3 mesos i intentar arreglar-ho allà.
Si encara no has tingut aquesta experiència, pots provar-la al teu projecte de casa. El més important és que no ho proveu en comercial. Escriviu un parell de línies de codi, oblideu-les durant sis mesos i, a continuació, torneu i intenteu explicar ràpidament de què es tracten aquestes línies de codi i com podeu solucionar-les o optimitzar-les. És una experiència molt, molt emocionant.
Si tenim una pràctica d'integració contínua, això ens permet comprovar-ho amb diverses eines automatitzades aquí i ara mateix, tan bon punt hagi escrit el meu codi. Això pot no donar-me la imatge completa, però, tanmateix, eliminarà almenys alguns dels riscos. I si hi ha algun error potencial, ho sabré ara mateix, és a dir, literalment en un parell de minuts. No hauré de retrocedir 3 mesos. Només necessitaré retrocedir 2 minuts. Una bona màquina de cafè ni tan sols tindrà temps de fer cafè en 2 minuts, així que és genial.
Això té el valor que es pot repetir una vegada a una altra en cada projecte, és a dir. no només el que l'has configurat. Podeu repetir tant la pràctica en si mateix com el CI mateix es repetirà per a cada nou canvi que feu al projecte. Això us permet optimitzar els recursos perquè el vostre equip treballa de manera més eficient. Ja no tindreu una situació en què us vingui un error del codi amb què vau treballar fa 3 mesos. Ja no tindreu canvi de context quan us assegueu i passeu les dues primeres hores intentant entendre què va passar llavors i entrar en l'essència del context abans de començar a corregir alguna cosa.
Com podem mesurar l'èxit o el fracàs d'aquesta pràctica? Si informeu al gran cap del que hem implementat al projecte CI, escolta bla bla bla. L'hem implementat, d'acord, però per què, què ens ha aportat, com ho mesurem, com ho estem implementant correctament o incorrectament?
La primera és que, gràcies a CI, podem desplegar-nos cada cop més sovint, i més sovint precisament perquè el nostre codi és potencialment més estable. De la mateixa manera, el nostre temps per trobar un error es redueix i el temps per corregir aquest error es redueix precisament perquè rebem una resposta del sistema aquí mateix i ara mateix, què passa amb el nostre codi.
Una altra pràctica que tenim és la pràctica de proves d'automatització, que sovint ve amb la pràctica CI. Van de la mà.
Què és important entendre aquí? És important entendre que les nostres proves són diferents. I cada prova automatitzada està dirigida a resoldre els seus propis problemes. Tenim, per exemple, proves unitàries que ens permeten provar un mòdul per separat, és a dir. Com funciona al buit? Això és bo.
També disposem de proves d'integració que ens permeten entendre com s'integren els diferents mòduls entre si. També és bo.
És possible que tinguem proves d'automatització de la IU que ens permetin comprovar si el treball amb la IU compleix determinats requisits establerts pel client, etc.
Les proves específiques que feu poden afectar la freqüència amb què les executeu. Les proves unitats solen ser escrites breus i petites. I es poden llançar regularment.
Si estem parlant de proves d'automatització de la interfície d'usuari, és bo si el vostre projecte és petit. Les proves d'automatització de la interfície d'usuari poden trigar el temps adequat. Però normalment una prova d'automatització de la interfície d'usuari és una cosa que triga diverses hores en un projecte gran. I és bo si són poques hores. L'única cosa és que no té sentit executar-los per a cada construcció. Té sentit executar-los a la nit. I quan tothom va venir a treballar al matí: tant provadors com desenvolupadors, van rebre una mena d'informe que vam fer la prova automàtica de la interfície d'usuari a la nit i vam obtenir aquests resultats. I aquí, una hora de treball d'un servidor que comprovarà que el teu producte compleix uns requisits serà molt més econòmica que una hora de treball del mateix enginyer de QA, encara que sigui un enginyer Júnior de QA que treballa per menjar i gràcies. Tot i així, una hora de funcionament de la màquina serà més barata. Per això té sentit invertir-hi.
Tinc un altre projecte en el qual he estat treballant. Vam fer sprints de dues setmanes en aquest projecte. El projecte era gran, important per al sector financer, i no es va poder cometre un error. I després d'un sprint de dues setmanes, el cicle de desenvolupament va ser seguit per un procés de prova, que va durar 4 setmanes més. Intenta imaginar l'envergadura de la tragèdia. Escrivim codi durant dues setmanes, després ho fem ala CodeFreeze, l'empaquetem en una nova versió de l'aplicació i el distribuïm als provadors. Els provadors el posen a prova durant 4 setmanes més, és a dir. Mentre ho estan provant, tenim temps de preparar-los dues versions més. Aquest és un cas realment trist.
I els vam dir que si voleu ser més productius, té sentit que implementeu pràctiques de proves automatitzades, perquè això és el que us fa mal aquí mateix, ara mateix.
Practicar el desplegament continu. Genial, has acabat de construir. Això ja és bo. El teu codi s'ha compilat. Ara estaria bé desplegar aquesta compilació en algun entorn. Diguem en un entorn per a desenvolupadors.
Per què és important? En primer lloc, podeu veure l'èxit que teniu amb el propi procés de desplegament. He conegut projectes com aquest, quan pregunto: “Com es desplega una nova versió de l'aplicació?”, els nois em diuen: “La muntem i l'empaquetem en un arxiu zip. L'enviem a l'administrador per correu. L'administrador baixa i amplia aquest arxiu. I tota l'oficina comença a pregar perquè el servidor reculli la nova versió".
Comencem amb una cosa senzilla. Per exemple, es van oblidar de posar CSS a l'arxiu o es van oblidar de canviar l'etiqueta al nom del fitxer java-script. I quan fem una sol·licitud al servidor, el navegador pensa que ja té aquest fitxer java-script i decideix no descarregar-lo. I hi havia una versió antiga, faltava alguna cosa. En general, hi pot haver molts problemes. Per tant, la pràctica del desplegament continu us permet com a mínim provar què passaria si agafeu una imatge de referència neta i la pengeu a un entorn completament net. Podeu veure on porta això.
A més, quan integreu el codi entre ells, és a dir. entre l'ordre, això us permet veure també com es veu a la interfície d'usuari.
Un dels problemes que es produeixen quan s'utilitza molt java-script de vainilla és que dos desenvolupadors van declarar precipitadament una variable amb el mateix nom a l'objecte finestra. I després, depenent de la teva sort. El fitxer java-script del qual s'extreu en segon lloc sobreescriurà els canvis de l'altre. També és molt emocionant. Entres: una cosa funciona per a una persona, una altra no funciona per a una altra. I és "meravellós" quan tot surt en producció.
La següent pràctica que tenim és la pràctica de la restauració automàtica, és a dir, tornar a la versió anterior de l'aplicació.
Per què és important per als desenvolupadors? Encara hi ha qui recorda els llunyans i llunyans anys 90, quan els ordinadors eren grans i els programes petits. I l'única manera de desenvolupar web era a través de PHP. No és que PHP sigui un llenguatge dolent, encara que sí.
Però el problema era diferent. Quan vam desplegar una nova versió del nostre lloc php, com la vam implementar? Molt sovint obrim Far Manager o una altra cosa. I he penjat aquests fitxers a FTP. I de sobte ens vam adonar que teníem un petit error, per exemple, ens vam oblidar de posar un punt i coma o vam oblidar de canviar la contrasenya de la base de dades, i hi ha una contrasenya per a la base de dades, que es troba a l'amfitrió local. I decidim connectar-nos ràpidament a FTP i editar els fitxers allà mateix. Això només és foc! Això és el que va ser popular als anys 90.
Però, si no us heu mirat el calendari, els anys 90 van ser fa gairebé 30 anys. Ara tot està passant una mica diferent. I mira d'imaginar l'envergadura de la tragèdia quan et diuen: “Ens vam desplegar a la producció, però alguna cosa va fallar allà. Aquí teniu el vostre inici de sessió i la vostra contrasenya FTP, connecteu-vos a la producció i arregleu-ho ràpidament. Si ets Chuck Norris, això funcionarà. Si no, corres el risc que si correges un error, en faràs 10. Precisament per això aquesta pràctica de tornar a la versió anterior et permet aconseguir molt.
Fins i tot si alguna cosa dolenta d'alguna manera va entrar a la producció en algun lloc, llavors és dolent, però no fatal. Podeu tornar a la versió anterior que teniu. Digueu-ne una còpia de seguretat, si és més fàcil percebre-ho en aquesta terminologia. Podeu tornar a aquesta versió anterior i els usuaris encara podran treballar amb el vostre producte i tindreu un temps de memòria intermèdia adequat. Pots tranquil·lament, sense presses, agafar tot això i provar-ho localment, arreglar-ho i, després, pujar una nova versió. Realment té sentit fer això.
Ara intentem combinar d'alguna manera les dues pràctiques anteriors juntes. En tindrem un tercer anomenat Release Management.
Quan parlem del desplegament continu en la seva forma clàssica, diem que hem d'extraure codi d'alguna branca del repositori, compilar-lo i desplegar-lo. És bo si tenim el mateix entorn. Si tenim diversos entorns, això vol dir que hem de treure el codi cada vegada, fins i tot des de la mateixa confirmació. El traurem cada cop, el construirem cada cop i el desplegarem en un nou entorn. En primer lloc, aquest és el moment, perquè per construir un projecte, si en teniu un de gran i veniu dels anys 90, pot trigar diverses hores.
A més, hi ha una altra tristesa. Quan creeu, fins i tot a la mateixa màquina, construireu les mateixes fonts, encara no teniu cap garantia que aquesta màquina estigui en el mateix estat que durant l'última construcció.
Suposem que algú va entrar i va actualitzar DotNet per a tu o, al contrari, algú va decidir suprimir alguna cosa. I després teniu una dissonància cognitiva que a partir d'aquest commit fa dues setmanes estàvem construint una compilació i tot anava bé, però ara sembla la mateixa màquina, la mateixa commit, el mateix codi que estem intentant construir, però no funciona. . T'enfrontaràs a això durant molt de temps i no és un fet que ho aconseguiu. Com a mínim, et espatllaràs molt els nervis.
Per tant, la pràctica de Release Management suggereix introduir una abstracció addicional anomenada dipòsit d'artefactes o galeria o biblioteca. Pots anomenar-lo com vulguis.
La idea principal és que tan bon punt tinguem algun tipus de commit allà, per exemple, en una branca que estem preparats per desplegar als nostres diferents entorns, recollim aplicacions d'aquest commit i tot el que necessitem per a aquesta aplicació, l'empaquetem. en un arxiu zip i deseu-lo en un emmagatzematge fiable. I des d'aquest emmagatzematge podem obtenir aquest arxiu zip en qualsevol moment.
A continuació, l'agafem i el despleguem automàticament a l'entorn de desenvolupament. Correm allà, i si tot va bé, ens despleguem a l'escenari. Si tot va bé, despleguem el mateix arxiu a producció, els mateixos binaris, compilats exactament una vegada.
A més, quan tenim una galeria com aquesta, també ens ajuda a abordar els riscos que vam abordar a l'última diapositiva quan vam parlar de retrocés a la versió anterior. Si accidentalment heu desplegat alguna cosa malament, sempre podeu agafar qualsevol altra versió anterior d'aquesta galeria i desplegar-la a aquests entorns de la mateixa manera. Això us permet tornar fàcilment a la versió anterior si alguna cosa va malament.
Hi ha una altra gran pràctica. Tots entenem que quan tornem a les nostres aplicacions a una versió anterior, això pot significar que també necessitem la infraestructura de la versió anterior.
Quan parlem d'infraestructura virtual, molta gent pensa que això és una cosa que configuren els administradors. I si necessiteu, per exemple, obtenir un nou servidor en el qual voleu provar una nova versió de la vostra aplicació, heu d'escriure un bitllet als administradors o devops. Devops trigarà 3 setmanes per a això. I al cap de 3 setmanes us diran que us hem instal·lat una màquina virtual, amb un nucli, dos gigabytes de RAM i un servidor Windows sense DotNet. Vostè diu: "Però jo volia DotNet". Ells: "D'acord, torna d'aquí a 3 setmanes".
La idea és que utilitzant Infraestructura com a pràctiques de codi, podeu tractar la vostra infraestructura virtual com un recurs més.
Potser, si algú de vosaltres està desenvolupant aplicacions a DotNet, potser haureu sentit a parlar d'una biblioteca anomenada Entity Framework. I potser fins i tot heu sentit que Entity Framework és un dels enfocaments que Microsoft està impulsant activament. Per treballar amb una base de dades, aquest és un enfocament anomenat Code First. Això és quan descriu en codi com voleu que es vegi la vostra base de dades. I després desplegueu l'aplicació. Es connecta a la base de dades, ell mateix determina quines taules hi ha i quines no, i crea tot el que necessites.
Podeu fer el mateix amb la vostra infraestructura. No hi ha cap diferència entre si necessiteu una base de dades per a un projecte o si necessiteu un servidor Windows per a un projecte. És només un recurs. I podeu automatitzar la creació d'aquest recurs, podeu automatitzar la configuració d'aquest recurs. En conseqüència, cada vegada que vulgueu provar algun concepte nou, algun enfocament nou, no haureu d'escriure un bitllet per a devops, simplement podeu implementar una infraestructura aïllada per a vosaltres mateixos a partir de plantilles ja fetes, de scripts ja fets i implementar-lo. allà tots els teus experiments. Podeu suprimir-ho, obtenir alguns resultats i informar-ne més.
La següent pràctica, que també existeix i també és important, però que poca gent utilitza, és el seguiment del rendiment de les aplicacions.
Només volia dir una cosa sobre el seguiment del rendiment de les aplicacions. Què és el més important d'aquesta pràctica? Això és el que és més o menys el mateix que reparar un apartament. Aquest no és un estat final, és un procés. Cal fer-ho regularment.
En bona manera, seria bo dur a terme un seguiment del rendiment de l'aplicació en gairebé totes les compilacions, encara que, com enteneu, això no sempre és possible. Però, com a mínim, s'ha de dur a terme per a cada llançament.
Per què és important? Perquè si de sobte experimenteu una caiguda del rendiment, heu d'entendre clarament per què. Si el vostre equip té, per exemple, sprints de dues setmanes, almenys una vegada cada dues setmanes hauríeu de desplegar la vostra aplicació en un servidor independent, on tingueu un processador, memòria RAM, discs clarament fixats, etc. I feu-los amb les mateixes proves de rendiment. . Obteniu el resultat. Mireu com ha canviat respecte a l'sprint anterior.
I si descobreixes que la baixada ha baixat bruscament en algun lloc, voldrà dir que va ser només pels canvis que s'han produït durant les últimes dues setmanes. Això us permetrà identificar i solucionar el problema molt més ràpidament. I de nou, aquestes són aproximadament les mateixes mètriques amb les quals podeu mesurar l'èxit que ho heu fet.
La següent pràctica que tenim és la pràctica de Gestió de la configuració. Són molt pocs els que s'ho prenen seriosament. Però creieu-me, això és realment una cosa molt seriosa.
Recentment hi va haver una història divertida. Els nois van venir a mi i em van dir: "Ajuda'ns a realitzar una auditoria de seguretat de la nostra aplicació". Vam mirar el codi junts durant molt de temps, em van parlar de l'aplicació, van dibuixar diagrames. I més o menys tot era lògic, entenedor, segur, però n'hi havia un PERÒ! Tenien fitxers de configuració al seu control de fonts, inclosos els de producció amb la base de dades IP, amb inicis de sessió i contrasenyes per connectar-se a aquestes bases de dades, etc.
I dic: "Nois, d'acord, heu tancat el vostre entorn de producció amb un tallafoc, però el fet que tingueu l'inici de sessió i la contrasenya de la base de dades de producció directament al control de fonts i qualsevol desenvolupador el pugui llegir ja és un gran risc de seguretat. . I per molt segura que sigui la vostra aplicació des del punt de vista del codi, si la deixeu al control del codi font, mai passareu cap auditoria enlloc". D'això estic parlant.
Gestió de la configuració. Podem tenir diferents configuracions en diferents entorns. Per exemple, podem tenir diferents inicis de sessió i contrasenyes per a bases de dades per a control de qualitat, demostració, entorn de producció, etc.
Aquesta configuració també es pot automatitzar. Sempre ha d'estar independent de l'aplicació en si. Per què? Com que heu creat l'aplicació una vegada, i després a l'aplicació no li importa si us connecteu al servidor SQL mitjançant tal i tal IP o tal i tal IP, hauria de funcionar igual. Per tant, si de sobte un de vosaltres encara està codificant la cadena de connexió al codi, recordeu que us trobaré i us castigaré si us trobeu al mateix projecte amb mi. Això sempre es col·loca en una configuració independent, per exemple, a web.config.
I aquesta configuració ja es gestiona per separat, és a dir, aquest és exactament el moment en què un desenvolupador i un administrador poden venir a seure a la mateixa habitació. I el desenvolupador pot dir: “Mira, aquí teniu els binaris de la meva aplicació. Ells treballen. L'aplicació necessita una base de dades per funcionar. Aquí al costat dels binaris hi ha un fitxer. En aquest fitxer, aquest camp és responsable de l'inici de sessió, això és per a la contrasenya, això és per a la IP. Desplegueu-lo a qualsevol lloc". I és senzill i clar per a l'administrador. Pot implementar-lo realment a qualsevol lloc gestionant aquesta configuració.
I l'última pràctica de la qual m'agradaria parlar és una pràctica molt i molt relacionada amb els núvols. I aporta el màxim efecte si treballes al núvol. Això és l'eliminació automàtica del vostre entorn.
Sé que hi ha diverses persones en aquesta conferència dels equips amb els quals treballo. I amb tots els equips amb els quals treballo, fem servir aquesta pràctica.
Per què? Per descomptat, seria fantàstic que cada desenvolupador tingués una màquina virtual que funcionés les 24 hores del dia. Però potser això és una notícia per a vosaltres, potser no us heu fet cas, però el propi desenvolupador no treballa les 7 hores del dia. Normalment, un desenvolupador treballa 24 hores al dia. Encara que ve d'hora a la feina, fa un gran dinar durant el qual va al gimnàs. Deixeu que siguin 7 hores al dia quan el desenvolupador utilitzi realment aquests recursos. Segons la nostra legislació, tenim 8 de cada 12 dies a la setmana que es consideren dies laborables.
En conseqüència, els dies laborables aquesta màquina no hauria de funcionar 24 hores, sinó només 12, i els caps de setmana aquesta màquina no hauria de funcionar en absolut. Sembla que tot és molt senzill, però què és important dir aquí? En implementar aquesta pràctica senzilla en aquesta programació bàsica, us permet reduir el cost del manteniment d'aquests entorns en un 70%, és a dir, heu pres el preu del vostre desenvolupament, control de qualitat, demostració, entorn i el vau dividir per 3.
La pregunta és, què fer amb la resta de diners? Per exemple, els desenvolupadors haurien de comprar ReSharper si encara no ho han fet. O fer un còctel. Si abans teníeu un entorn en el qual els desenvolupadors i el control de qualitat van pastar, i ja està, ara podeu fer-ne 3 de diferents que quedaran aïllats i la gent no interferirà entre elles.
Pel que fa a la diapositiva amb mesura de rendiment contínua, com podem comparar el rendiment si tinguéssim 1 registres a la base de dades del projecte, dos mesos després n'hi ha un milió? Com entendre per què i quin sentit té mesurar el rendiment?
Aquesta és una bona pregunta, perquè sempre hauríeu de mesurar el rendiment amb els mateixos recursos. És a dir, desplegueu el codi nou, mesureu el rendiment del codi nou. Per exemple, cal provar diferents escenaris de rendiment, suposem que voleu provar com funciona l'aplicació amb una càrrega lleugera, on hi ha 1 usuaris i la mida de la base de dades és de 000 gigabytes. Ho has mesurat i has aconseguit els números. A continuació, prenem un altre escenari. Per exemple, 5 usuaris, mida de la base de dades 5 terabyte. Vam rebre els resultats i els vam recordar.
Què és important aquí? L'important aquí és que, segons l'escenari, el volum de dades, el nombre d'usuaris simultanis, etc., podeu trobar-vos amb certs límits. Per exemple, al límit d'una targeta de xarxa, o al límit d'un disc dur, o al límit de les capacitats del processador. Això és el que és important perquè entenguis. En diferents escenaris et trobes amb certs límits. I cal entendre els números quan els toqueu.
Estem parlant de mesurar el rendiment en un entorn de prova especial? És a dir, això no és producció?
Sí, això no és producció, això és un entorn de prova, que sempre és el mateix perquè pugueu comparar-lo amb mesures anteriors.
Entés gràcies!
Si no hi ha preguntes, crec que podem acabar. Gràcies!
Font: www.habr.com