SkyeTec sine topp DevOps råd! Del 1 av 2.

[vc_row type=»vc_default»][vc_column][dt_fancy_title title=»SkyeTec sine topp DevOps råd! (Del 1 av 2)» title_align=»left» title_size=»h1″ title_color=»custom» separator_style=»disabled» custom_title_color=»#0c0c0c»][ultimate_heading main_heading=»Er DevOps nytt for deg?» alignment=»left»][/ultimate_heading][vc_column_text]

SkyeTec er et konsulenthus som rendyrker skyteknologi, og som et resultat av dette har vi fått mye erfaring med å jobbe i agile prosjekter med kultur for DevOps.
Vi er en sammensatt gjeng seniorkonsulenter med bakgrunn både fra IT-Infrastruktur, IT-Drift og utvikling.

Som en konsekvens av de agile prosjektene og DevOps har IT-infrastruktur og -drift konsulentene våre jobbet seg mot utvikling og tilegnet seg denne kompetansen, hvor utviklerne våre i “motsatt ende” har jobbet seg mot infrastruktur og drift og tilegnet seg denne kompetansen.

Med dette som utgangspunkt har vi utarbeidet en punktliste med gode DevOps råd og betraktninger hvor Azure er i fokus.

Vi har kategorisert punktene innenfor områdene:

Prosesser

Organisering

Teknologi

Informasjon

Disse kan du bruke når du vurderer å starte opp et “DevOps løp”.

I første del av 2 skriver vi om «Prosesser».

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][ultimate_heading main_heading=»Prosesser» alignment=»left»][/ultimate_heading][ultimate_heading main_heading=»Kanban» heading_tag=»h3″ alignment=»left»][/ultimate_heading][vc_column_text]

Kanban et meget godt styringsverktøy som vi foretrekker å benytte med våre kunder når man begynner med DevOps. Når teamet blir mer “varm-i-trøya», kan man eventuelt vurdere å gå over til å bruke rammeverk som feks “SCRUM”.
Vi har følgende tips når når man skal begynne med Kanban:

Verktøy – Vi har god erfaring med å bruke Azure DevOps Board og Trello.

Oppsett – Vi har god erfaring med følgende layout (kolonner) i boardet:

Backlog – For Oppgaver/tasker som er definert men ikke tildelt til noen.
Tips! Backlog ut i fra behov som dukker opp. Ikke vær redd for å “fylle på”. Det er bedre å definere og notere en oppgave og heller slette den, om det viser seg at den ikke er aktuell å gjennomføre.

ToDo – oppgaver flyttes hit når de er tildelt en person.

WIP – Står for Work in Progress. Oppgaven flyttes inn når en person begynner å jobbe med den. Dette innebærer design arbeid, koding og grunnleggende testing av koden (sandbox test) og oppdatering av CI/CD pipeline

Dev – oppgaven flyttes dit når den (fortrinnsvis den nye koden som er utviklet) er klar for å bli testet ut i utvikler miljøet/plattformen. Oppgaven defineres fortsatt som WIP.

Prod – Når den nye koden som er utviklet er testet og godkjent på utviklerplattformen, flyttes den over til produksjonsmiljøet, og oppgaven blir flyttet tilsvarende i Kanban boardet. Oppgaven defineres fortsatt som WIP.
Tips! Ha en godt definert test strategi i prod (ja vi tester i prod!). Vi bruker ofte en Blue/green tilnærming, hvor vi bygger opp rutiner, overvåking og infrastruktur som bygger oppunder denne tilnærmingen.

Finish – Når oppgaven er definert som ferdig, flyttes den tilsvarende over til Finish. Den respektive personen har da en mindre oppgave i Kanban boardet, og kan da selv velge en ny oppgave som er definert i backlog.

[/vc_column_text][ultimate_heading main_heading=»Pull system» heading_tag=»h4″ alignment=»left»][/ultimate_heading][vc_column_text]

Et viktig prinsipp med bruk av Kanban som beskrevet over er bruken av “Pull System”. Som i praksis betyr at personer velger oppgaver selv og “drar” disse gjennom boardet. Altså at ingen står å “pusher” oppgaver på medarbeidere.

