{"id":38747,"date":"2019-10-31T22:25:42","date_gmt":"2019-10-31T19:25:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\/"},"modified":"2019-10-31T22:25:42","modified_gmt":"2019-10-31T19:25:42","slug":"infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","title":{"rendered":"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej, Habr! Tidligere har jeg klaget over livet i paradigmet Infrastructure as code og ikke tilbudt l\u00f8sninger p\u00e5 den eksisterende situation. I dag er jeg tilbage for at fort\u00e6lle, hvilke tilgange og praksisser der kan hj\u00e6lpe med at bryde fri fra afgrundens fortvivlelse og styre situationen i den rigtige retning. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e23fbf20980e731ae1cdb4719c97eb00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nI den tidligere artikel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">\u00abInfrastructure as code: et f\u00f8rste m\u00f8de\u00bb<\/a><\/noindex> Jeg delte mine indtryk af dette omr\u00e5de, fors\u00f8gte at reflektere over den nuv\u00e6rende situation og endda foreslog, at de standardpraksisser, som alle udviklere kender, kunne hj\u00e6lpe. Det kunne virke som om, der var mange klager over livet, men der manglede forslag til, hvordan man kunne komme ud af den vanskelige situation. <\/p>\n<h2>Hvem er vi, hvor er vi, og hvilke problemer har vi<\/h2>\n<p>\nI \u00f8jeblikket er vi i SRE Onboarding Team, som best\u00e5r af seks programm\u00f8rer og tre infrastrukturingen\u00f8rer. Vi fors\u00f8ger alle at skrive Infrastructure as code (IaC). Vi g\u00f8r det, fordi vi grundl\u00e6ggende kan skrive kode og har en baggrund som udviklere af \"over gennemsnittet\" niveau. <\/p>\n<ul>\n<li>Vi har et s\u00e6t fordele: en bestemt baggrund, kendskab til praksis, evne til at skrive kode, og lysten til at l\u00e6re nyt. <\/li>\n<li>Og der er den svage side, ogs\u00e5 kendt som ulempe: mangel p\u00e5 viden om infrastrukturens materie. <\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Teknologistekken, vi bruger i vores IaC.<\/b><\/p>\n<ul>\n<li>Terraform til at oprette ressourcer.<\/li>\n<li>Packer til at bygge billeder. Det er Windows, CentOS 7 billeder.<\/li>\n<li>Jsonnet til at lave kraftige builds i drone.io, samt til at generere packer json og vores Terraform moduler.<\/li>\n<li>Azure.<\/li>\n<li>Ansible til klarg\u00f8ring af billeder.<\/li>\n<li>Python til st\u00f8ttev\u00e6rkt\u00f8jer og provisioneringsscripts.<\/li>\n<li>Og alt dette i VSCode med plugins delt mellem teammedlemmerne.<\/li>\n<\/ul>\n<p>Min konklusion var, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">om dotCloud, s\u00e5 her er essensen: det er en platform som en tjeneste (PaaS), der g\u00f8r det muligt for kunderne at k\u00f8re et bredt udvalg af applikationer (Java, PHP, Python \u2026), med st\u00f8tte til et bredt udvalg af datatjenester (MongoDB, MySQL, Redis \u2026) og et arbejdsgang som hos Heroku: du uploader din kode til platformen, den bygger containerbilleder og implementerer dem.<\/a><\/noindex> at jeg fors\u00f8gte at indgyde (f\u00f8rst og fremmest i mig selv) optimisme, jeg ville sige, at vi vil pr\u00f8ve de tilgange og praksisser, vi kender, for at k\u00e6mpe med de vanskeligheder og kompleksiteter, der findes i dette omr\u00e5de. <\/p>\n<p>I \u00f8jeblikket k\u00e6mper vi med f\u00f8lgende IaC-problemer:<\/p>\n<ul>\n<li>Ufuldkommenhed i v\u00e6rkt\u00f8jerne, redskaber til kodning.<\/li>\n<li>Langsom udrulning. Infrastruktur er en del af den virkelige verden, og den kan v\u00e6re langsom.<\/li>\n<li>Mangel p\u00e5 tilgange og praksisser.<\/li>\n<li>Vi er nye og ved ikke meget.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ekstrem programmering (XP) kommer til unds\u00e6tning.<\/h2>\n<p>\nAlle udviklere er godt bekendt med ekstrem programmering (XP) og de praksisser, der ligger bag. Mange af os har arbejdet med denne tilgang, og den har v\u00e6ret vellykket. S\u00e5 hvorfor ikke udnytte de principper og praksisser, der er etableret der, for at overvinde infrastrukturs udfordringer? Vi har besluttet at anvende denne tilgang og se, hvad der kommer ud af det.<\/p>\n<p><b class=\"spoiler_title\">Vurdering af anvendeligheden af XP-tilgangen i dit felt<\/b>Jeg pr\u00e6senterer beskrivelsen af det milj\u00f8, hvor XP er velegnet, og hvordan det relaterer sig til os: <\/p>\n<p>1. Dynamisk \u00e6ndrende softwarekrav. Vi var klar over, hvad det endelige m\u00e5l var. Men i detaljerne kunne der varieres. Vi bestemmer selv, hvor vi skal dreje hen, s\u00e5 kravene \u00e6ndrer sig fra tid til anden (prim\u00e6rt af os selv). Hvis vi ser p\u00e5 SRE-teamet, der selv laver automatisering og samtidig begr\u00e6nser kravene og omfanget af arbejdet, s\u00e5 passer dette punkt godt. <\/p>\n<p>2. Risici forbundet med faste tidsprojekter, der bruger ny teknologi. Vi kan st\u00e5 overfor risici ved brugen af nogle ukendte ting for os. Og det er 100 % vores tilf\u00e6lde. Hele vores projekt er brugen af teknologier, som vi ikke helt har v\u00e6ret bekendt med. Det er generelt et konstant problem, da der hele tiden dukker mange nye teknologier op inden for infrastrukturen. <\/p>\n<p>3,4. Lille, co-lokation udvidet udviklingsteam. Den teknologi, du bruger, muligg\u00f8r automatiserede enheds- og funktionelle tests. Disse to punkter passer ikke helt til os. For det f\u00f8rste er vi ikke et co-lokationsteam, for det andet er vi ni personer, hvilket kan betragtes som et stort team. Selvom, if\u00f8lge nogle definitioner af et \u201estort\u201c team, er mange over 14 personer. <\/p>\n<p>Lad os se p\u00e5 nogle praktikker fra XP og hvordan de p\u00e5virker hastigheden og kvaliteten af feedback.<\/p>\n<h4>Princippet om feedback-loopet i XP<\/h4>\n<p>\nEfter min opfattelse er feedback et svar p\u00e5 sp\u00f8rgsm\u00e5let, om jeg g\u00f8r det rigtigt, om vi bev\u00e6ger os i den rigtige retning? I XP er der en guddommelig skema til dette: feedback-loopet over tid. Det interessante er, at jo lavere vi er, jo hurtigere har vi mulighed for at f\u00e5 feedback til at besvare de n\u00f8dvendige sp\u00f8rgsm\u00e5l. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e381fb2d7937cbd1978fd6740e63e790.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet er et ret interessant emne til diskussion, hvordan vi i IT-industrien hurtigt kan f\u00e5 feedback. Forestil dig, hvor smertefuldt det er at udf\u00f8re et projekt i et halvt \u00e5r og f\u00f8rst derefter finde ud af, at der i starten blev lagt en fejl. S\u00e5dan noget sker b\u00e5de i design og i opbygningen af komplekse systemer. <\/p>\n<p>I vores tilf\u00e6lde hj\u00e6lper IaC os med feedback. Jeg laver straks en mindre justering i ovenst\u00e5ende skema: udgivelsesplanen har ikke en m\u00e5nedlig cykel, men finder sted flere gange om dagen. Til denne cyklus er der knyttet nogle praksisser, som vi vil se n\u00e6rmere p\u00e5.<\/p>\n<blockquote><p>Vigtigt: feedback kan blive l\u00f8sningen p\u00e5 alle ovenst\u00e5ende problemer. I kombination med XP-praksisserne kan det tr\u00e6kke os op fra afgrundens desperation.<\/p><\/blockquote>\n<p><\/p>\n<h2>S\u00e5dan tr\u00e6kker du dig selv op fra afgrundens desperation: tre praksisser<\/h2>\n<p><\/p>\n<h4>Tests <\/h4>\n<p>\nTests n\u00e6vnes to gange i XP-feedbackcyklussen. Det er ikke uden grund. De er ekstremt vigtige for hele teknikken bag ekstrem programmering. <\/p>\n<p>Det foruds\u00e6ttes, at du har Unit- og Acceptance-tests. Nogle giver dig feedback p\u00e5 et par minutter, andre p\u00e5 et par dage, da de skrives l\u00e6ngere og k\u00f8res sj\u00e6ldnere. <\/p>\n<p>Der er en klassisk testpyramide, der viser, at der b\u00f8r v\u00e6re flere af nogle tests. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/29f3217f11b67378c9c0c3f14fab9d61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvordan er dette schema anvendeligt for os i IaC-projektet? Faktisk\u2026 p\u00e5 ingen m\u00e5de. <\/p>\n<ul>\n<li>Selvom vi b\u00f8r have mange Unit-tests, kan vi ikke have for mange. Enten tester de noget meget indirekte. Faktisk kan man sige, at vi slet ikke skriver dem. Men her er et par anvendelser for s\u00e5danne tests, som vi alligevel har form\u00e5et at lave:\n<ol>\n<li>Test af kode p\u00e5 jsonnet. Det er for eksempel vores build-pipeline i drone, som er ret kompleks. Koden p\u00e5 jsonnet er godt d\u00e6kket af tests. <br \/>\n Vi bruger denne <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/yugui\/jsonnetunit\">Unit testing framework for Jsonnet<\/a><\/noindex>. <\/li>\n<li> Tests p\u00e5 scripts, der udf\u00f8res ved opstart af ressourcen. Scripts i Python, og derfor kan tests skrives til dem.<\/li>\n<\/ol>\n<\/li>\n<li>Der er potentielt mulighed for at teste konfigurationen i tests, men vi g\u00f8r det ikke. Der er ogs\u00e5 mulighed for at konfigurere validering af ressourcekonfigurationsregler gennem <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wata727\/tflint\">tflint<\/a><\/noindex>. Men for Terraform er der simpelthen for grundl\u00e6ggende kontroller, men mange testscenarier er skrevet til AWS. Og vi er p\u00e5 Azure, s\u00e5 det passer ikke igen.<\/li>\n<li>Komponent- og integrations tests: her afh\u00e6nger det af, hvordan du klassificerer dem og hvor du placerer dem. Men de fungerer grundl\u00e6ggende.\n<p>S\u00e5dan ser integrations tests ud. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/b4771e9e5d329ffb2ba565ead7fdddfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er et eksempel fra opbygning af billeder i Drone CI. For at n\u00e5 dem, skal man vente 30 minutter, mens Packer-billedet opbygges, og derefter yderligere 15 minutter, mens de k\u00f8res. Men de eksisterer! <\/p>\n<p><b class=\"spoiler_title\">Algoritme til billedkontrol<\/b> <\/p>\n<ol>\n<li>F\u00f8rst skal Packer forberede billedet helt.<\/li>\n<li>Ved siden af testen er der terraform med lokal tilstand, som vi bruger til at implementere dette image. <\/li>\n<li>Under implementeringen bruges en lille modul, der ligger ved siden af, for at g\u00f8re det nemmere at arbejde med billedet. <\/li>\n<li>N\u00e5r VM'en er blevet implementeret fra billedet, kan vi begynde at udf\u00f8re tests. Prim\u00e6rt udf\u00f8res testene p\u00e5 maskinen. Vi kontrollerer, hvordan skripterne k\u00f8rte ved opstart, og hvordan d\u00e6monerne fungerer. For dette logger vi ind p\u00e5 den netop oprettede maskine via ssh eller winrm og kontrollerer konfigurationens tilstand eller om tjenesterne er startet.<\/li>\n<\/ol>\n<p>\n <\/li>\n<li>En lignende situation g\u00e6lder for integrationstests og moduler til terraform. Her er en kort tabel, der forklarer karakteristikaene ved s\u00e5danne tests.\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e2624fb97831701e374a7e8e7fe39a16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFeedback p\u00e5 pipelinen tager cirka 40 minutter. Alt sker meget langsomt. Det kan bruges til regression, men til ny udvikling er det slet ikke realistisk. Hvis man forbereder sig meget, forbereder running, skripter, kan det forkortes til 10 minutter. Men det er stadig ikke unit-tests, der tager 5 sekunder for 100 tests. <\/li>\n<\/ul>\n<p>\nManglen p\u00e5 unit-tests ved opbygning af billeder eller terraform-moduler tvinger os til at overf\u00f8re arbejdet til separate tjenester, som vi bare kan kalde via REST eller til Python-scripts.<\/p>\n<p>For eksempel havde vi brug for at f\u00e5 det til at fungere, s\u00e5 n\u00e5r den virtuelle maskine starter, registrerer den sig i tjenesten <noindex><a rel=\"nofollow\" href=\"https:\/\/www.scaleft.com\/\">ScaleFT<\/a><\/noindex>, og n\u00e5r den virtuelle maskine slettes, fjerner den sig selv.<\/p>\n<p>Da ScaleFT fungerer som en tjeneste, er vi n\u00f8dt til at arbejde med det via API. Der blev skrevet en wrapper, som vi kan kalde og sige: \"G\u00e5 ind og slet dette, dette\". Den gemmer alle n\u00f8dvendige indstillinger og adgangsoplysninger. <\/p>\n<p>Vi kan nu skrive normale tests p\u00e5 dette, da det ikke adskiller sig fra almindelig software: en API mockes, du kalder det, og vi ser hvad der sker. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/dc17aaa64038acb080669d31fe8ecfe0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p>Resultaterne af testene: Unit-testning, som burde give OS p\u00e5 et minut, giver det ikke. Andre h\u00f8jere tests p\u00e5 pyramiden giver effekt, men d\u00e6kker kun en del af problemerne. <\/p><\/blockquote>\n<h4>Parprogrammering<\/h4>\n<p>\nTests are certainly good. You can write many of them, and they can come in different types. They will operate at their levels and provide us with feedback. However, the issue with poor unit tests that yield the quickest OS still remains. Yet, we still desire a fast OS, as it is easy and pleasant to work with. Not to mention the quality of the resulting solution. Fortunately, there are techniques that allow for even faster feedback than unit tests. This is where pair programming comes in.<\/p>\n<p>When writing code, you want to receive feedback on its quality as quickly as possible. Yes, you can write everything in a feature branch (so as not to break anything for anyone), make a pull request on GitHub, assign someone whose opinion carries weight, and wait for a response. <\/p>\n<p>But the wait can be long. People are all busy, and the response, even if it comes, may not be of the highest quality. Let's assume the answer arrives immediately, and the reviewer instantly understands the entire intention, but the feedback still comes with a delay, post-factum. What you want is earlier feedback. This is exactly what pair programming aims for \u2013 to get immediate feedback while writing.<\/p>\n<p>Next, I present the styles of pair programming and their applicability in working on IaC: <\/p>\n<p><b>1. Classic, Experienced + Experienced, change by timer.<\/b> Two roles \u2013 driver and navigator. Two people. They work on the same code and switch roles after a predetermined time interval. <\/p>\n<p>Let's consider the compatibility of our problems with this style: <\/p>\n<ul>\n<li>Problem: imperfection of tools and means for code development. <br \/>\nNegative impact: longer development time, we slow down, disrupting the pace\/rhythm of work.<br \/>\n How we cope: we apply different tooling, a common IDE, and we also learn shortcuts.<\/li>\n<li> Problem: slow deployment. <br \/>\nNegative impact: increases the time to create a working piece of code. We get bored while waiting, our hands reach for something else to do while we wait. <br \/>\nHow we cope: we have not overcome this.<\/li>\n<li> Problem: lack of approaches and practices. <br \/>\nNegative impact: no knowledge of what is good or bad. This prolongs the feedback process. <br \/>\nHow we cope: exchanging opinions and practices in pair work nearly resolves the issue.<\/li>\n<\/ul>\n<p>\nHovedproblemet med at anvende denne stil i IaC er det uj\u00e6vne arbejde tempo. I traditionel softwareudvikling har man en meget j\u00e6vn fremdrift. Man kan bruge fem minutter p\u00e5 at skrive N. Bruge ti minutter p\u00e5 at skrive 2N, 15 minutter \u2013 3N. Her kan man bruge fem minutter p\u00e5 at skrive N og derefter bruge yderligere 30 minutter p\u00e5 at skrive en tiendedel af N. Her ved man ikke noget, man st\u00e5r stille, og det tager tid at finde ud af tingene, hvilket distraherer fra selve programmeringen. <\/p>\n<blockquote><p>Konklusion: I sin rene form passer det ikke til os.<\/p><\/blockquote>\n<p><b>2. Ping-pong. Denne tilgang indeb\u00e6rer, at \u00e9n deltager skriver en test, mens en anden implementerer den.<\/b> Da det er kompliceret med unit-tests, og man er n\u00f8dt til at skrive en langvarig integreringstest, forsvinder al lethed ved ping-pong. <\/p>\n<p>Jeg kan sige, at vi har fors\u00f8gt at adskille ansvarsomr\u00e5derne for design af testscenarier og implementering af koden under dem. \u00c9n deltager opfandt scenariet, og i denne del af arbejdet var han ansvarlig, han havde det sidste ord. Den anden var ansvarlig for implementeringen. Det fungerede godt. Kvaliteten af scenariet \u00f8ges med denne tilgang. <\/p>\n<blockquote><p>Konklusion: Desv\u00e6rre tillader arbejdstempoet ikke at bruge ping-pong som en praksis for parprogrammering i IaC.<\/p><\/blockquote>\n<p>\n <b>3. Strong Style.<\/b> <noindex><a rel=\"nofollow\" href=\"http:\/\/llewellynfalco.blogspot.com\/2014\/06\/llewellyns-strong-style-pairing.html\">En kompliceret praksis.<\/a><\/noindex>Id\u00e9en er, at \u00e9n deltager fungerer som en styrende navigator, mens den anden har rollen som udf\u00f8rende driver. Navigatoren har det fulde beslutningsret. Driveren skriver kun og kan med ord p\u00e5virke det, der sker. Roller skifter ikke i lang tid. <\/p>\n<p>Godt til l\u00e6ring, men kr\u00e6ver st\u00e6rke bl\u00f8de kompetencer. Her st\u00f8dte vi p\u00e5 problemer. Teknikken gik sv\u00e6rt. Og det handler ikke engang om infrastrukturen. <\/p>\n<blockquote><p>Konklusion: Potentialet for anvendelse er der, vi giver ikke op p\u00e5 fors\u00f8get.<\/p><\/blockquote>\n<p>\n<b>4. Mobbing, swarming og alle kendte, men ikke n\u00e6vnte stilarter.<\/b> overvejes ikke, da vi ikke har pr\u00f8vet dem, og vi kan ikke sige noget om dem i konteksten af vores arbejde.<\/p>\n<blockquote><p>Generelle resultater af brugen af pair programming:<\/p>\n<ul>\n<li>Vi har et uj\u00e6vnt arbejdstempo, som forstyrrer.<\/li>\n<li>Vi er st\u00f8dt ind i ikke tilstr\u00e6kkelige gode bl\u00f8de f\u00e6rdigheder. Og emneomr\u00e5det bidrager ikke til at overvinde disse mangler.<\/li>\n<li>Lange tests og problemer med v\u00e6rkt\u00f8jerne g\u00f8r parudvikling besv\u00e6rlig.<\/li>\n<\/ul>\n<\/blockquote>\n<p><b>5. P\u00e5 trods af dette var der ogs\u00e5 succeser. Vi opfandt vores egen metode \"Sammenkomst - Adskillelse\".<\/b> Lad mig kort beskrive, hvordan den fungerer. <\/p>\n<p>Vi har faste partnere i flere dage (mindre end en uge). Vi arbejder sammen om en opgave. I et stykke tid sidder vi sammen: en skriver, den anden sidder og observerer som supportteam. S\u00e5 adskiller vi os i et stykke tid, hver is\u00e6r laver uafh\u00e6ngige ting, og s\u00e5 m\u00f8des vi igen, synkroniserer os meget hurtigt, laver noget sammen og adskiller os igen. <\/p>\n<h4>Planl\u00e6gning og kommunikation<\/h4>\n<p>\nDen sidste blok af praksis, hvor problemer i OS l\u00f8ses, er organiseringen af arbejdet med selve opgaverne. Dette inkluderer ogs\u00e5 erfaringsudveksling, der ligger uden for pararbejde. Lad os se p\u00e5 tre praksisser:<\/p>\n<p><b>1. Opgaver gennem m\u00e5lsystem.<\/b> Den overordnede projektledelse organiserede vi gennem et tr\u00e6, der uendeligt str\u00e6kker sig ind i fremtiden. Teknisk set udf\u00f8res ledelsen i Miro. Der er en opgave - den er en mellemindstilling. Fra den g\u00e5r der enten mindre m\u00e5l eller grupper af opgaver. Fra dem kommer selve opgaverne. Alle opgaver oprettes og h\u00e5ndteres p\u00e5 denne tavle. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/fe601e959f0055de4f7f4c39ae713c31.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDenne ordning giver ogs\u00e5 feedback, som sker \u00e9n gang om dagen, n\u00e5r vi synkroniserer os p\u00e5 m\u00f8derne. Tilstedev\u00e6relsen af en f\u00e6lles plan foran alle, som samtidig er struktureret og helt \u00e5ben, g\u00f8r, at alle er opdaterede p\u00e5, hvad der foreg\u00e5r, og hvor langt vi er kommet med fremskridtene. <\/p>\n<p>Fordele ved visuel opfattelse af opgaver:<\/p>\n<ul>\n<li>\u00c5rsagssammenh\u00e6ng. Hver opgave f\u00f8rer til et eller andet globalt m\u00e5l. Opgaver grupperes efter mindre m\u00e5l. Infrastrukturens dom\u00e6ne er i sig selv ret teknisk. Det er ikke altid tydeligt med det samme, hvilken konkret indvirkning for eksempel skrivningen af en ranbook om migration til en anden nginx har p\u00e5 virksomheden. Tilstedev\u00e6relsen af et m\u00e5l-kort i n\u00e6rheden g\u00f8r det mere forst\u00e5eligt.<br \/>\n <img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/fc4da9d277f7dc186a5710cf2be4419c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n \u00c5rsagssammenh\u00e6ng er en vigtig egenskab ved opgaver. Den svarer direkte p\u00e5 sp\u00f8rgsm\u00e5let: \"G\u00f8r jeg det rette?\" <\/li>\n<li>Parallellitet. Vi er ni personer, og det er fysisk umuligt for os alle at kaste os over \u00e9n opgave. Opgaver fra \u00e9t omr\u00e5de er heller ikke altid tilstr\u00e6kkelige. Vi er tvunget til at parallelisere arbejdet mellem sm\u00e5 arbejdsgrupper. Disse grupper fokuserer et stykke tid p\u00e5 deres opgave, og de kan f\u00e5 ekstra ressourcer. Der kan ogs\u00e5 ske \u00e6ndringer i gruppen; nogle kan tage ferie, andre forbereder et opl\u00e6g til DevOps-conf, eller skriver en artikel til Habr. At vide, hvilke m\u00e5l og opgaver der kan udf\u00f8res parallelt, bliver meget vigtigt. <\/li>\n<\/ul>\n<p>\n<b>2. Skiftende facilitatorer for morgenm\u00f8der.<\/b> Der er opst\u00e5et et problem i stand-up m\u00f8derne \u2013 mange opgaver udf\u00f8res parallelt. Nogle gange er opgaverne svagt relaterede, og der er ikke klarhed over, hvem der laver hvad. Men meningen fra en anden teammedlem er meget vigtig. Det er en ekstra information, som kan \u00e6ndre tilgangen til opgavel\u00f8sningen. Selvf\u00f8lgelig har du normalt en partner, men r\u00e5d og vejledning er aldrig overfl\u00f8dige. <\/p>\n<p>For at forbedre denne situation anvendte vi teknikken \"Skiftende facilitator for stand-up\". Nu roterer de efter en bestemt liste, og det har en effekt. N\u00e5r din tur kommer, er du n\u00f8dt til at dykke ned i og forst\u00e5, hvad der sker for at kunne lede scrum-m\u00f8det ordentligt. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/622973a654ecd3e27a7a366596814ffc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>3. Intern demo.<\/b> Hj\u00e6lp til at l\u00f8se opgaver gennem parprogrammering, visualisering af opgavedr\u00e6et og st\u00f8tte p\u00e5 scrum-m\u00f8derne om morgenen er godt, men ikke perfekt. I et par er man kun begr\u00e6nset af sine egne viden. Opgavedr\u00e6et hj\u00e6lper med at f\u00e5 et overblik over, hvem der laver hvad. Men facilitator og kolleger ved morgenm\u00f8det vil ikke dykke dybt ned i dine problemer. De kan helt sikkert overse noget. <\/p>\n<p>L\u00f8sningen blev fundet i at fremvise de udf\u00f8rte arbejder for hinanden og efterf\u00f8lgende diskutere dem. Vi m\u00f8des en gang om ugen i en time og viser detaljerne i l\u00f8sningerne p\u00e5 opgaverne, vi har arbejdet p\u00e5 i den forgangne uge. <\/p>\n<p>Under demonstrationen skal man afsl\u00f8re detaljerne om opgaven og s\u00f8rge for at vise, hvordan det fungerer. <\/p>\n<p><b class=\"spoiler_title\">Opl\u00e6gget kan f\u00f8lges p\u00e5 en tjekliste.<\/b>1. Indf\u00f8r konteksten. Hvor kom opgaven fra, og hvorfor var den overhovedet n\u00f8dvendig?<\/p>\n<p>2. Hvordan blev opgaven l\u00f8st tidligere? For eksempel, var der behov for masser af musklik eller var det helt umuligt at g\u00f8re noget?<\/p>\n<p>3. Hvordan forbedrer vi dette? For eksempel: \"Se, nu er der et lille script, her er readme.'<\/p>\n<p>4. Vis, hvordan det fungerer. Det er \u00f8nskeligt at gennemf\u00f8re et brugerflow direkte. Jeg \u00f8nsker X, g\u00f8r Y, ser Z (eller Z). For eksempel, jeg deployer NGINX, tjekker url, f\u00e5r 200 OK. Hvis handlingen tager lang tid, forbered det p\u00e5 forh\u00e5nd, s\u00e5 det kan vises. Ideelt set b\u00f8r der ikke v\u00e6re nedbrud en time f\u00f8r demoen, is\u00e6r hvis systemet er skr\u00f8beligt.<\/p>\n<p>5. Forklar, hvor godt problemet er l\u00f8st, hvilke udfordringer der stadig er, hvad der ikke er f\u00e6rdigt, og hvilke forbedringer der kan komme senere. For eksempel, nu er det CLI, senere vil der v\u00e6re fuld automatik i CI.<\/p>\n<p>Det er \u00f8nskeligt, at hver taler holder sig inden for 5-10 minutter. Hvis dit indl\u00e6g er v\u00e6sentligt og vil tage l\u00e6ngere tid, skal det aftales p\u00e5 forh\u00e5nd i kanalen sre-takeover.<\/p>\n<p>Efter den fysiske del f\u00f8lger der en diskussion i tr\u00e5den. Her kommer den n\u00f8dvendige feedback p\u00e5 vores opgaver frem. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/77da888d24b52c7eea7e65d2400e152c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nI slutningen gennemf\u00f8res en afstemning for at afd\u00e6kke hvor nyttig begivenheden har v\u00e6ret. Dette er allerede feedback om indl\u00e6ggets essens og opgavens vigtighed.<\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan man l\u00f8ser problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/7642cd87050171cc4a6bf278329dd283.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Lange konklusioner og hvad der s\u00e5 skal ske<\/h2>\n<p>\nDet kan synes, at tonen i artiklen er noget pessimistisk. S\u00e5dan er det ikke. De to lavpraktiske niveauer for at f\u00e5 feedback, nemlig tests og parprogrammering, fungerer. Ikke helt som i traditionel udvikling, men der er en positiv effekt. <\/p>\n<p>Tests, i deres nuv\u00e6rende form, giver kun delvis d\u00e6kning af koden. Mange konfigurationsfunktioner forbliver utestet. Deres indflydelse p\u00e5 det direkte arbejde ved kodning er lav. Men der er en effekt fra integrationstests, og det er dem, der g\u00f8r det muligt at udf\u00f8re refactoring uden frygt. Det er en stor pr\u00e6station. Desuden forsvinder problemet med at flytte fokus til udvikling i h\u00f8jniveau sprog (hos os python, go). Der er mange checks p\u00e5 'kl\u00e6bemidlet', og der er ikke behov for det, kun netop den generelle integration.<\/p>\n<p>Pararbejde afh\u00e6nger mere af de konkrete mennesker. Der er faktoren af opgaven og vores bl\u00f8de f\u00e6rdigheder. Nogle gange fungerer det rigtig godt, andre gange mindre godt. Der er bestemt en fordel ved det. Det er klart, at selv med utilstr\u00e6kkelig overholdelse af reglerne for pararbejde, p\u00e5virker selve faktum af f\u00e6lles opgavel\u00f8sning positivt kvaliteten af resultatet. Personligt er det lettere og mere behageligt for mig at arbejde i par.<\/p>\n<p>Mere h\u00f8jniveaus m\u00e5der at p\u00e5virke OS p\u00e5 - planl\u00e6gning og arbejde med opgaver giver bestemt resultater: kvalitetsvidensudveksling og forbedring af udviklingskvaliteten. <\/p>\n<h4>Korte opsummeringer i \u00e9n s\u00e6tning <\/h4>\n<p><\/p>\n<ul>\n<li>XP-praksisser fungerer i IaC, men med lavere effektivitet.<\/li>\n<li>Styrk det, der fungerer.<\/li>\n<li>Opfind dine egne kompensationsmekanismer og praksisser.<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/470620\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0432\u0435\u0440\u043d\u0443\u043b\u0441\u044f, \u0447\u0442\u043e\u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044b \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0432\u044b\u0440\u0432\u0430\u0442\u044c\u0441\u044f \u0438\u0437 \u0431\u0435\u0437\u0434\u043d\u044b \u043e\u0442\u0447\u0430\u044f\u043d\u0438\u044f \u0438 \u0432\u044b\u0440\u0443\u043b\u0438\u0442\u044c \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044e \u0432 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0440\u0443\u0441\u043b\u043e. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abInfrastructure as code: \u043f\u0435\u0440\u0432\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e\u00bb \u044f \u0434\u0435\u043b\u0438\u043b\u0441\u044f \u0441\u0432\u043e\u0438\u043c \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0435\u043d\u0438\u0435\u043c \u043e\u0442 \u044d\u0442\u043e\u0439 \u0441\u0444\u0435\u0440\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29066,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Infrastructure as Code: hvordan man overvinder problemer ved hj\u00e6lp af XP | ProHoster","description":"Hej, Habr! Tidligere klagede jeg over livet i Infrastructure as Code-paradigmet og foreslog ikke noget til at l\u00f8se situationen.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:42+00:00","article:modified_time":"2019-10-31T19:25:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38747","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:16:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:04:30","updated":"2026-01-23 23:16:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38747"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29066"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}