allan ebdrup bloghoved ny

VIDEO: Sådan kan du deploy'e til produktion ti gange om dagen

Continuous Delivery warstories - er titlen på et foredag jeg holdt til et gratis #AgilityLab meetup for over 80 mennesker.

Illustration: Privatfoto

Foredraget er den ærlige fortælling om hvordan vi, med to teams og ti udviklere på debitoor, gik fra 14-dages sprints til at deploy'e til produktion ti gange om dagen eller mere.

Videoen ovenover er den korte variant af foredraget. De kommende måneder rejser jeg rundt i landet og giver den lange variant.

Overvejer du også at prøve kræfter med Continuous Release? Kommentarer og spørgsmål modtages med kyshånd.

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Grubbe

Vi bruger Git, hosted på Github. Vi kører Ruby on Rails, og vi er 9 udviklere i alt. Det fungerer ret smooth, det var dog lidt af uhyggeligt at tænde for continous integration første gang og lade en ekstern service deploye, men nu er det bare hverdag.

  • 1
  • 0
Henrik Hansen

Vi er stille og roligt ved at migrere vores forskellige applikationer over på Shippable, og i den forbindelse er vores håb, at vi kan ende med at lave automatisk deployment som nødvendigt (i skrivende stund deployer vi kun vores develop branches automatisk til de respektive test-miljøer). Vi bruger Git på Bitbucket, Python og er samlet set 7 udviklere.

Jeg synes det er en angstprovokerende ting at slå til; min umiddelbare frygt er, at vi mangler en test-case, og man derfor ender med noget som er automatisk deployed, som det tager lidt tid før man finder ud af ikke virker. Og hvis man alligevel skal sidde og holde ting i hånden, og være opmærksom ved hvert deployment, så kan man jo ligeså godt lave manuel deployment.

That being said, vi ses i Aalborg 21. maj til den lange version!

  • 1
  • 0
Allan Ebdrup Blogger

Ja, det er nok frygten for at man giver slip på noget kontrol der spiller ind. For os har det været et non-issue. Om noget er kvaliteten blevet bedre i det vi leverer. Det skyldes langt hen ad vejen den måde vi bruger git på, med branches, som jeg taler om i foredraget.

Spændende med forskellige tools. Det er en imponerende feature-liste Shippable har, og prisen på $12/år med 5 samtidige builds lyder helt utrolig, kan det virkelig løbe rund for dem?

Vi kunne godt være interesseret i en erstatning for vores on-premise TeamCity installation. Og Single Sign on med GitHub lyder som det helt rigtige for os. Kan man styre det så kun nogle i github org'en kan køre visse builds osv? Hvordan virker Shippable generelt for jer?

That being said, vi ses i Aalborg 21. maj til den lange version!


Det gør vi!

  • 0
  • 0
Henrik Hansen

Shippables priser er helt absurd lave. Vi kører faktisk på gratisplanen, fordi vi ikke har brug for samtidige builds som tingene står nu (det er dog allerede begyndt at irritere os en lille smule, når vi sidder forskellige personer og gerne vil have forskellige projekter igennem hurtigst muligt). Dedikerede hosts er i beta og derfor gratis, men jeg tænker at de vil tjene pengene hjem på dem, når de går ud af beta. Et eksempel hvor en dedikeret host er super nice, er hvis du vil lave et Git push fra et successfuld build, over SSH. Du vil sikkert ikke åbne SSH for hele verden, men Shippable har kun kendte IP ranges hvis du bruger dedikerede hosts (det påstår de i hvert fald). Men det er en minor ting i det store hele.

Jeg er ikke helt klar over det; min tanke er, at hvis nogen har adgang til et repo i din org, så vil push til repoet triggere en build. Du kan selvfølgelig begrænse hvilke branches der må triggere et build, og teknisk set kan du også lave begrænsninger på brugere i dit projekts shippable configuration - men den kan alle med adgang til projektet jo ændre. På den anden side -- hvis man kører continous delivery på sit projekt, så stoler man vel også på alle som har push rettigheder til sit repo?

Vi er glade for Shippable. Vi kom fra Atlassian Bamboo, som bare var for tungt at danse med for os. Projektkonfigurationen er meget lig med Travis. Det giver dig "bare minimum", og alt du ønsker at gøre med dit build, skal du selv sørge for ved successfuldt build i form af on_success kommandoer i din konfiguration.
Det eneste jeg mangler i Bamboo er faktisk ordentlig visning af coverage rapporter, men det er lidt en anden snak :)

  • 1
  • 0
Kasper Grubbe

Vi er glade for Shippable.

Det er ret interessant, jeg testede dem ud for et halvt år siden, opgraderede til deres betalingsversion, og så at de havde problemer med tests der var "stuck" og aldrig kom videre. Jeg måtte skrive til dem for at få dem til at markere det som værende frosne, og et par timer efter var de stuck igen.

Det lyder som om det er blevet bedre.

  • 0
  • 0
Jari Wiklund

Efter at have læst kommentarerne i denne tråd, prøvede jeg også shippable og jeg må sige at det har overrasket positivt. Nemt at sætte op ikke mindst.
Jeg er endnu ikke blevet træt af at se hele den automatik der går igang, når jeg pusher fra mit IDE, til shippable detekterer det og sætter et nyt build igang og slutter af med at deploy'e til amazon elastic beanstalk, hvor dashboardet til environment'et så begynder at opdatere for at slutte af med Health=green.
Det er nok bare fascinerende når store maskinerier kører og man kan se alle tandhjulene dreje :-)
Jeg var til meetup'et hos economic og blev meget inspireret til hvordan vi skulle bygge vores afdelings deployment-pipeline op. Første vellykkede skridt er hermed taget.

  • 1
  • 0
Allan Ebdrup Blogger

Er det korrekt forstået, at branching modellen som anvendes, ligner gitflow?


Det minder om. Men vores flow er meget meget simplere. Git Flow har en række svagheder. Jeg ville i stedet tage et kig på på praqmas version af git flow:
http://www.praqma.com/resources/papers/git-flow

Det er en version af denne vi kører. Vi kører bare en meget simplere variant da vi ikke har maintenance branches. Og master er produktion for os, så hver merge til master er en release.

  • 0
  • 0
Log ind eller Opret konto for at kommentere