Dette er med å sørge for at det ikke blir for mange jobber i WIP, og vår erfaring er også at dette systemet er med å skape trygghet for medarbeiderne som jobber med DevOps. De velger selv hvilke oppgaver de er komfortable med å ta fra backlog, velger selv tempoet for å dra oppgavene igjennom boardet og hvor mange de har kapasitet til å ha i WIP.

Når medarbeiderne blir komfortable med arbeidsformen, ser vi at de blir “tøffere og tøffere” på å velge komplekse oppgaver, og at gjennomføringshastigheten på oppgavene blir raskere og raskere. Vår erfaring viser at Pull systemet faktisk er med på å øke gjennomføringshastigheten på oppgaver, hvor kvaliteten på arbeidet blir høyre.

[/vc_column_text][ultimate_heading main_heading=»StandUps» heading_tag=»h4″ alignment=»left»][/ultimate_heading][vc_column_text]

En viktig del av den agile arbeidsformen, er å ha daglige Kanban standupmøter. Møtet er med på å opprettholde hastigheten på jobbingen, og avdekker eventuelle problemer, såkalte “show stoppere”.
Tips til disse møtene er:

Bruk en mentor

Møtet bør vare maks 15-30 min.

Gå bare igjennom WIP oppgavene.

Gå igjennom WIP kolonnene fra venstre til høyre.

Bare eierne av oppgavene gir status på oppgaven. Hvor eieren av oppgaven fokuser på hva som er gjort siden forrige møte, og om det er noen kjente “blokkere” på oppgaven. Dette er med på å opprettholde møtehastigheten.

[/vc_column_text][ultimate_heading main_heading=»Retrospect» heading_tag=»h4″ alignment=»left»][/ultimate_heading][vc_column_text]

Det som er vanlig å gjennomføre i SCRUM på slutten av en “Sprint Cycle”. Dette er et punkt vi gjerne gjennomfører uansett hvilke rammeverk vi benytter i et DevOps løp.

Vi ser at det kan lønner seg å ha et møte når man har gjennomført en større mengder oppgaver for å reflektere over disse i fellesskap. Vi deler et “retro” møte inn i følgende delpunkter:

Pros – Hva gikk bra?

Cons – Hva gikk ikke så bra?

Develop – Hva kan vi forbedre?

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][ultimate_heading main_heading=»MVP» heading_tag=»h4″ alignment=»left»][/ultimate_heading][vc_column_text]

Står for “minimum viable product”.

Vår erfaring er at denne tilnærmingen kan og bør(?) benyttes for “alt”. Dette gjelder produktutvikling, men også utarbeidelse av design, dokumentasjon, utarbeidelse av governance modeller osv.

Mangel på informasjon i startfasen av en jobb/prosjekt, begrenset med kompetanse og erfaringer, samt hvor mye uforutsett kan skje på veien, gjør at “den gamle” måten å jobbe på hvor alt skulle planlegges, lages og utarbeides i forkant, i de fleste tilfeller bare fører til mye unødvendig arbeid som aldri gir noe særlig nytte for seg

[/vc_column_text][ultimate_heading main_heading=»Governance» heading_tag=»h3″ alignment=»left»][/ultimate_heading][vc_column_text]

Er lik styring og retningslinjer. Bruk MVP prinsippet som beskrevet over, men ha likevel en klar styrings-strategi fra start. Vi anbefaler å opprette en “governance” funksjon/virtuell team, hvor man bør utarbeide og ha følgende governance disipliner på plass fra start:

Sikkerhet – Tenk moderne sikkerhet fra dag en, og begynn med å utarbeide rettingslinjer for identitet og tilgangskontroll, samt retningslinjer for “asset” og informasjons klassifisering med sikring.

Kostnad – Lag rettingslinjer for å få kontroll på kostnader. Bruk av sky kan bli en dyrekjøpt erfaring hvis man ikke har en god strategi på kostnader. Begynn f.eks. med en slags standardisering på hva slags teknologi som skal benyttes, størrelse, og Typer/“SKU”.
Ex på føring er: All “Runtime” skal kontaineriseres og kunne produksjonsettes på K8s hvor AKS er standarden, hvor følgende SKU benyttes “Standard_D4s_v3”. AKS “clustere” skal støtte “autoscaling” på node og pod/HPA nivå. Max 10 noder per AKS cluster.

Ressurskonsistens – Begynn med å definere rettingslinjer på språk (ARM template vs Terraform), Navn standarder, Brancingsstrategier, og arkitektur/design prinsipper som skal benyttes.

