8 centrale udfordringer i vedtagelse af DevOps: Del 2 - løsninger

I del 1 (her) af denne to-dages blogserie så jeg på de 8 vigtigste udfordringer, jeg ser organisationer, når de vedtager DevOps. Lad os nu se på nogle løsninger.

Forandring er hårdest i begyndelsen, mest klodset i midten og det bedste i slutningen. - Robin S. Sharma

1. Oprettelse af kulturfunktion i henhold til DevOps-principper

DevOps-ledere og forandringsagenter bliver nødt til at finde måder til kontinuerligt at uddanne teams og mennesker i organisationen om, hvordan DevOps-kultur ser ud, og hvorfor det fremskynder strømmen af ​​værdi. Her er nogle ting, jeg har prøvet, der har fungeret:

Læring og praksisfællesskaber

DevOps-personalet kan arrangere intern træning eller introduktionspræsentationer til DevOps-adoption og give eksponering for DevOps-kultur. På denne måde kan de fremme og mødes ansigt til ansigt med alle i organisationen. Ansigt til ansigt samarbejde foretrækkes frem for at bruge e-mail eller videokonferencer, da mennesker opbygger tillid hurtigere på denne måde, så det anbefales at gennemføre et roadshow, hvis hold er spredt, med det formål at møde alle mindst en for at oprette relationer.

DevOps Knowledgebase & FAQ

DevOps-team kan oprette en vidensbase eller ofte stillede spørgsmål (FAQ) og dele med alle mennesker i organisationen, og derfor ved alle, hvor de kan få information til at forholde sig til DevOps, hvor de har brug for det. Synligheden og let adgang til de oplysninger, der motiverer dem til at søge og læse dem selv og endda bidrage. Denne form for information kan opbevares i samarbejdsplatforme som Atlassian Confluence eller Microsoft Teams.

Anvendelse af Westrum Organisation Kulturpraksis

Vi kan bruge Westrum Organisations kulturpraksis til at fremstille en generativ kultur, der kultiverer datastrøm og tillid ved at se på de seks dele af Westrums model for hierarkisk kultur, koncentrere os om den praksis, der findes i den generative kultur;

Her kan du oprette en generativ kultur;

2. Adresser modstand mod ændring

Ledere må forvente, at folk vil modstå forandring. I henhold til DevOpsologist, Philippa Hale, i sin artikel om kortlægningsværktøjer for interessenter og hun diskuterede, hvordan vi kan adressere bestemte gruppers menneskers humør og følelser mod ændringer, kan vi anvende forskellige engagementstrategier for at henvende sig til DevOps-initiativer. Der er 6 “adfærdsprofil”, og hvordan vi kan samarbejde med dem som nedenfor;

unengaged

tilskuere

kynikere

Kritikere

entusiaster

Fortalere (Champions / Eksperter)

For at opsummere baseret på ovenstående kan vi se alle involverede tilgange involveret kommunikation og holde os informeret om DevOps-vedtagelsen. Vi er nødt til at arbejde tæt sammen med alle grupper og være synlige for dem og give hjælp, når de har brug for en.

3.Bringe klarhed til DevOps Vision

Introduktion af DevOps CALMS-rammen kan hjælpe med at definere DevOps køreplan og mål. CALMS er en konceptuel ramme for integration af udviklings- og drifts (DevOps) teams, funktioner og systemer i en organisation.

DevOps-ledere skal udvikle en klar køreplan for DevOps-udviklingen med klare forbedringsfaser. De skal dele det og gøre det synligt for alle i organisationen;

4. Oprettelse af tværgående team-samarbejde

Udviklings- og it-driftsteams skal lære at samarbejde. Dette kan betyde oprettelse af tværfunktionelle teams, herunder både dev og ops, men dette fungerer ikke i mange organisationer. Det er ofte for dramatisk en organisatorisk ændring, eller der er simpelthen ikke nok mennesker til at gå rundt. Opsætninger af traditionel teknologiafdeling har også en tendens til at inkludere dyb emneekspertise inden for it-operationer omkring sikkerhed og netværk, så det er vanskeligt at se, hvordan man deler disse typer mennesker på tværs af udviklings- eller produktteam.

Hvad hjælper der ved, at både udviklings- og it-driftsteam møder regelmæssigt? Hvis udviklingsteam gennemfører daglige skrummer som en del af deres agile praksis, kan det at hjælpe med at fjerne hindringer invitere IT-operationer til at deltage. At invitere dem til sprintplanlægning kan sikre, at de ikke-funktionelle krav tages i betragtning i sprinten, og dermed strømline værdiforsyningsprocessen.

