top of page

Uge 20

  • Forfatters billede: jonathanlipinskira
    jonathanlipinskira
  • 27. maj
  • 2 min læsning

Opdateret: 28. maj

Mandag: 

Mål for dagen 

Påbegynde at læse og forstå teori om DevOps, for at finde ud af, hvor devops i teorien ligger i forhold til procesmodel, fokusområder, systemudviklingsmetoder mm. 

 

Aktiviteter for dagen 

I dag havde jeg fokus på DevOps’ filosofi. Min praktiske erfaring med DevOps fra de sidste par måneder har helt klart hjulpet mht. at i dag kunne sætte mig ind i DevOps’ filosofier, da det er en smule mere håndgribeligt, når man selv har siddet med det. Den første kilde jeg fandt gennemgår devops’ tilgang til softwareudvkling. Kilden postulerer at devops’ er en forlængelse af agil procesmodel. Man kan sige, at DevOps’ filosofi ligger i dens tilgang til udvikling og udrulning, det handler altså om at automatisere og optimere samarbejdet mellem developers og operations departments i et firma. Man fokuserer på at udrulle og levere til kunder så ofte og hurtigt som muligt, på samme tid med at man automatiserer sig til at kunne opretholde et vis software niveau. 

Youtube videoen gennemgår et kernekoncept i devops, nemlig “three ways”, som jeg vil læse videre om i morgen. 

https://www.youtube.com/watch?v=FxHDfHxFe7I&ab_channel=SalesforceDevelopers (DevOps philosophy principles, Youtube søgning) 

 

 

 

 

Refleksioner for dagen 

Det var lærerigt at læse om teori bag DevOps, som jeg ikke har gjort siden starten af semesteret, da jeg hurtigt valgte at have en praktisk tilgang til DevOps, hvor fokus lå på værktøjer. Mine erfaringer de sidste par måneder hjælper helt klart til at kunne forstå teorien bedre i dag. 

 


Onsdag: 

Mål for dagen 

Undersøge “three-ways” i DevOps 

Aktiviteter for dagen 

Artiklen beskriver “three ways” som en måde at beskrive værdierne og filosofien i Devops. 

 

  1. First way 

  2. Hele ens arbejdskæde skal hænge sammen, altså developer team skal være i tæt samarbejde på lige fod med operations team, eller hvilke andre teams man nu har. Man tænker altså på udvikling som en helhed istedet for siloer af forskellige ‘departments’ 

  3. Second way 

  4. Er et feedback loop, hvor vi opdager og retter fejl så tidlig som mulight. Vi udvikler altså ikke fra A til B, men fra A til B til A osv. 

  5. Three way 

  6. Det tredje punkt omdrejer at skabe kultur for at kunne eksperimentere og fejle, da det er der, at devops skinner. DevOps er kun godt netop når der fejles, da man hurtigt kan rette op på fejlen og forbedre systemet. 

 

 

 

Refleksioner for dagen 

Jeg har lavet et lille produkt som viser DevOps’ filosofier med mine egne ord: 



ree

Torsdag: 

Mål for dagen 

Undersøge de forskellige faser i DevOps 


Aktiviteter for dagen 

I dag havde jeg fokus på faserne i DevOps og hvordan de opdeles (continuous integration og continuous delivery). Jeg fandt ud af, faserne danner en cirkulær proces, hvor man hele tiden forbedrer sig og bruger feedback fra drift og brugere til næste iteration. 

Jeg gennemgik de otte klassiske faser: Plan, Code, Build, Test, Release, Deploy, Operate, Monitor – og det gav meget mere mening, fordi jeg kunne relatere dem til de tools og flows, jeg selv har arbejdet med fx. Azure Pipelines, hvor jeg brugte YAML filer til at lave en pipeline som bygger, tester, containerizer & deployer kode. Så det er netop det, jeg har kæmpet lidt med i min egen pipeline, så det gav god mening at læse teorien bag det. 

Derudover begyndte jeg at se på hvordan faserne også er en måde at samarbejde på tværs af teams, så alle hænger sammen fra planlægning til monitorering. 

https://www.browserstack.com/guide/devops-lifecycle (“DevOps phase flow”, Google søgning) 

 

 

Refleksioner for dagen 

Jeg udarbejdede et lille artefakt til at visualisere faserne 



ree

Fredag: 

Mål for dagen Undersøge de forskellige procedurer, regler og dokumentation i DevOps 


Aktiviteter for dagen I dag dykkede jeg ned i, hvilke procedurer og regler man typisk arbejder med i DevOps, og hvordan dokumentation egentlig spiller ind i det hele. Jeg fandt ud af, at DevOps ikke handler om faste regler, men mere om principper og best practices, som teams tilpasser efter behov. Dog er der stadig nogle gennemgående ting som f.eks. automatisering, små og hyppige releases, og samarbejde på tværs af roller. 

Det var også interessant at læse om “Infrastructure as Code” – altså hvordan man behandler opsætning af servere og infrastruktur som kode, så det kan versionstyres og gentages præcist hver gang. Det stødte jeg også selv på, da jeg udviklede min YAML pipeline. Man benytter disse procedurer for at opfange fejl så hurtigt som muligt, og for at sikre sig, at det er computerne som opfanger de fleste fejl. Altså CI/CD. 

I forhold til dokumentation, så er det ikke noget, som DevOps specificerer noget specielt i. Det meste dokumentation ligger i form at alle de små inkrementer man udfører.  

 

https://spacelift.io/blog/devops-best-practices (“DevOps rules and procedures”, Google søgning) 

https://www.atlassian.com/devops/what-is-devops (“DevOps rules and principles”, Google søgning) 


Refleksioner for dagen 

Artefakter jeg udviklede for dagen: 



ree

 
 
 

Seneste blogindlæg

Se alle

Kommentarer


© 2035 by Train of Thoughts. Powered and secured by Wix

bottom of page