henrik knopper bloghoved

Ingen continous deployment under ITIL?

På GOTO havde Michael T Nygard (som trods navnet er ærkeamerikansk - og i øvrigt altid værd at høre på) et indlæg om "the deployment army".

Den hær af mennesker som skal til for at lave et release i ITIL styret miljø.

I ITIL v3 2011 var der mindst 103 roller, så det er klart at der skal en del mennesker til. (Faktisk skal der ret mange mennesker til hvad som helst. Det skriver jeg om en anden gang.)

Nu er jeg en af dem der mener at agil udvikling er vejen frem, men her giver continous deployment og ovennævnte hær af mennesker et par udfordringer:

  • Med så mange mennesker involveret bliver en release meget dyr, så tanken om hyppige releases får typisk de økonomiansvarlige op på barrikaderne.
  • Du kan ikke lave en ITIL-godkendt kontrolleret udrulning af en release du ikke i månedsvis har vidst hvad indeholdt.

Det ville ellers give god mening at dele releases op i mindre bidder.

Når du samler dine releases i store batches, bliver mængden af fejlkilder mange-doblet. Det betyder at risikoen for at noget går galt vokser.
Så skal du bruge rigtig mange ressourcer på at forsøge at finde fejlene ved at teste for alle kombinationer af ny kode som bunken af rettelser implementerer.

Og det er jo lige præcis hvad der sker med ITIL - og specielt i de regulerede industrier.

Men hvad kan man gøre?

Lave continous deployment til et valideringsmiljø med løbende test af de moduler der bliver ændret?

Og skal man så lave de samme små deployments ud i produktionsmiljøet bagefter, eller skal man samle de små deployments i gammeldags batches?
Så mister man en alt for stor del af fleksibiliteten, men genvinder forudsigeligheden og kontrollen - og behovet for en mindre hær.

Hvad gør I?

Er der nogen der har fået ITIL og SCRUM til at mødes?

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Ole Elkjær Christensen

Jeg er basalt set også tilhænger af agil udvikling. Jeg har dog set flere tilfælde af begrebet agil hvor det i virkeligheden mere betyder panisk adhoc. Det sker ofte når man begynder at mene at agil udvikling skal bruges overalt og specielt på systemer der forventes at være stabile så som produktions systemer med rigtige kunder :-)

Er det virkelig meningen at noget der er opfundet til software udvikling skal presses ned over alt andet også, eller er det bare mangel på forståelse af metodens begrænsninger ???

Jeg kan godt se at i et tilfælde som Google med 100000 servere eller mere, er det ikke noget problem at lave deployment til 50 servere og så på den måde få testet live om rettelsen/modulet virker, men for de fleste virksomheder er en prod web server et sted med kunder online. Deployment betyder som regel nedetid i et eller andet omfang. Giver den forøgede ustabillitet ved vedvarende deployment forøget kundetilfredshed ???

/Ole

  • 1
  • 1
#2 Deleted User

Continuous deployment er jo ikke en religion, metode eller noget andet af den slags. Det er et mål og et begreb for at din deployment process er så automatiseret at den kan køre af sig selv. Det bør betyde at din deployment process er stabil og dermed behøver der ikke sidde en person og lave fejl ved deploy.

Så for at få det helt på det rene.. hvis man får noget ud af at kunne smide en ændring i produktion hurtigt og fejlfrit så er det nok en god ide at bygge sig et continuous deployment miljø.

For at tage dit eksempel er det ikke continuous deployment der fordrer at man skal sende samtlige ændringer i produktion og så lade brugerne finde fejl i dem. Continuous deployment gør det blot muligt. Det er aldrig en god ide at sende fejlbehæftet kode i produktion hvis brugerne ikke kan håndtere det.

  • 0
  • 0
#3 Deleted User

Jeg har ikke den store erfaring med process (ITIL, men har styr på scrum) og organisation som du virker til at være udsat for men giver da et bud alligevel ;-)

De mange mennesker du taler om er vist et problem uanset scrum og continuous deployment. Det lyder vist til at være et politisk problem mere end teknisk.

Omkring scrum. Laver man netop ikke et "stort" deploy til produktion i slutningen af et sprint ? F.eks. efter 4 ugers arbejde. Så kan er det vel ikke det store antal gange hæren af folk skal i sving i forhold til normale store releases. Umiddelbart kan continuous deployment stadig være en hjælp i forhold til at f.eks. et demosite altid er up-to-date med de nyeste rettelser. Så kan product owner altid løbende tjekke og afprøve funktionaliteten som der er implementeret. Det kunne ITIL hæren måske også gøre løbende?

Til sidst vil et continuous deployment miljø også hjælpe til at få ændringer ud i produktion med sikkerhed om at det virker som på demo. Det er trodsalt samme deployment der er sket.

  • 0
  • 0
#4 Lars Zobbe Mortensen

Du får kun et kort svar – selv om et langt svar egentligt var på sin plads.

  1. Mange roller (du snakker om 103) betyder ikke nødvendigvis mange mennesker (blot at arbejdet KAN deles imellem mange mennesker hvis opgaven er så stor at der er behov for det).
  2. ”Er der nogen der har fået ITIL og SCRUM til at mødes?” – Ja, jeg har set at det kan hænge sammen.
  3. Hvad skal man gøre – det er kraftigt afhængig af situationen (kan være forskellig fra opgave til opgave). Vær opmærksom på at der IKKE i ITIL er noget krav om at der skal være et valideringsmiljø - der er et krav om at man skal OVERVEJE om der skal være et test- (validerings) miljø.
  • 1
  • 0
#5 Jonas Swiatek

Hvis man lige blander process ud af det at lave continuous deployment, og kigger på det teknisk er det somregl dér problemet er. Rigtig mange organisationer har slet ikke den nødvendige infrastruktur på plads til at kunne. Det kræver et, når vi snakker web i hvertfald, snedige setup af servere de rigtige steder.

En ting jeg rigtig ofte ser er at udviklerne kæmper imod en bunke driftsfolk for overhoved at kunne lave noget der ligner.

Hvis teknikken med CI og det hele bare spiller rent teknisk, er continuous deployment blot en forlængelse af det, som vandrer helt ud i DMZ delen af serverrummet og rumsterer rundt dér - hvilket ofte får de fleste driftsfolk til at dø af skræk.

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