Cross-team kommunikationsværktøjer som Slack eller Microsoft Teams hjælper virkelig her ved at gøre det muligt for samarbejde at være kontinuerligt. Chat-gruppen eller -kanalen “Alert / Notification” skal også styres korrekt, så problemer kan ledes til det rigtige team og eskaleres hurtigt ved hjælp af den rigtige handling, der skal udføres for at løse problemet / bug.

Her er nogle samarbejdsværktøjer, som du muligvis bruger og begynder at samarbejde i din organisation;

5.Standardiserende miljøer

Et miljø er en samling af ressourcer eller målrettede steder, som du vil konvertere fra kode til et rigtigt produkt via pipeline. Miljøet kan omfatte virtuelle maskiner (VM), databaseservere, tredjeparts tjenester osv. Nedenfor er et eksempel på miljøstadier med dets brug, bruger / persona og en ansvarlig for at opretholde miljøet;

Fordelene ved at have et veldefineret miljø inkluderer følgende;

  1. Deployment record / history - Alle detaljer om pipeline-kørsel registreres i CI / CD-værktøjer for dets ressourcer.
  2. Sporbarhed - Det giver en mulighed for at spore, om en kodeændring (engagement) eller funktion / bug-fix (arbejdsemner) nåede et miljø.
  3. Tilladelse / kontrol - et sikkert miljø ved at specificere, hvilken bruger der er tilladt, og hvilket målmiljø der skal implementeres.

Levering af automatiseringsmiljø er en vigtig faktor for succes i en kontinuerlig leveringsproces. Kan Dev-teamet anmode om et nyt miljø ad-hoc, og leveres dit miljø on-demand, når applikationen implementeres? Applikationsmiljøet kan opdeles i tre hovedområder:

1. Infrastruktur

2. Konfiguration

3. afhængigheder

Infrastruktur er det sted, hvor applikationen eller tjenesten bliver implementeret, og applikationen kører specifikke konfigurationsbehov. Det inkluderer også, hvordan afhængigheder skal integreres med applikationen. Fra i dag kan infrastruktur leveres med script eller de kalder det "Infrastructure as Code" eller kort sagt IaC. IaC gøres mere tilgængelig i dag gennem en omfattende vifte af værktøjer, der er tilgængelige til at automatisere hele miljøfremstillingsprocessen.

Konfiguration er det næste mest konsekvente aspekt af applikationsmiljøet. Konfiguration dikterer både, hvordan applikationen komporteres i en given infrastruktur, og hvordan infrastrukturen komporteres i anerkendelse til den underliggende applikation.

Afhængigheder er alle de forskellige moduler eller systemer, en applikation afhænger af, fra biblioteker til tjenester eller andre applikationer.

Fordelen ved at bruge automatiske miljøforsyninger som følger;

  • Reduceret kompleksitet ved at lade DevOps-hold arbejde på et højere abstraktionsniveau.
  • Øget stabilitet ved at gøre det muligt for applikationer at reagere dynamisk på deres implementering.
  • Øget fleksibilitet ved at afkoble konfigurationsstyring fra en applikations specifikke hostingmiljø.

Vi har mange tilgængelige værktøjer på markedet, uanset om det er open source eller virksomhed, som vi kan bruge til at automatisere levering til alle de 3 områder, der er nævnt ovenfor, f.eks.

6.Standardisering af DevOps værktøjskæde og levering af det som selvbetjening

Når DevOps-adoptionsmål og -processer er defineret, kan vi bestemme det værktøjssæt, der kræves for at opfylde processerne. Sørg for, at udviklings- og it-driftsteamene samarbejder om at beslutte de værktøjer, der er egnede til organisationen. Med ethvert nyt værktøj, der introduceres, skal eksisterende arbejdstagere trænes. Det er også vigtigt at sikre, at værktøjerne opfylder sikkerhedskrav og er godt integreret med eksisterende ressourcer og tjenester.

** Benyt blot et par værktøjskæder, der er tilgængelige på markedet for ovenstående afsnit.

7. Accelerating Release Management

Når vi har defineret vores miljø korrekt, er DevOps-lederne nødt til at oprette en ordentlig frigørelsespipeline, som når vi har brug for en auto-trigger til implementering, når behovet for godkendelse af præinstallation og når QA / teststadiet skal placeres. Nedenstående billede har vist en grundlæggende frigørelsesrørledning med kombineret automatisk og manuel implementering;

