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

[vc_row type=»vc_default»][vc_column][dt_fancy_title title=»SkyeTec sine topp DevOps råd! (Del 2 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”.

Dette er en fortsettelse på: SkyeTec sine topp DevOps råd! (Del 1 av 2)

I andre del skriver vi om «Organisering, «Teknologi» og «Informasjon».

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

Dedikerte Team

Når man bestemmer seg for å starte opp et «DevOps løp» viser vår erfaring at et dedikert team eller «kjerneteam» for et slikt løpet er et must. Dette betyr at ressursene som jobber for dette teamet er dedikert til nettopp dette teamet. Altså, de jobber ikke for noen andre team eller tilsvarende. Vi ser at dette må til for at alle medarbeidere skal klare å holde fokus.
Men vi ser at det er ok at enkeltpersoner skiftes ut med andre personer under et «DevOps løp».
Faktisk mener vi dette noen ganger er lurt, for å få nye impulser i teamet. Men vi anbefaler å beholde et fast “kjerneteam” som sørger for at kunnskapen som er opparbeidet forblir i teamet.

Definer behovet for Funksjoner – og ikke ressurser/personer.

Med funksjoner så mener vi kompetanseområder vi må dekke opp i teamet for å få til å gjennomføre et «DevOps løp». Velg deretter medarbeidere som kan dekke en eller flere funksjoner. I mange tilfeller ser vi nemlig at en medarbeider kan dekke opp en eller flere funksjoner. Dette er helt ok.
Vår erfaring viser at det å definere opp funksjoner gir den fordelen at det blir enklere å finne eventuelle flaskehalser i teamet, og deretter enklere å “fylle på” med medarbeidere med tilsvarende kompetanseområde for å løse opp i “proppen”.
Eksempel på funksjon kan være; DevSecOps, SRE, Infra-koder, App-koder, Arkitekt eller Governance.
^^{Kan feks deles videre opp i Full stack, front end eller back end.}

Utilization

Unngå “rovdrift” av medarbeidere i teamet. Hold alltid igjen noe av en medarbeiders kapasitet til andre formål i prosjektet. Jobber man ikke for dette så er vår erfaring at det kan føre til “utbrente” medarbeidere. Dette er ingen tjent med.
Hvis vi opplever at en medarbeider har en for høy utnyttelsesgrad, så prøver vi alltid å hente inn en person til med tilsvarende funksjon, altså kompetanseområde.

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

Bruk sky-teknologi

Vår erfaring viser seg at å standardisere på bruk av sky-teknologi er en nødvendighet for å lykkes med et «DevOps løp». Hvorfor?

Skalering – Skyen skalerer “uendelig”. De fleste sky-tjenestene støtter også dynamisk eller automatisk skalering etter behov, hvor det er mulig å skalere ressursene uten å tenke på re-installasjon eller nede-tid.

Automatisering – Skyen er bygget 100% for IaC og støtter meget høy grad av automatisering. Dette betyr at man enkelt kan automatisere hele livssyklusen til en tjenestene/system/applikasjon som kjører i skyen. Automatiseringen skjer gjerne i form av CI/CD verktøy, overvåkning/telemetri med triggere, og deklarativ kode i form av «Infrastructure as Code«. Enkelt forklart betyr deklarativ tilstandsbaserte tekstfiler som feks yaml eller json, som beskriver ønsket tilstand til infrastruktur ressursen/tjenesten som brukes.

Sikkerhet – Skyleverandørene investerer enorme summer på å sikre sky-plattformen. Bare Microsoft bruker ca 1 milliard dollar årlig på sikkerhet, hvor brorparten blir investert i Azure. Av denne årsaken vil tjenester og applikasjoner som leverer i skyen typisk være sikrere enn tilsvarende “on-prem” implementasjoner.

Kreativitet – Kostnadene med å teste ut en ide eller hypoteser med bruk av sky-teknologi kan gjøres raskt, enkelt og billig. Nødvendig infrastruktur for å teste ut en ide kan etableres på minutter og enkelt fjernes igjen etter bruk uten større maskinvare eller programvare investeringer. Dette fremmer innovasjon og kreativitet i teamet og for virksomheten!

IaC – er et must å bruke!

Bruken av IaC gir blant annet følgende fordeler:

Infrastrukturen og applikasjonskoden henger tettere i sammen.

Repeterbar, trygg og ikke minst en rask implementering av infrastrukturen på tvers av plattformer og miljøer.

En god oversikt over når, hvorfor og hvem, som gjorde endringer i infrastrukturen “out of the box”.

Enkelt å kunne etterleve navn konvensjoner og standarder.

Azure DevOps

Er et meget kraftig verktøy vi anbefaler å bruke når man begynner et «DevOps løp». Azure DevOps kan fint brukes både av infrastruktur- og applikasjonskodere, og vil understøtte deres CI/CD behov. I tillegg god erfaring med å bruke:

Azure DevOps “Repos” til versjonering og oppbevaring av kode.

Azure DevOps “Boards” til Kanban (..eller SCRUM), som gjør at man for eksempel enkelt kan integrere både branch og pull-request strategier med oppgavene man definerer.

Azure DevOps for å måle effektiviteten i teamet, med bruk av de innebyggede analytic verktøyene.

Azure Devops “Pipelines” for pre- og postrelease testing. Her kan man også spesifisere hvordan og hvor man vil at koden skal utrulles og bygges.

Github

Når Microsoft kjøpte GitHub i 2018, slo de også i sammen Azure DevOps og GitHub teamene til et team. Det vil derfor være naturlig å anta at Azure DevOps og GitHub på sikt blir til et og samme produkt. Mye skjer med GitHub, og vi ser allerede nå at ny nyttig funksjonalitet basert på Azure DevOps, blir tilgjengeliggjort.
GitHub kan derfor være et godt alternativ til Azure DevOps for nye organisasjoner eller team som vurderer å begynne med et DevOps løp. Vi ser spesielt med introduksjonen av GitHub Actions (ekvivalenten til Azure DevOps Pipeline), at GitHub begynner å bli et kraftig CI/CD verktøy som vil dekke de fleste “nye” DevOps Team sine CI/CD behov.

Confluence

Er et meget godt verktøy for å dele informasjon og samhandling. Vi anbefaler å bruke denne tjenesten som teamets primære informasjonsplattform.

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

Lag Arkitektur og design prinsipper

I en tidlig fase bli enige om hvilke design og arkitekturprinsipper som skal benyttes av teamet. Dette for å sikre at utviklingen foregår i trygge rammer, men også for å sikre at kvaliteten og utviklingshastigheten på systemet ivaretas allerede i en tidlig fase. Benytt en MVP tilnærming, hvor man legger på mer informasjon når forståelsen for hva man utvikler blir bedre. Tips er å involvere governance teamet når man utarbeider prinsippene. Prinsippene bør være kortfattelig, enkle å lese og lette å forstå. Bruk gjerne punktlister hvor prinsippene inneholder både påstand og begrunnelsen for påstanden.

Eksempler på prinsipper:

Alle ressurser og artefakter som benyttes skal bruke Azure, da dette anses som mest kost effektivt.

Alle nye Azure ressurser og artefakter utvikles og implementeres med IaC, for å ivareta CI/CD prinsippene og for å sikre kvalitet, agilitet og gjenbrukbarhet.

Satte «Branch» navn konvensjoner skal benyttes på alt av IaC og CI/CD for å sikre agilitet og gjenbrukbarhet.

Blue/Green tilnærming skal benyttes på alle koder som benyttes i CI/CD pipen for å sikre fleksibilitet og gjenbrukbarhet.

All design skal bruke Microsoft «Well architected» og design praksis som finnes i Microsoft sin offisielle Docs inkludert CAF.

Samhandling

Vi har god erfaring med å bruke PM funksjon i Microsoft Teams eller Slack som den primære kommunikasjonskanalen (spesielt nå pga Covid-19). Større utfordringer løser vi med “spontane møter” (JIT møter) med bruk av samme verktøy. Bruk av Teams og Slack gir fordeler som blant annet å kunne jobbe sammen over større fysiske avstander og sporbarhet på kommunikasjon.

Lav dokumentasjonsgrad

Med dette mener vi “just in time, just enough” dokumentering. Dette gjelder spesielt alt som har å gjøre med arkitektur og design, hvor vi bare gjør arkitektur og design ved behov og i det momentet vi trenger det. Ellers så har vi god erfaring med å benytte Readme.md som en del av dokumentasjon når vi koder. Eventuelt supplementer med “Wiki” informasjon i f.eks. Confluence.

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

Les gjerne: «DevOpsSec»: 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 #Kanban #SCRUM #Confluence #DevOps #DevOps #Github #GithubActions #CAF #CICD #Json #Yaml #Terraform #ARM #Pipeline #IaC

[/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”.

Dette er en fortsettelse på: SkyeTec sine topp DevOps råd! (Del 1 av 2)

I andre del skriver vi om «Organisering, «Teknologi» og «Informasjon».

Dedikerte Team

Definer behovet for Funksjoner – og ikke ressurser/personer.

Utilization

Bruk sky-teknologi

Vår erfaring viser seg at å standardisere på bruk av sky-teknologi er en nødvendighet for å lykkes med et «DevOps løp». Hvorfor?

Skalering – Skyen skalerer “uendelig”. De fleste sky-tjenestene støtter også dynamisk eller automatisk skalering etter behov, hvor det er mulig å skalere ressursene uten å tenke på re-installasjon eller nede-tid.

IaC – er et must å bruke!

Bruken av IaC gir blant annet følgende fordeler:

Azure DevOps

Er et meget kraftig verktøy vi anbefaler å bruke når man begynner et «DevOps løp». Azure DevOps kan fint brukes både av infrastruktur- og applikasjonskodere, og vil understøtte deres CI/CD behov. I tillegg god erfaring med å bruke:

Azure DevOps “Repos” til versjonering og oppbevaring av kode.

Azure DevOps “Boards” til Kanban (..eller SCRUM), som gjør at man for eksempel enkelt kan integrere både branch og pull-request strategier med oppgavene man definerer.

Azure DevOps for å måle effektiviteten i teamet, med bruk av de innebyggede analytic verktøyene.

Azure Devops “Pipelines” for pre- og postrelease testing. Her kan man også spesifisere hvordan og hvor man vil at koden skal utrulles og bygges.

Github

Confluence

Er et meget godt verktøy for å dele informasjon og samhandling. Vi anbefaler å bruke denne tjenesten som teamets primære informasjonsplattform.

Lag Arkitektur og design prinsipper

Eksempler på prinsipper:

Alle ressurser og artefakter som benyttes skal bruke Azure, da dette anses som mest kost effektivt.

Alle nye Azure ressurser og artefakter utvikles og implementeres med IaC, for å ivareta CI/CD prinsippene og for å sikre kvalitet, agilitet og gjenbrukbarhet.

Satte «Branch» navn konvensjoner skal benyttes på alt av IaC og CI/CD for å sikre agilitet og gjenbrukbarhet.

Blue/Green tilnærming skal benyttes på alle koder som benyttes i CI/CD pipen for å sikre fleksibilitet og gjenbrukbarhet.

All design skal bruke Microsoft «Well architected» og design praksis som finnes i Microsoft sin offisielle Docs inkludert CAF.

Samhandling

Lav dokumentasjonsgrad

Les gjerne: «DevOpsSec»: 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.

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”.

Dette er en fortsettelse på: SkyeTec sine topp DevOps råd! (Del 1 av 2)

I andre del skriver vi om «Organisering, «Teknologi» og «Informasjon».

Dedikerte Team

Definer behovet for Funksjoner – og ikke ressurser/personer.

Utilization

Bruk sky-teknologi

Vår erfaring viser seg at å standardisere på bruk av sky-teknologi er en nødvendighet for å lykkes med et «DevOps løp». Hvorfor?

Skalering – Skyen skalerer “uendelig”. De fleste sky-tjenestene støtter også dynamisk eller automatisk skalering etter behov, hvor det er mulig å skalere ressursene uten å tenke på re-installasjon eller nede-tid.

IaC – er et must å bruke!

Bruken av IaC gir blant annet følgende fordeler:

Azure DevOps

Er et meget kraftig verktøy vi anbefaler å bruke når man begynner et «DevOps løp». Azure DevOps kan fint brukes både av infrastruktur- og applikasjonskodere, og vil understøtte deres CI/CD behov. I tillegg god erfaring med å bruke:

Azure DevOps “Repos” til versjonering og oppbevaring av kode.

Azure DevOps “Boards” til Kanban (..eller SCRUM), som gjør at man for eksempel enkelt kan integrere både branch og pull-request strategier med oppgavene man definerer.

Azure DevOps for å måle effektiviteten i teamet, med bruk av de innebyggede analytic verktøyene.

Azure Devops “Pipelines” for pre- og postrelease testing. Her kan man også spesifisere hvordan og hvor man vil at koden skal utrulles og bygges.

Github

Confluence

Er et meget godt verktøy for å dele informasjon og samhandling. Vi anbefaler å bruke denne tjenesten som teamets primære informasjonsplattform.

Lag Arkitektur og design prinsipper

Eksempler på prinsipper:

Alle ressurser og artefakter som benyttes skal bruke Azure, da dette anses som mest kost effektivt.

Alle nye Azure ressurser og artefakter utvikles og implementeres med IaC, for å ivareta CI/CD prinsippene og for å sikre kvalitet, agilitet og gjenbrukbarhet.

Satte «Branch» navn konvensjoner skal benyttes på alt av IaC og CI/CD for å sikre agilitet og gjenbrukbarhet.

Blue/Green tilnærming skal benyttes på alle koder som benyttes i CI/CD pipen for å sikre fleksibilitet og gjenbrukbarhet.

All design skal bruke Microsoft «Well architected» og design praksis som finnes i Microsoft sin offisielle Docs inkludert CAF.

Samhandling

Lav dokumentasjonsgrad

Les gjerne: «DevOpsSec»: 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.