[/vc_column_text][ultimate_heading main_heading=»CI/CD» heading_tag=»h3″ alignment=»left»][/ultimate_heading][vc_column_text]

Utarbeid en god CI/CD strategi.

Prinsippet vi bruker for CI/CD er som følgende:

[/vc_column_text][dt_fancy_image image_id=»3340″ width=»900″ image_decoration=»shadow» shadow_h_length=»2px» shadow_v_length=»2px» shadow_blur_radius=»2px» shadow_spread=»2px» shadow_color=»rgba(0,0,0,0.6)» image_scale_animation_on_hover=»quick_scale»][vc_column_text]

Andre viktige prinsipper vi har med når vi lager en CI/CD strategi er:

En god “variable” strategi på koden vi produserer – Koden må kunne gjenbrukes på tvers av miljøene, uten menneskelig interaksjon.

“Branching”, “trigger”, “gates” og “pull request” strategier.

Failback strategi(er) – If shit happens, and it does!

God tilgangsstyrings strategi – CI/CD verktøyet man benytter vil ha mye rettigheter inn i de forskjellige miljøene.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][ultimate_heading main_heading=»Ønsker du mer informasjon?» heading_tag=»h3″ alignment=»left» margin_design_tab_text=»»][/ultimate_heading][vc_column_text]

Neste del: SkyeTec sine topp DevOps råd! (Del 2)

Les gjerne: DevSecOps – Hva er det?

Dersom du har behov for en DevOps prat ta kontakt med oss.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

#Azure #AKS #K8s #DevOps #DevOpsSec #Kanban #SCRUM #StandUp #Board #CICD #Terraform #ARM #Pipeline

[/vc_column_text][/vc_column][/vc_row]

SkyeTec er et konsulenthus som rendyrker skyteknologi, og som et resultat av dette har vi fått mye erfaring med å jobbe i agile prosjekter med kultur for DevOps. Vi er en sammensatt gjeng seniorkonsulenter med bakgrunn både fra IT-Infrastruktur, IT-Drift og utvikling.

Som en konsekvens av de agile prosjektene og DevOps har IT-infrastruktur og -drift konsulentene våre jobbet seg mot utvikling og tilegnet seg denne kompetansen, hvor utviklerne våre i “motsatt ende” har jobbet seg mot infrastruktur og drift og tilegnet seg denne kompetansen.

Med dette som utgangspunkt har vi utarbeidet en punktliste med gode DevOps råd og betraktninger hvor Azure er i fokus.

Vi har kategorisert punktene innenfor områdene:

Prosesser

Organisering

Teknologi

Informasjon

Disse kan du bruke når du vurderer å starte opp et “DevOps løp”.

I første del av 2 skriver vi om «Prosesser».

Kanban et meget godt styringsverktøy som vi foretrekker å benytte med våre kunder når man begynner med DevOps. Når teamet blir mer “varm-i-trøya», kan man eventuelt vurdere å gå over til å bruke rammeverk som feks “SCRUM”. Vi har følgende tips når når man skal begynne med Kanban:

Verktøy – Vi har god erfaring med å bruke Azure DevOps Board og Trello.

Oppsett – Vi har god erfaring med følgende layout (kolonner) i boardet:

Backlog – For Oppgaver/tasker som er definert men ikke tildelt til noen. Tips! Backlog ut i fra behov som dukker opp. Ikke vær redd for å “fylle på”. Det er bedre å definere og notere en oppgave og heller slette den, om det viser seg at den ikke er aktuell å gjennomføre.

ToDo – oppgaver flyttes hit når de er tildelt en person.

WIP – Står for Work in Progress. Oppgaven flyttes inn når en person begynner å jobbe med den. Dette innebærer design arbeid, koding og grunnleggende testing av koden (sandbox test) og oppdatering av CI/CD pipeline

Dev – oppgaven flyttes dit når den (fortrinnsvis den nye koden som er utviklet) er klar for å bli testet ut i utvikler miljøet/plattformen. Oppgaven defineres fortsatt som WIP.

Finish – Når oppgaven er definert som ferdig, flyttes den tilsvarende over til Finish. Den respektive personen har da en mindre oppgave i Kanban boardet, og kan da selv velge en ny oppgave som er definert i backlog.