Når du har en ordentlig frigørelsespipeline, automatisering af bygning, integration, test, & levering og andre processer, reducerer det de menneskelige aktiviteter i hver udgivelse såvel som mængden af ​​styring og koordinering, der kræves.

Da udviklingsacceleration er blevet en konkurrencefordel, har DevOps-teamet forsøgt at muliggøre kontinuerlig integration og kontinuerlig distribution (CI / CD). CI / CD hjælper udviklere og IT-operationer med at overvinde et kæmpe besvær med softwareudviklings- og testprocessen. I årenes løb er softwareudvikling migreret fra virksomhedsniveau, hvor der er brede ressourcer, til mindre udviklingshold, som kæmper for at holde trit med efterspørgslen fra milliarder af smartphones og andre mobile forbrugerenheder og platforme. Nedenfor er et eksempel på CI / CD-rørledning med en tilgængelig kombination af værktøjskæde;

I vores tilfælde vælger vi at bruge en kombination af værktøjer, da det ser ud til at give den bedste løsning til vores komplicerede behov. De fleste teams, der udvikler virksomhedsprodukter, ville drage fordel af en sådan grundlæggende tilgang. Vores værktøjskæbeback består af,

  1. Atlassian JIRA - et værktøj til teamsamarbejde fra produktets efterslæb, Sprintplanlægning og rapport om frigivelse og hvor godt Agile-teamet klarer sig i hver sprint.
  2. Github - et distribueret versionskontrolsystem (DVCS), hvor udvikleren kommunikerer med hinanden og samarbejder om at forbedre produktfunktionskoden og synligheden for ændringer og kodeversioner. Eventuelle ændringer skal gennemgås af andre udviklere eller Code Reviewer, der gjorde koden mere ren og mindre fejl / fejl.
  3. Azure DevOps - det er et værktøj, vi bruger til at orkestreere vores CI / CD-rørledning, og det er også stedet, hvor mere samarbejde mellem DevOps Engineer, Developer, Release Manager og QA-team. Det er også stedet, hvor integrationer sker for at kunne levere et produkt med god kvalitet, hvorfor vi har sikkerhedsanalyse og QA-test, før vi implementerer til produktionsmiljøet.
  4. Datadog - Det er et overvågningsværktøj, som du med Datadog kan overvåge dine servere, dine skyer, dine målinger, dine apps, dit team sammen. Det er som et one-stop for alle slags skærme til dit miljø og produkter.

En effektiv CI / CD-rørledning kan markant forbedre tiden til marked og benytte stabiliteten og kvaliteten af ​​softwaren, der distribueres.

8. Automatisering af test

DevOps fremmer automatisering, og det er mål at udføre så mange automatiseringer som muligt af alle daglige opgaver, der ikke kræver menneskelige indgreb. Tilføj QA-eksperter til DevOps-teamets sammensætning vil hjælpe teamet med at beslutte den bedste tilgang, eller testværktøjer kan automatiseres. Automationsværktøjer fungerer generelt, når det kommer til testning for applikations- eller systemfejl, men QA-test udfører et meget bedre stykke arbejde med at teste for brugervenlighed og frigøringsberedskab.

Integrering af automatiseret kontinuerlig test til din CI / CD-rørledning kræver et applikationsprøvningsredskab, der er let at integrere med den build, testautomation og CI / CD-redskaber, du allerede bruger, og som har omfattende web API-support. Fordelen ved at bruge automatisk kontinuerlig test som følger:

Stabilitet. Det hjælper dig med at anvende kvalitet og sikkerhedskrav mere konsekvent. Hvis du registrerer en manuel sikkerhedstest og derefter automatiserer den, bliver det et sikkerhedskrav, du kan håndhæve på hver build.

Hastighed. Med automatiseret kontinuerlig test drevet af skalerbare værktøjer kan udviklere finde og finjustere problemer i ægte tid i hele SDLC. Dette fremskynder applikationsudvikling og undgår fejl, der er fælles for manuel test.

Vægt. For at skalere manuel test kræver du flere manuelle testere. For at skalere automatiseret test har du kun brug for flere apps og builds for at teste.

Konklusion

DevOps Adoption er en rejse, der skal starte med en analyse af organisationens arkitektur og mål. Løsning af disse almindelige udfordringer i DevOps Adoption vil få transformation til at blive meget glattere. Over en periode vil hvert team eller person i organisationen vænne sig til DevOps-ændringerne og tilpasse sig de kontinuerlige læringsprocesser. Når udviklings-, drifts- og ledelsesteamene lærer at samarbejde, hjælper de automatisk hinanden og samarbejder tæt for at arkivere DevOps Adoption-mål.