In het rapport wordt gesproken over enkele DevOps-praktijken, maar dan vanuit het perspectief van een ontwikkelaar. Normaal gesproken hebben alle engineers die zich bij DevOps aansluiten al meerdere jaren administratieve ervaring achter de rug. Maar dit betekent niet dat hier geen plaats is voor de ontwikkelaar. Vaker wel dan niet zijn ontwikkelaars druk bezig met het oplossen van ‘de volgende dringend kritieke bug van de dag’, en hebben ze geen tijd om zelfs maar even naar het DevOps-veld te kijken. Volgens de auteur is DevOps in de eerste plaats gezond verstand. Ten tweede is het een kans om effectiever te zijn. Als u een ontwikkelaar bent, gezond verstand heeft en effectiever wilt zijn als teamspeler, dan is dit rapport iets voor u.
Laat ik mij even voorstellen, ik geef volledig toe dat er mensen in de zaal zijn die mij niet kennen. Mijn naam is Anton Boyko, ik ben een Microsoft Azure MVP. Wat is MVP? Dit is Model-View-Presentator. Model-View-Presenter ben precies mij.
Daarnaast bekleed ik momenteel de functie van Solution Architect bij Ciklum. En onlangs kocht ik zo'n mooi domein voor mezelf, en ik heb mijn e-mail bijgewerkt, die ik meestal laat zien bij presentaties. U kunt mij schrijven op: me [dog] byokoant.pro. Bij vragen kunt u mij mailen. Meestal beantwoord ik ze. Het enige is dat ik geen vragen per e-mail wil ontvangen die betrekking hebben op twee onderwerpen: politiek en religie. Over al het andere kunt u mij per e-mail schrijven. Er zal enige tijd verstrijken, ik zal antwoorden.
Een paar woorden over mezelf:
- Ik zit nu al 10 jaar in dit vakgebied.
- Ik heb bij Microsoft gewerkt.
- Ik ben de grondlegger van de Oekraïense Azure-gemeenschap, die we ergens in 2014 hebben opgericht. En we hebben het nog steeds en zijn het aan het ontwikkelen.
- Ik ben ook de vader van de oprichter van de Azure-conferentie, die we in Oekraïne organiseren.
- Ook help ik bij het organiseren van de Global Azure Bootcamp in Kiev.
- Zoals ik al zei, ik ben een Microsoft Azure MVP.
- Ik spreek heel vaak op conferenties. Ik vind het heel leuk om op conferenties te spreken. Het afgelopen jaar heb ik ongeveer 40 keer mogen optreden. Als je Oekraïne, Wit-Rusland, Polen, Bulgarije, Zweden, Denemarken, Nederland, Spanje of een ander land in Europa passeert, dan is het heel goed mogelijk dat wanneer je naar een conferentie gaat die een cloudthema in de stroom heeft, Misschien zie je mij op de lijst met sprekers.
- Ik ben ook een Star Trek-fan.
Laten we het even hebben over Agenda. Onze agenda is heel eenvoudig:
- We zullen het hebben over wat DevOps is. Laten we praten waarom dit belangrijk is. Voorheen was DevOps een trefwoord dat u op uw cv schreef en onmiddellijk +€500 aan salaris ontving. Nu moet je bijvoorbeeld blockchain in je cv schrijven om +500 dollar aan je salaris te krijgen.
- En als we dan een beetje begrijpen wat dit is, zullen we praten over wat DevOps-praktijken zijn. Maar niet zozeer in de context van DevOps in het algemeen, maar over die DevOps-praktijken die interessant kunnen zijn voor ontwikkelaars. Ik zal je vertellen waarom ze voor jou interessant kunnen zijn. Ik vertel je waarom je dit überhaupt moet doen en hoe je hierdoor minder pijn kunt ervaren.
Een traditioneel beeld dat veel mensen laten zien. Dit is wat in veel projecten gebeurt. Dit is wanneer we ontwikkelings- en operationele afdelingen hebben die onze software ondersteunen. En deze afdelingen communiceren niet met elkaar.
Als je het niet zo duidelijk kon voelen op de afdelingen DevOps en Operations, kun je misschien een analogie trekken met de afdelingen Dev en QA. Er zijn mensen die software ontwikkelen en er zijn QA-mensen die slecht zijn vanuit het oogpunt van de ontwikkelaars. Ik commit bijvoorbeeld mijn prachtige code in de repository, en daar zit een schurk die deze code aan mij terugstuurt en zegt dat jouw code slecht is.
Dit gebeurt allemaal omdat mensen niet met elkaar communiceren. En ze gooien wat pakketjes, een of andere toepassing op elkaar, door een muur van misverstanden heen en proberen er iets mee te doen.
Het is precies deze muur die de DevOps-cultuur wil vernietigen. dwing mensen om met elkaar te communiceren en op zijn minst te begrijpen wat verschillende mensen in het project doen en waarom hun werk belangrijk is.
En als we het over DevOps hebben, zal iemand je vertellen dat het project bij DevOps een continue integratie kent; iemand zal zeggen dat DevOps is als het project de ‘infrastructuur als code’-praktijk implementeert; iemand zal zeggen dat de eerste stap naar DevOps feature branching is, feature flags.
In wezen is dit allemaal op zijn eigen manier waar. Maar dit zijn slechts de ultieme praktijken die we hebben. Voordat ik verder ga met deze praktijken, stel ik voor om naar deze dia te kijken, die de drie fasen toont van het implementeren van Dev-Ops-methodologie in uw project, in uw bedrijf.
Deze dia heeft ook een tweede onofficiële naam. Je kunt online zoeken om erachter te komen wat de 3 Musketiers van DevOps zijn. Het is mogelijk dat u dit artikel tegenkomt. Waarom 3 Musketiers? Daaronder staat: mensen, processen en producten, d.w.z. PPP – Porthos, Porthos en Porthos. Hier zijn de 3 Musketiers van DevOps. In dit artikel wordt nader beschreven waarom dit belangrijk is en wat het inhoudt.
Wanneer je begint met het implementeren van een DevOps-cultuur, is het van groot belang dat deze in de onderstaande volgorde wordt geïmplementeerd.
In eerste instantie moet je met mensen praten. En je moet mensen uitleggen wat het is en hoe ze er voordelen uit kunnen halen.
Onze conferentie heet DotNet Fest. En zoals de organisatoren me vertelden, hebben we hier vooral een publiek van ontwikkelaars uitgenodigd, dus ik hoop dat de meeste mensen in de zaal betrokken zijn bij de ontwikkeling.
We zullen het over mensen hebben, we zullen het hebben over wat ontwikkelaars elke dag willen doen. Wat willen ze het liefst? Ze willen nieuwe code schrijven, nieuwerwetse raamwerken gebruiken, nieuwe functies creëren. Wat willen ontwikkelaars het minst? Repareer oude bugs. Ik hoop dat je het met mij eens bent. Dit is wat de ontwikkelaars willen. Ze willen nieuwe functies schrijven, ze willen geen bugs oplossen.
Het aantal bugs dat een bepaalde ontwikkelaar produceert, hangt af van hoe recht zijn armen zijn en hoeveel ze vanaf zijn schouders groeien, en niet vanuit zijn achterzakken. Maar toch, als we een groot project hebben, komt het soms voor dat het onmogelijk is om alles bij te houden, dus het zou leuk zijn als we een aantal benaderingen zouden gebruiken die ons zullen helpen stabielere code van hogere kwaliteit te schrijven.
Wat willen QA’s het liefst? Ik weet niet of ze in de hal zijn. Het is moeilijk voor mij om te zeggen dat ik een QA wil, omdat ik er nog nooit een ben geweest. En ik wil de jongens niet beledigen: er zal worden gezegd dat ik hoop dat dit nooit zal gebeuren. Maar niet om de reden dat ik hun werk zinloos en nutteloos beschouw, maar omdat ik mezelf niet beschouw als een persoon die dit werk efficiënt zou kunnen doen, dus ik zal niet eens proberen het te doen. Maar voor zover ik het begrijp, is wat QA het minst leuk vindt 's ochtends werken, voortdurend een soort regressietests uitvoeren, op dezelfde bugs trappen die ze drie sprints geleden aan de ontwikkelaars hebben gerapporteerd en zeggen: "Wanneer ga je , Monsieur D 'Artagnan, repareer deze bug.' En meneer D'Artagnan antwoordt hem: "Ja, ja, ja, ik heb het al opgelost." En hoe het gebeurt dat ik één bug heb opgelost en er gaandeweg vijf heb gemaakt.
De mensen die deze oplossing in productie ondersteunen, willen dat deze oplossing zonder bugs werkt, zodat ze de server niet elke vrijdag opnieuw hoeven op te starten, als alle normale mensen naar de bar gaan. De ontwikkelaars zijn vrijdag ingezet, de beheerders zijn tot zaterdag bezig geweest om deze implementatie op orde te krijgen.
En als je mensen uitlegt dat ze gericht zijn op het oplossen van dezelfde problemen, kun je overgaan tot het formaliseren van de processen. Het is erg belangrijk. Waarom? Want als we het over ‘formalisering’ hebben, is het belangrijk dat u op zijn minst ergens op een servet beschrijft hoe uw processen plaatsvinden. U moet begrijpen dat als u bijvoorbeeld implementeert in een QA-omgeving of een productieomgeving, dit altijd in deze volgorde gebeurt; in deze fasen voeren we bijvoorbeeld automatische unit-tests en UI-tests uit. Na de inzet controleren wij of de inzet goed of slecht is verlopen. Maar u beschikt al over een duidelijke lijst met acties die steeds opnieuw moeten worden herhaald wanneer u in productie gaat.
En pas wanneer uw processen zijn geformaliseerd, begint u producten te selecteren die u zullen helpen deze processen te automatiseren.
Helaas zie ik dit vaak omgekeerd gebeuren. Zodra iemand het woord ‘DevOps’ hoort, stellen ze onmiddellijk voor om Jenkins te installeren, omdat ze denken dat ze, zodra ze Jenkins installeren, over DevOps zullen beschikken. Ze installeerden Jenkins, lazen de 'How to'-artikelen op de Jenkins-website, probeerden processen in deze How to-artikelen te proppen, en kwamen toen naar mensen toe en bogen mensen voorover, zeggend dat het boek zegt dat je het op deze manier moet doen, dus doen wij het op deze manier.
Het is niet zo dat Jenkins een slecht hulpmiddel is. Dat wil ik op geen enkele manier zeggen. Maar dit is slechts één van de producten. En welk product u gebruikt, moet uw laatste beslissing zijn, en zeker niet uw eerste. Uw product mag niet worden gedreven door de implementatie van cultuur en benaderingen. Dit is heel belangrijk om te begrijpen, en daarom besteed ik zoveel tijd aan deze dia en leg ik dit allemaal zo lang uit.
Laten we het hebben over DevOps-praktijken in het algemeen. Wat zijn ze? Wat is het verschil? Hoe probeer je ze? Waarom zijn ze belangrijk?
De eerste praktijk waar je misschien van hebt gehoord heet Continuous Integration. Misschien heeft iemand in het project Continuous Integration (CI).
Het grootste probleem is dat wanneer ik iemand vraag: "Heeft u CI op het project?" en hij zegt: "Ja", en als ik vraag wat hij doet, beschrijft hij mij absoluut het hele automatiseringsproces. Dit is niet helemaal waar.
In feite is de praktijk van CI alleen gericht op het integreren van de code die verschillende mensen schrijven in een soort enkele codebasis. Dat is alles.
Naast CI zijn er meestal ook andere praktijken onderweg, zoals Continuous Deployment en Release Management, maar daar zullen we later over praten.
CI zelf vertelt ons dat verschillende mensen code schrijven en dat deze code continu moet worden geïntegreerd in één enkele codebasis.
Wat levert dit ons op en waarom is het belangrijk? Als we DotNet hebben, dan is dat goed, het is een gecompileerde taal, we kunnen onze applicatie compileren. Als het compileert, is dit al een goed teken. Dit betekent nog niets, maar het is het eerste goede teken dat we in ieder geval kunnen compileren.
Dan kunnen we wat testen doen, wat ook een aparte praktijk is. De tests zijn allemaal groen – dit is het tweede goede teken. Maar nogmaals, dit betekent niets.
Maar waarom zou je dit doen? Alle praktijken waar ik het vandaag over zal hebben, hebben ongeveer dezelfde waarde, dat wil zeggen ongeveer dezelfde voordelen, en worden ook ongeveer op dezelfde manier gemeten.
Ten eerste kunt u de levering versnellen. Hoe kunt u hierdoor de levering versnellen? Wanneer we nieuwe wijzigingen aanbrengen in onze codebasis, kunnen we meteen proberen iets met deze code te doen. We wachten niet tot het donderdag is, want donderdag geven we het vrij aan QA Environment, we doen het hier en hier.
Ik zal je een droevig verhaal uit mijn leven vertellen. Het was lang geleden, toen ik nog jong en knap was. Nu ben ik al jong, mooi en slim en bescheiden. Enige tijd geleden zat ik in een project. We hadden een groot team van ongeveer 30 ontwikkelaars. En we hadden een groot, groot Enterprise-project dat zich ongeveer tien jaar lang ontwikkelde. En we hadden verschillende vestigingen. In de repository hadden we een branch waarin ontwikkelaars liepen. En er was een branch die de versie van de code weergaf die in productie is.
De productietak liep 3 maanden achter op de tak die beschikbaar was voor ontwikkelaars. Wat betekent dit? Dit betekent dat zodra ik ergens een bug heb die in productie gaat vanwege de fout van de ontwikkelaars, omdat zij het hebben toegestaan, en vanwege de fout van QA, omdat ze ernaar hebben gekeken, dit betekent dat als ik een taak voor hotfix voor productie, dan moet ik mijn codewijzigingen van 3 maanden geleden ongedaan maken. Ik moet onthouden wat ik drie maanden geleden had en proberen het daar te repareren.
Als je deze ervaring nog niet hebt gehad, kun je het proberen bij je thuisproject. Het belangrijkste is: probeer het niet op een commerciële manier. Schrijf een paar regels code, vergeet ze een half jaar lang, en kom dan terug en probeer snel uit te leggen waar die regels code over gaan en hoe je ze kunt repareren of optimaliseren. Het is een heel, heel opwindende ervaring.
Als we een Continuous Integration-praktijk hebben, kunnen we dit hier en nu controleren met een aantal geautomatiseerde tools, zodra ik mijn code heb geschreven. Dit geeft mij misschien niet het volledige beeld, maar het zal niettemin op zijn minst een deel van de risico's wegnemen. En als er een mogelijke bug is, weet ik dat nu meteen, dat wil zeggen letterlijk binnen een paar minuten. Ik hoef geen drie maanden terug te draaien. Ik hoef maar 3 minuten terug te draaien. Een goede koffiemachine heeft niet eens de tijd om binnen 2 minuten koffie te zetten, dus dat is best gaaf.
Dit heeft de waarde dat het bij elk project keer op keer kan worden herhaald, d.w.z. niet alleen degene waarop je het hebt ingesteld. U kunt zowel de oefening zelf herhalen als dat CI zelf wordt herhaald voor elke nieuwe wijziging die u in het project aanbrengt. Hierdoor kunt u de middelen optimaliseren omdat uw team efficiënter werkt. Je zult niet langer een situatie hebben waarin een bug naar je toekomt vanuit de code waarmee je 3 maanden geleden hebt gewerkt. Je zult niet langer van context wisselen als je de eerste twee uur zit en probeert te begrijpen wat er toen is gebeurd en tot de essentie van de context doordringt voordat je iets gaat corrigeren.
Hoe kunnen we het succes of falen van deze praktijk meten? Als je aan de grote baas rapporteert wat we op het CI-project hebben geïmplementeerd, hoort hij bla bla bla. We hebben het geïmplementeerd, oké, maar waarom, wat heeft het ons opgeleverd, hoe meten we het, hoe correct of incorrect implementeren we het?
De eerste is dat we dankzij CI steeds vaker kunnen inzetten, en vaker juist omdat onze code potentieel stabieler is. Op dezelfde manier wordt onze tijd om een fout te vinden verkort en de tijd om deze fout te corrigeren wordt juist verkort omdat we hier en nu een antwoord van het systeem ontvangen over wat er mis is met onze code.
Een andere praktijk die we hebben is de Automation Testing-praktijk, die meestal samen met de CI-praktijk wordt geleverd. Ze gaan hand in hand.
Wat is belangrijk om hier te begrijpen? Het is belangrijk om te begrijpen dat onze tests verschillend zijn. En elke geautomatiseerde test is gericht op het oplossen van zijn eigen problemen. We hebben bijvoorbeeld unit-tests waarmee we een module afzonderlijk kunnen testen, d.w.z. Hoe werkt het in een vacuüm? Dit is goed.
We hebben ook integratietests waarmee we kunnen begrijpen hoe verschillende modules met elkaar integreren. Het is ook goed.
Mogelijk hebben we UI-automatiseringstests waarmee we kunnen controleren hoe goed het werk met de UI voldoet aan bepaalde eisen die door de klant zijn gesteld, enz.
De specifieke tests die u uitvoert, kunnen van invloed zijn op hoe vaak u ze uitvoert. Unit-tests zijn meestal kort en klein geschreven. En ze kunnen regelmatig worden gelanceerd.
Als we het hebben over UI-automatiseringstests, dan is het goed als uw project klein is. Uw UI-automatiseringstests kunnen voldoende tijd in beslag nemen. Maar meestal is een UI-automatiseringstest iets dat bij een groot project enkele uren in beslag neemt. En het is goed als het een paar uur is. Het enige is dat het geen zin heeft om ze voor elke build uit te voeren. Het is zinvol om ze 's nachts te laten draaien. En toen iedereen 's ochtends naar zijn werk kwam: zowel testers als ontwikkelaars, ontvingen ze een soort rapport dat we' s nachts de UI-autotest hadden uitgevoerd en deze resultaten kregen. En hier zal een uur werk van een server die controleert of uw product aan bepaalde eisen voldoet veel goedkoper zijn dan een uur werk van dezelfde QA-ingenieur, zelfs als hij een Junior QA-ingenieur is die werkt voor eten en dank. Toch zal een uur machinebediening goedkoper zijn. Daarom is het verstandig om daarin te investeren.
Ik heb nog een project waar ik aan heb gewerkt. We hadden sprints van twee weken voor dit project. Het project was groot, belangrijk voor de financiële sector en er kon geen fout worden gemaakt. En na een sprint van twee weken werd de ontwikkelingscyclus gevolgd door een testproces, dat nog eens vier weken duurde. Probeer je de omvang van de tragedie voor te stellen. We schrijven twee weken lang code, daarna doen we het in CodeFreeze, verpakken het in een nieuwe versie van de applicatie en rollen het uit naar testers. Testers testen het nog 4 weken, d.w.z. Terwijl zij het testen, hebben wij tijd om nog twee versies voor hen klaar te maken. Dit is een heel triest geval.
En we vertelden hen dat als je productiever wilt zijn, het zinvol is om geautomatiseerde testpraktijken te implementeren, omdat dit is wat je hier en nu pijn doet.
Oefen met continue implementatie. Geweldig, je bent klaar met bouwen. Dit is al goed. Uw code is gecompileerd. Nu zou het leuk zijn om deze build in een bepaalde omgeving te implementeren. Laten we zeggen in een omgeving voor ontwikkelaars.
Waarom is het belangrijk? Ten eerste kunt u kijken hoe succesvol u bent met het implementatieproces zelf. Ik heb projecten als deze ontmoet en als ik vraag: “Hoe implementeer je een nieuwe versie van de applicatie?”, vertellen de jongens me: “We assembleren het en verpakken het in een zip-archief. Wij sturen het per post naar de beheerder. De beheerder downloadt en breidt dit archief uit. En het hele kantoor begint te bidden dat de server de nieuwe versie zal ophalen.”
Laten we beginnen met iets eenvoudigs. Ze vergaten bijvoorbeeld CSS in het archief te plaatsen of vergaten de hashtag in de javascript-bestandsnaam te wijzigen. En als we een verzoek indienen bij de server, denkt de browser dat hij dit javascript-bestand al heeft en besluit het niet te downloaden. En er was een oude versie, er ontbrak iets. Over het algemeen kunnen er veel problemen zijn. Daarom kunt u met de praktijk van Continuous Deployment op zijn minst testen wat er zou gebeuren als u een schone referentie-image zou nemen en deze naar een volledig schone nieuwe omgeving zou uploaden. Je kunt zien waar dit toe leidt.
Ook als u code onderling integreert, d.w.z. tussen de opdracht, hierdoor kunt u ook zien hoe het eruit ziet in de gebruikersinterface.
Een van de problemen die zich voordoen als er veel gewoon Java-script wordt gebruikt, is dat twee ontwikkelaars onbezonnen een variabele met dezelfde naam in het vensterobject declareren. En dan, afhankelijk van je geluk. Wiens Java-scriptbestand als tweede wordt uitgetrokken, overschrijft de wijzigingen van de ander. Het is ook heel spannend. Je komt binnen: het ene werkt voor de één, het andere werkt niet voor de ander. En het is “geweldig” als het allemaal in productie komt.
De volgende praktijk die we hebben is de praktijk van automatisch herstel, namelijk teruggaan naar de vorige versie van de applicatie.
Waarom is dit belangrijk voor ontwikkelaars? Er zijn nog steeds mensen die zich de verre, verre jaren negentig herinneren, toen computers groot waren en programma's klein. En de enige manier om te webontwikkeling was via PHP. Het is niet zo dat PHP een slechte taal is, hoewel dat wel zo is.
Maar het probleem was anders. Toen we een nieuwe versie van onze php-site implementeerden, hoe hebben we deze dan geïmplementeerd? Meestal hebben we Far Manager of iets anders geopend. En uploadde deze bestanden naar FTP. En we realiseerden ons plotseling dat we een kleine, kleine bug hadden, we vergaten bijvoorbeeld een puntkomma te plaatsen of vergaten het wachtwoord voor de database te wijzigen, en er is een wachtwoord voor de database, die zich op de lokale host bevindt. En we besluiten snel verbinding te maken met FTP en de bestanden daar te bewerken. Dit is gewoon vuur! Dit is wat populair was in de jaren 90.
Maar als je niet naar de kalender hebt gekeken: de jaren negentig zijn bijna dertig jaar geleden. Nu gebeurt alles een beetje anders. En probeer je de omvang van de tragedie voor te stellen als ze je vertellen: “We zijn ingezet voor de productie, maar daar is iets misgegaan. Hier zijn uw FTP-login en wachtwoord. Maak verbinding met de productie en repareer het daar snel. Als je Chuck Norris bent, zal dit werken. Als dat niet het geval is, loop je het risico dat als je één bug oplost, je er nog eens 90 maakt. Dit is precies de reden waarom je met deze praktijk van terugdraaien naar de vorige versie veel kunt bereiken.
Zelfs als er op de een of andere manier iets ergs in de productie terechtkomt, dan is het slecht, maar niet fataal. U kunt teruggaan naar de vorige versie die u heeft. Noem het een back-up, als het gemakkelijker is om het in die terminologie waar te nemen. U kunt teruggaan naar de vorige versie. Gebruikers kunnen dan nog steeds met uw product werken en u beschikt over voldoende buffertijd. U kunt dit alles rustig en zonder haast meenemen en lokaal testen, repareren en vervolgens een nieuwe versie uploaden. Het is echt zinvol om dit te doen.
Laten we nu proberen de twee voorgaande praktijken op de een of andere manier te combineren. We krijgen een derde genaamd Release Management.
Als we het hebben over Continuous Deployment in zijn klassieke vorm, zeggen we dat we code uit een bepaalde branch uit de repository moeten halen, deze moeten compileren en implementeren. Het is goed als we dezelfde omgeving hebben. Als we meerdere omgevingen hebben, betekent dit dat we de code elke keer moeten ophalen, zelfs uit dezelfde commit. We zullen het er elke keer uithalen, we zullen het elke keer bouwen en we zullen het inzetten in een nieuwe omgeving. Ten eerste is dit tijd, want het bouwen van een project, als je een groot project hebt en uit de jaren 90 komt, kan enkele uren duren.
Daarnaast is er nog een ander verdriet. Wanneer je bouwt, zelfs op dezelfde machine, bouw je dezelfde bronnen, je hebt nog steeds geen garantie dat deze machine zich in dezelfde staat bevindt als tijdens de laatste build.
Stel dat iemand binnenkwam en DotNet voor u heeft bijgewerkt, of omgekeerd, dat iemand heeft besloten iets te verwijderen. En dan heb je de cognitieve dissonantie dat we vanuit deze commit twee weken geleden een build aan het bouwen waren en alles in orde was, maar nu lijkt het dezelfde machine, dezelfde commit, dezelfde code die we proberen te bouwen, maar het werkt niet . Je zult hier lang mee te maken hebben en het is niet zo dat je er ooit achter komt. Je zult op zijn minst je zenuwen flink bederven.
Daarom suggereert de praktijk van Release Management de introductie van een extra abstractie, een artefactrepository of galerij of bibliotheek. Je kunt het noemen zoals je wilt.
Het belangrijkste idee is dat zodra we daar een soort commit hebben, bijvoorbeeld in een branch die we willen implementeren in onze verschillende omgevingen, we applicaties van deze commit verzamelen en alles wat we nodig hebben voor deze applicatie, we deze inpakken. in een zip-archief en bewaar het op een betrouwbare opslagplaats. En uit deze opslag kunnen we dit zip-archief op elk moment ophalen.
Vervolgens nemen we het en implementeren het automatisch in de ontwikkelomgeving. We racen daar en als alles goed is, gaan we naar het podium. Als alles goed is, zetten we hetzelfde archief in productie, dezelfde binaire bestanden, precies één keer gecompileerd.
Als we zo'n galerij hebben, helpt het ons bovendien ook de risico's aan te pakken die we op de laatste dia hebben besproken toen we spraken over het terugdraaien naar de vorige versie. Als u per ongeluk iets verkeerd heeft geïmplementeerd, kunt u altijd een andere eerdere versie uit deze galerij halen en deze op dezelfde manier in deze omgevingen ongedaan maken. Hierdoor kun je gemakkelijk teruggaan naar de vorige versie als er iets misgaat.
Er is nog een mooie praktijk. U en ik begrijpen allemaal dat wanneer we onze applicaties terugzetten naar een eerdere versie, dit kan betekenen dat we ook de infrastructuur van de vorige versie nodig hebben.
Als we het hebben over virtuele infrastructuur, denken veel mensen dat dit iets is dat beheerders hebben opgezet. En als u bijvoorbeeld een nieuwe server nodig heeft waarop u een nieuwe versie van uw applicatie wilt testen, moet u een ticket schrijven naar de beheerders of ontwikkelaars. Devops zullen hiervoor 3 weken nodig hebben. En na 3 weken vertellen ze je dat we een virtuele machine voor je hebben geïnstalleerd, met één core, twee gigabyte RAM en een Windows-server zonder DotNet. Jij zegt: “Maar ik wilde DotNet.” Zij: “Oké, kom over drie weken terug.”
Het idee is dat u, door Infrastructure as Code te gebruiken, uw virtuele infrastructuur als gewoon een hulpbron kunt behandelen.
Als iemand van jullie applicaties ontwikkelt op DotNet, heb je misschien gehoord van een bibliotheek genaamd Entity Framework. En je hebt misschien zelfs gehoord dat Entity Framework een van de benaderingen is die Microsoft actief promoot. Voor het werken met een database is dit een aanpak genaamd Code First. Dit is wanneer u in code beschrijft hoe u wilt dat uw database eruit ziet. En dan implementeer je de applicatie. Het maakt verbinding met de database, bepaalt zelf welke tabellen er zijn en welke niet, en creëert alles wat je nodig hebt.
Hetzelfde kunt u doen met uw infrastructuur. Er is geen verschil tussen of u een database nodig heeft voor een project of dat u voor een project een Windows-server nodig heeft. Het is slechts een hulpbron. En u kunt het maken van deze bron automatiseren, u kunt de configuratie van deze bron automatiseren. Dienovereenkomstig hoeft u elke keer dat u een nieuw concept of een nieuwe aanpak wilt testen geen ticket naar devops te schrijven, u kunt eenvoudigweg een geïsoleerde infrastructuur voor uzelf inzetten op basis van kant-en-klare sjablonen, van kant-en-klare scripts en deze implementeren. daar al je experimenten. Je kunt dit verwijderen, wat resultaten krijgen en er verder over rapporteren.
De volgende praktijk, die ook bestaat en ook belangrijk is, maar waar weinig mensen gebruik van maken, is Application Performance Monitoring.
Ik wilde maar één ding zeggen over het monitoren van applicatieprestaties. Wat is het belangrijkste aan deze praktijk? Dit is wat Application Performance Monitoring ongeveer hetzelfde is als het repareren van een appartement. Dit is geen definitieve toestand, het is een proces. Je moet het regelmatig doen.
Op een goede manier zou het goed zijn om Application Performance Monitoring op bijna elke build uit te voeren, hoewel dit, zoals u begrijpt, niet altijd mogelijk is. Maar het moet op zijn minst voor elke release worden uitgevoerd.
Waarom is het belangrijk? Want als u plotseling een prestatiedaling ervaart, moet u duidelijk begrijpen waarom. Als uw team sprints van bijvoorbeeld twee weken heeft, dan moet u uw applicatie minstens één keer in de twee weken op een aparte server implementeren, waar u een duidelijk vaste processor, RAM, schijven, enz. heeft. En voer die dezelfde prestatietests uit . Je krijgt het resultaat. Kijk hoe het is veranderd ten opzichte van de vorige sprint.
En als je erachter komt dat de trekking ergens scherp is gedaald, betekent dit dat dit alleen maar te danken is aan de veranderingen die de afgelopen twee weken hebben plaatsgevonden. Hierdoor kunt u het probleem veel sneller identificeren en oplossen. En nogmaals, dit zijn grofweg dezelfde statistieken waarmee je kunt meten hoe succesvol je het hebt gedaan.
De volgende praktijk die we hebben is de configuratiemanagementpraktijk. Er zijn maar weinig mensen die dit serieus nemen. Maar geloof me, dit is eigenlijk een heel ernstige zaak.
Er was onlangs een grappig verhaal. De jongens kwamen naar me toe en zeiden: "Help ons een beveiligingsaudit van onze applicatie uit te voeren." We hebben lang samen naar de code gekeken, ze vertelden me over de applicatie, tekenden diagrammen. En plus of min alles was logisch, begrijpelijk, veilig, maar er was één MAAR! Ze hadden configuratiebestanden in hun bronbeheer, inclusief die uit de productie met de IP-database, met logins en wachtwoorden om verbinding te maken met deze databases, enz.
En ik zeg: “Jongens, oké, jullie hebben je productieomgeving afgesloten met een firewall, maar het feit dat je de login en het wachtwoord voor de productiedatabase rechtstreeks in het bronbeheer hebt staan en elke ontwikkelaar deze kan lezen, is al een enorm veiligheidsrisico. . En hoe superveilig je applicatie ook is vanuit code-oogpunt, als je het in bronbeheer laat staan, zul je nergens een audit doorstaan.” Dat is waar ik het over heb.
Configuratiebeheer. Het kan zijn dat we verschillende configuraties hebben in verschillende omgevingen. We kunnen bijvoorbeeld verschillende logins en wachtwoorden hebben voor databases voor QA, demo, productieomgeving, enz.
Deze configuratie kan ook worden geautomatiseerd. Het moet altijd gescheiden zijn van de applicatie zelf. Waarom? Omdat je de applicatie één keer hebt gebouwd, en het vervolgens voor de applicatie niet uitmaakt of je via dit en dat IP-adres of dat en dat IP-adres verbinding maakt met de SQL-server, zou het hetzelfde moeten werken. Daarom, als een van jullie plotseling nog steeds de verbindingsreeks in de code hardcodeert, onthoud dan dat ik je zal vinden en je zal straffen als je merkt dat je met mij in hetzelfde project zit. Deze wordt altijd in een aparte configuratie geplaatst, bijvoorbeeld in web.config.
En deze configuratie wordt al apart beheerd, dit is dus precies het moment waarop een ontwikkelaar en een beheerder in dezelfde ruimte kunnen komen zitten. En de ontwikkelaar kan zeggen: “Kijk, hier zijn de binaire bestanden van mijn applicatie. Ze werken. De applicatie heeft een database nodig om te kunnen werken. Hier naast de binaire bestanden is er een bestand. In dit bestand is dit veld verantwoordelijk voor de login, dit is voor het wachtwoord, dit is voor het IP-adres. Implementeer het overal." En het is eenvoudig en duidelijk voor de beheerder. Door deze configuratie te beheren, kan hij het werkelijk overal inzetten.
En de laatste praktijk waar ik het over wil hebben, is een praktijk die heel erg verband houdt met wolken. En het geeft maximaal effect als je in de cloud werkt. Dit is het automatisch verwijderen van uw omgeving.
Ik weet dat er verschillende mensen op deze conferentie aanwezig zijn uit de teams waarmee ik werk. En bij alle teams waarmee ik werk, gebruiken we deze praktijk.
Waarom? Het zou natuurlijk geweldig zijn als elke ontwikkelaar een virtuele machine had die 24/7 zou werken. Maar misschien is dit nieuws voor je, misschien heb je niet opgelet, maar de ontwikkelaar zelf werkt niet 24/7. Een ontwikkelaar werkt doorgaans 8 uur per dag. Zelfs als hij vroeg naar zijn werk komt, heeft hij een grote lunch en gaat hij naar de sportschool. Laat het 12 uur per dag zijn wanneer de ontwikkelaar deze bronnen daadwerkelijk gebruikt. Volgens onze wetgeving hebben we 5 van de 7 dagen in een week die als werkdagen worden beschouwd.
Dienovereenkomstig zou deze machine op weekdagen niet 24 uur moeten werken, maar slechts 12 uur, en in het weekend zou deze machine helemaal niet moeten werken. Het lijkt erop dat alles heel eenvoudig is, maar wat is belangrijk om hier te zeggen? Door deze eenvoudige praktijk volgens dit basisschema te implementeren, kunt u de kosten voor het onderhoud van deze omgevingen met 70% verlagen, dat wil zeggen dat u de prijs van uw ontwikkelaar, QA, demo en omgeving hebt gedeeld door 3.
De vraag is: wat te doen met de rest van het geld? De ontwikkelaars zouden bijvoorbeeld ReSharper moeten kopen als ze dat nog niet hebben gedaan. Of organiseer een cocktailparty. Als je voorheen één omgeving had waarin zowel dev als QA graasden, en dat is alles, dan kun je nu drie verschillende maken die geïsoleerd zullen zijn, en mensen zullen zich niet met elkaar bemoeien.
Wat betreft de dia met continue prestatiemeting: hoe kunnen we de prestaties vergelijken als we 1 records in de database van het project hadden, terwijl er twee maanden later een miljoen zijn? Hoe begrijp je waarom en wat is het nut van het meten van prestaties?
Dit is een goede vraag, omdat u altijd de prestaties op dezelfde bronnen moet meten. Dat wil zeggen, je rolt nieuwe code uit, je meet de prestaties van de nieuwe code. U moet bijvoorbeeld verschillende prestatiescenario's testen. Stel dat u wilt testen hoe de applicatie presteert bij lichte belasting, waarbij er 1 gebruikers zijn en de databasegrootte 000 gigabyte is. Je hebt het gemeten en de cijfers gekregen. Vervolgens nemen we een ander scenario. Bijvoorbeeld 5 gebruikers, databasegrootte 5 terabyte. We hebben de resultaten ontvangen en onthouden.
Wat is hier belangrijk? Het belangrijkste hier is dat u, afhankelijk van het scenario, de hoeveelheid gegevens, het aantal gelijktijdige gebruikers, enz., tegen bepaalde limieten aan kunt lopen. Bijvoorbeeld tot de limiet van een netwerkkaart, of tot de limiet van een harde schijf, of tot de limiet van de processormogelijkheden. Dit is wat voor u belangrijk is om te begrijpen. In verschillende scenario’s loop je tegen bepaalde grenzen aan. En je moet de cijfers begrijpen als je ze tegenkomt.
Gaat het om het meten van prestaties in een speciale testomgeving? Dat wil zeggen, dit is geen productie?
Ja, dit is geen productie, dit is een testomgeving, deze is altijd hetzelfde zodat je deze kunt vergelijken met eerdere metingen.
Begrepen, bedankt!
Als er geen vragen zijn, denk ik dat we kunnen afronden. Bedankt!
Bron: www.habr.com