Varför DevOps? Del 2

Nu när vi har fått en inblick i vad DevOps är för nåt så är det dags att börja titta på ett verktyg som kan hjälpa dig på vägen under din DevOps resa.

Har ni missat att läsa om vad DevOps är för nåt så kan ni läsa mitt tidigare inlägg: Varför DevOps? – Asurgent

Det finns många verktyg man kan välja mellan och jag skulle vilja påstå att det inte finns något som är rätt eller fel, det beror mer på vad som passar organisationen, oftast har man redan tekniker man föredrar som man har jobbat med under en längre tid och som man är bekväm med. Allt från PowerShell, Bash, Cygwin, Homebrew, Python, Ruby, till GitHub, GitLab, GitOps, Argo .NET, Java, JavaScript, React och så vidare.

Idag ska vi titta på molnverktyget Azure DevOps som innan hette VSTS (Visual Studio Team Services) och som har haft flera namn på vägen sedan starten 2005 så som Visual studio 2005 Team System, Visual Studio Team System 2008, Team Foundation Server 2010, Team Foundation Service Preview, och Visual Studio Online.

En stor missuppfattning med namnet idag är tyvärr att många tänker sig att detta verktyg är specifik för Azure plattformen men det är långt ifrån sanningen. Man brukar säga att Azure DevOps är en cross function platform dvs du kan bygga och testa i node.js, Python, Java, PHP, Ruby, C/C++, C# .NET/Core, Android och i OS appar. Du kan kompilera din kod mot Linux, macOS och Windows. Du kan releasea mot Azure, AWS, GCP och mot dina on-prem miljöer. Om man lagrar sin källkod i GitHub så kan man integrera det med Azure DevOps om man vill.

Som ni märker ovan så är verktyget inte alls specifikt bara för Azure???? Med Azure DevOps  sköts och hanteras allt i molnet. Det finns möjlighet att kunna använda verktyget on-prem och då heter det istället Azure DevOps Server men helst vill man använda sig utav Azure DevOps och inte Azure DevOps Server lösningen då t.ex. nya funktioner där bara introduceras var tredje månad och det kan finnas en del down time för att göra uppgraderingar. Du behöver då också tänka på backups, uppgraderingar och underhåll och att skala upp servern om det skulle behövas. Precis som med allt annat på infrastruktur nivå på marken.

I molnet sker uppdateringarna var tredje vecka och man behöver inte göra något för att få tillgång till dem och det är heller inget underhåll man behöver tänka på. Evergreen helt enkelt.

Microsoft verkar också ha förstått att det finns många företag som har lagt ner mycket tid och pengar på att ta fram ett arbetssätt för sina DevOps tekniker och därav kan man integrera Azure DevOps med många av dessa verktyg så som Puppet, Chef, Terraform, Jenkins, Ansible, Whitesource, Octopus deploy, Docker och Kubernetes. Dessa är bara några av de tekniker som kan integrera med.

Azure DevOps innehåller 5 olika fristående tjänster som man kan använda sig utav, från att lagra sin källkod till att releasea till olika miljöer på ett automatisk sätt.

Du kan använda dessa tjänster beroende på vad för behov din organisation har. Det som används flitigast och är hjärtat utav verktyget skulle jag säga är Azure Repo (Repository) där man centraliserar sin källkod och Azure pipelines där man paketerar (kompilera) sin kod och på ett automatiskt sätt releasear mot sina miljöer.

Jobbar din organisation efter ett agilt arbetssätt eller med SCRUM kan ni använda er utav Azure Dashboard, om ni inte gör det så rekommenderar jag att man börjar titta på det då det kommer underlätta kommunikationen mellan teamet som jobbar i samma projekt.

Har ni redan eller vill sätta upp manuella och automatiska tester (enhetstester och testning utav användargränssnitt) så kan man använda sig utav Azure Test plans där man kan t.ex. dokumentera steg för steg hur man ska utföra dom manuella tester man har.

Sist men inte minst har du Azure Artifacts där du kan ha dela med dig av säkra paket (säker nedladdning) som t.ex. Nuget som kan delas inom teamet och din Azure pipeline för att sänka tiden på din byggprocess.

Här kommer en kort introduktion till dom fem olika tjänsterna, det blir lite mer tekniskt beroende på läsarens bakgrund men jag hoppas ni kan få ut något av det.

Azure Dashboard
Detta är nåt man kallar för ALM (Application Life cycle Management). Tjänsten kan användas för att planera sina projekt på ett agilt arbetssätt eller med SCURM, man kan spåra sina work items (t.ex. Feature, Bugs, User story och Task), backlogs och  skapa Kanban tavlor. Man skulle kunna säga att denna tjänst funkar som ett JIRA verktyg.

Work item
Är kopplat till ditt projekt och indikerar vad för sorts arbete som behöver göras och det finns möjlighet att sätta ett slutdatum för när jobbet ska vara klart. Du kan också tilldela dessa work items till någon i teamet som är bäst lämpad att jobba med uppgiften.

Backlogs
Är en lista utav work items som måste utföras för produkten eller tjänsten för att ge affärsvärde.

Azure Pipelines
Gör att du kan bygga (kompilera din kod), testa och releasea mot dina miljöer på ett automatisk sätt. Det är en kombination utav CI (Continuous Integration) och CD (Continuous Delivery) arbetsmetodik.

