Ni har gjort er research och som vi alla vet är DevOps ett fantastiskt system - särskilt när det används tillsammans med en produktionsmetodik som Agile. Vissa skulle till och med kallad det en himmelsk kombination som erbjuder ett brett spektrum av fördelar, vilket resulterar i snabbare, mer tillförlitliga releaser och förbättrad övergripande effektivitet. Det är okej, vi behöver inte sälja in allt det där igen, men trots alla fördelar som ni med all rätt förväntar er, står vi nu inför en mycket viktig fråga: Hur kommer vi igång?
Gör-det-själv eller färdig-att-använda?
En snabbgenomgång av de tekniker och tjänster som finns därute visar att det finns två huvudsakliga typer avlösningar att tillgå när man letar efter en plats att börja på:
- Gör-det-själv (GDS)
- Färdig-att-använda
Även om det är mycket frestande att välja det snabba alternativet med ett färdigt paket, kommer ni också snabbt hitta begränsningar när det gäller alternativ och anpassning. Å andra sidan kan GDS-lösningar hamna på den motsatta änden av spektrumet och vara skrämmande med alla valmöjligheter och den mängd uppgifter som följer med att underhålla en pipeline som är specialdesignad för just era behov och processer.
AWS DevOps verktyg
De DevOps-verktyg som tillhandahålls av Amazon Web Services (AWS) faller helt inom GDS-domänen och även om det, som sagt, erbjuder full kontroll över er pipeline kan det också vara en överväldigande uppgift att komma igång med det för företag som är nya inom DevOps eller har ett mindre team.
I ett försök att göra processen så smidig som möjligt stöder och möjliggör Amazon Web Services DevOps genom att tillhandahålla verktyg för att bygga, lagra och distribuera applikationer. Oavsett om du redan använder AWS eller inte kan du skapa och integrera en DevOps-pipeline och automatisera stegen i dina processer för att publicera programvara på ett sätt som passar dig bäst.
Att välja den här typen av lösning innebär oundvikligen att det kommer att krävas mer tid och experimenterande för att komma igång med DevOps-pipelinen. Därför kan det vara frestande att välja en färdig pipeline som ni kan börja använda direkt. Det som kan vara tveksamt med denna lösningen är att ägandet, underhållet och anpassningen av pipelinen inte ligger i era händer.
När ni har använt DevOps ett tag är det troligt att ni blir bortskämda med de fördelar er pipeline ger er och ni vill ha flexibiliteten att optimera ytterligare, automatisera och utveckla erat system. Detta är något som en standardlösning inte kan erbjuda. Så vilken lösning ska ni välja - och vilka fördelar är ni villiga att kompromissa på?
Sanningen är att ni ska inte behöva kompromissa - och ni behöver inte heller göra det.
Använd vår CI/CD CloudFormation-mall.
Det första steget är att använda vår CI/CD CloudFormation-mall för att komma igång med AWS DevOps-verktygen och snabbt få en fungerande pipeline. Vi har gjort grovjobbet, tänkt igenom, skapat en mall och testat den I flera projekt.
Mallen erbjuder en anpassningsbar konfiguration som gör lösningen mer lik ett standardalternativ, samtidigt som den behåller all anpassningsbarhet och kontroll som ett gör-det-själv-alternativ ger.
Koppla bort dina beroendeförhållanden.
Det finns utan tvekan många olika och lämpliga tillvägagångssätt för att utforma er DevOps-pipeline. Vår erfarenhet visar dock att ett av de bästa sätten att göra det på är att dynamiskt skapa nya pipelines för varje ny funktionsgren. På så sätt skapas pipelines med hjälp av CloudFormation och distribueras för varje funktion.
Huvudargumentet för detta är frikoppling av beroenden mellan både utvecklare och funktioner, vilket gör att varje ny funktion som utvecklas självständigt kan gå igenom pipeline-stegen och nå produktion.
DevOps pipeline-sekvens
Så här ser vår pipeline ut. Låt oss plocka isär den och förklara sekvensen den går igenom.
Steg 1: Leveransbara användarberättelser
Utvecklingsprocessen inleds med att backloggen fördelas på mindre leveransbara användarberättelser. Utvecklarna förgrenar skapar sedan en ny gren från huvudgrenen (Master Branch) för den aktuella användarberättelsen.
Steg 2: Pull Request (Begäran om utdrag)
När det är dags att skicka in den kodade användarberättelsen skapar utvecklarna ett Pull Request som fångas upp av ett CloudWatch Event och startar en Lambda-funktion som skapar en CodePipeline genom en CloudFormation-mall. Pipelinen börjar automatiskt testa och bygga applikationen och meddelar sedan utvecklarna när det har slutförts eller misslyckats.
Steg 3: Code Review (Kodgranskning)
Nästa steg i pipelinen är Manual Approve, som kallas Code Review och godkänns när Pull Request-statusen är godkänd. Baserat på byggandet i steg 1 genom Serverless-ramverket skapas sedan en unik utvecklingsmiljö för applikationen som är identisk med produktionsmiljön.
Steg 4: QA och testning
QA meddelas sedan via SNS att en ny User Story är redo för testning tillsammans med granskningsadressen och en länk till steget för manuellt godkännande i CodePipeline. Om QA avvisar användarberättelsen lägger utvecklaren in en ny ändring på samma gren och pipelinen startar om från början. Om den godkänns utlöses en Lambda-funktion som slår samman grenen med huvudgrenen och raderar de resurser som tillhandahållits av pipelinen tillsammans med CodePipeline-stackens resurser.
Steg 5: Driftsättning
Produktionspipelinen aktiveras när det finns en ny ändring på huvudgrenen. Den består av en "test och bygg"-fas och en "driftsättnings"-fas. Utvecklare och QA meddelas via SNS när det sker en ny driftsättning eller när något går fel i produktionspipelinen.
Och det är allt!
Kom igång med att komma igång.
Nu när vi har gått igenom varför detta är ett av de bästa alternativen för erat företag och hur ni kan få det bästa av båda världar, är det dags att agera och sätta igång. Kontakta oss för att konfigurera er pipeline och sparka igång er DevOps-resa.