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.
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.
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Er det korrekt forstået, at branching modellen som anvendes, ligner gitflow?https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflowog forlægget:https://nvie.com/posts/a-successful-git-branching-model/
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:https://www.praqma.com/resources/papers/git-flowEr det korrekt forstået, at branching modellen som anvendes, ligner gitflow?
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.
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.
Det kunne være interessant at høre mere om jeres udviklingsprocesser og hvilke roller i har. Hvordan har i organiseret jeres udvikling?
Et hurtigt kig på et projekt der er rimelig aktivt viser 18 deployments igår :)
Kører på Mercurial med 3-4 udviklere.
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!
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?
Det gør vi!That being said, vi ses i Aalborg 21. maj til den lange version!
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 :)
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.
Vi deployer nogle dage lidt mere end 10 gange om dagen, vi bruger CircleCI og er glade for det.
Cool. Hvilken versionsstyring bruger I og hvor mange udviklere er I?
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.
Ja, vi har også oplevet at vi var lettere frygtsomme undervejs. Det er interresant. Hvad er det der gør det så angstprovokerende?