Continuous integration (CI)
Är en utvecklingsmetod där det krävs att utvecklarna integrerar med sin kod i en gemensam källkodshanterare (repository) flera gånger per dag. Varje gång man skickar in sin kod så verifieras det automatisk med ett bygge vilket tillåter teamet att upptäcka problem tidigt i processen då man b.la. har kopplat på enhetstester till sin process.

Continuous delivery (CD)
Tar koden du har validerat som ett paket från byggprocessen och frisläpper det mot olika miljöer så som utvecklings- och produktionsmiljön. Utvecklarna kan spåra sina releases och se den gick igenom eller om det misslyckades och på detta sätt kan dom begränsa och hitta det specifika problem som uppstår i dom olika paketen man använder sig av.

Det vanliga sättet man konfigurera sina pipelines på är med YAML (Yet Another Markup Language)  vilket Microsoft rekommenderar att man använder sig av, om man redan jobbar med IaC (Infrastructure as Code) metodiken så faller det sig naturligt att använda YAML, vilket betyder att du bygger din pipeline med kod.

Det är också möjligt att koppla den källkod du har i GitHub mot din Azure pipeline om du skulle vilja göra det.

Azure pipeline Agents
För att kunna bygga och release kod via Azure pipeline så används Azure pipeline agent  för utföra själva jobbet för att bl.a. kompilera koden och release din kod i din miljö. En agent är i grunden en VM som skapas när du startar din pipeline och tas bort så fort den är klar. Därav tar det en stund innan ditt bygge kommer igång (från några sekunder till några minuter kan det ta, går dock snabbare om man har en Microsoft-hosted agent.

Microsoft låter dig använd en fri agent (1 800 minuter per månad) dels för att man ska ha möjlighet att labba runt och se om detta är något som organisationen kan använda sig utav och det räcker för mindre projekt som man jobbar med, men för större organisationer så rekommenderad dom att man använder sig utav en privat agent som man kan köpa som kallas för Microsoft-hosted agent.

Då agenten i grunden är ett VM så finns det möjlighet att kunna skapa sin egen privata agent som kalls för self-hosted agent och koppla den mot sin Azure DevOps projekt men då behöver man tänka på att underhålla VM:en b.la att patcha VM när det kommer uppgraderingar och därav finns det anledning att använda sig utav en Microsoft-hosted agent.

Azure Repo (Repository)
Är där man kan lagra sin källkod och där det är möjligt att skapa, hantera och lagra olika versioner av källkoden. Det versionskontroll-system som används för att kunna hantera sin kod är Git. Man får också möjligheten att lagra obegränsade privata källkoder (repositories). Man kan använda sig utav något som heter Branch policy och Pull Requests som hjälper dig att skydda och se till att inte fel kod matas in till din källkod.

Repository & Branch
Repository är hela ditt projekt (kataloger/mappar och filer) som du kan klona (ladda ner) till din lokala dator. En branch är en version utav din repository, man skulle kunna säga att det är en oberoende kopia av ditt arbete som lagras lokalt.

En repository kan innehålla flera branches vilket betyder att det kan finnas olika versioner av din repository. Anledningen till att skapa versioner utav din kod är så att ditt team kan arbeta med olika aspekter av projektet samtidigt dvs varje arbete har sin egen branch.

Branch policy
Är ett bra sätt att skydda dina brancher. Du kan begränsa teammedlemmar från att arbeta eller skapa specifika brancher, ha namngivningsriktlinjer för brancher, automatiskt lägga till teammedlemmar för att granska varje kodändring. Ha byggvalidering vilket betyder att bygget måste lyckas för att kunna slutföra sin pull request.

Pull Requests
Låter ditt team granska koden och ger möjligheten att ge feedback om ändringar innan den slås ihop till huvudbranchen eller någon annan branch. Granskaren kan gå igenom de föreslagna ändringarna, lämna kommentarer och välja att godkänna eller avvisa koden. Det är ett bra sätt att få mer kontroll över dina brancher.

Azure Test plans
Stöder avancerade testhanteringslösningar för kundfeedback, UAT (User acceptance testing), automatisering och manuell testningar.
Det ger dig en komplett verktygslåda för att utföra tester från början till slut, planera manuell och utforskande testning så att man kan bekräfta att programvaran fungerar bra.

Azure Artifacts
Här kan du skapa, hosta och också dela med dig dina paket till ditt team så som Mave, NPM, pyhtom, Nuget och m.m. På detta sätt kan du också säkra att dom paket som du delar med dig av inte kommer ha något som kan skada ditt team när det laddas ner till deras dator så som ett virus.

Extension Marketplace
Används för att kunna utnyttja 3-parts lösningar så som Puppet, Chef, Octopus deploy osv.

Nu när vi har gått igenom dom olika tjänsterna så hoppas jag att jag lyckades fånga ert intresse för att undersöka om Azure DevOps är något för er organisation!

Jag tänker i nästa blogginlägg beskriva hur man enkelt skulle kunna komma igång med en .NET core applikation i Azure DevOps. Fram till dess önskar jag er lycka till i ert Azure DevOps resa och tveka inte att höra av er om ni behöver hjälp på vägen!