Et viktig prinsipp med bruk av Kanban som beskrevet over er bruken av “Pull System”. Som i praksis betyr at personer velger oppgaver selv og “drar” disse gjennom boardet. Altså at ingen står å “pusher” oppgaver på medarbeidere.

En viktig del av den agile arbeidsformen, er å ha daglige Kanban standupmøter. Møtet er med på å opprettholde hastigheten på jobbingen, og avdekker eventuelle problemer, såkalte “show stoppere”. Tips til disse møtene er:

Bruk en mentor

Møtet bør vare maks 15-30 min.

Gå bare igjennom WIP oppgavene.

Gå igjennom WIP kolonnene fra venstre til høyre.

Bare eierne av oppgavene gir status på oppgaven. Hvor eieren av oppgaven fokuser på hva som er gjort siden forrige møte, og om det er noen kjente “blokkere” på oppgaven. Dette er med på å opprettholde møtehastigheten.

Det som er vanlig å gjennomføre i SCRUM på slutten av en “Sprint Cycle”. Dette er et punkt vi gjerne gjennomfører uansett hvilke rammeverk vi benytter i et DevOps løp.

Vi ser at det kan lønner seg å ha et møte når man har gjennomført en større mengder oppgaver for å reflektere over disse i fellesskap. Vi deler et “retro” møte inn i følgende delpunkter:

Pros – Hva gikk bra?

Cons – Hva gikk ikke så bra?

Develop – Hva kan vi forbedre?

Står for “minimum viable product”.

Vår erfaring er at denne tilnærmingen kan og bør(?) benyttes for “alt”. Dette gjelder produktutvikling, men også utarbeidelse av design, dokumentasjon, utarbeidelse av governance modeller osv.

Er lik styring og retningslinjer. Bruk MVP prinsippet som beskrevet over, men ha likevel en klar styrings-strategi fra start. Vi anbefaler å opprette en “governance” funksjon/virtuell team, hvor man bør utarbeide og ha følgende governance disipliner på plass fra start:

Sikkerhet – Tenk moderne sikkerhet fra dag en, og begynn med å utarbeide rettingslinjer for identitet og tilgangskontroll, samt retningslinjer for “asset” og informasjons klassifisering med sikring.

Ressurskonsistens – Begynn med å definere rettingslinjer på språk (ARM template vs Terraform), Navn standarder, Brancingsstrategier, og arkitektur/design prinsipper som skal benyttes.

Utarbeid en god CI/CD strategi.

Prinsippet vi bruker for CI/CD er som følgende:

Andre viktige prinsipper vi har med når vi lager en CI/CD strategi er:

En god “variable” strategi på koden vi produserer – Koden må kunne gjenbrukes på tvers av miljøene, uten menneskelig interaksjon.

“Branching”, “trigger”, “gates” og “pull request” strategier.

Failback strategi(er) – If shit happens, and it does!

God tilgangsstyrings strategi – CI/CD verktøyet man benytter vil ha mye rettigheter inn i de forskjellige miljøene.

Neste del: SkyeTec sine topp DevOps råd! (Del 2)

Les gjerne: DevSecOps – Hva er det?

Dersom du har behov for en DevOps prat ta kontakt med oss.

SkyeTec er et konsulenthus som rendyrker skyteknologi, og som et resultat av dette har vi fått mye erfaring med å jobbe i agile prosjekter med kultur for DevOps.
Vi er en sammensatt gjeng seniorkonsulenter med bakgrunn både fra IT-Infrastruktur, IT-Drift og utvikling.

Kanban et meget godt styringsverktøy som vi foretrekker å benytte med våre kunder når man begynner med DevOps. Når teamet blir mer “varm-i-trøya», kan man eventuelt vurdere å gå over til å bruke rammeverk som feks “SCRUM”.
Vi har følgende tips når når man skal begynne med Kanban:

Backlog – For Oppgaver/tasker som er definert men ikke tildelt til noen.
Tips! Backlog ut i fra behov som dukker opp. Ikke vær redd for å “fylle på”. Det er bedre å definere og notere en oppgave og heller slette den, om det viser seg at den ikke er aktuell å gjennomføre.

En viktig del av den agile arbeidsformen, er å ha daglige Kanban standupmøter. Møtet er med på å opprettholde hastigheten på jobbingen, og avdekker eventuelle problemer, såkalte “show stoppere”.
Tips til disse møtene er: