Jag får ofta frågan från våra kunder om hur man ska jobba med uppgraderingar i sin förvaltning av webbplatser. Ska man uppgradera sin plattform eller ska man sitta still i båten tills det verkligen behövs? Svaret på den frågan har ändrats under de senaste året.

Sedan ett tag tillbaka har EPiServer gått över till något som man på engelska kallar Continuous Release Process, vilket i praktiken innebär att det släpps nya releaser av EPiServer väldigt ofta. Med väldigt ofta menar man 1-3 gånger per månad. Det här innebär att vi alla också måste tänka lite annorlunda runt hur vi jobbar med uppgraderingar och vad vi kan förvänta oss av nya releaser.

Två nya versioner på en månad – är det verkligen bra?

I grunden tycker jag att det är bra att det kommer nya versioner ofta. Det gör det möjligt att hänga med i det som händer och snabbt få tillgång till buggfixar och funktioner som kan innebära stor nytta för redaktörerna. Problemet är att alltför många personer (speciellt utvecklare, men även kunder) är lite brända av uppgraderingsprojekt, som alltför ofta blivit enormt krångliga och kostsamma. Det gör att man inte vill ge sin in i ett uppgraderingsprojekt om man inte absolut måste. Jag har också många gånger ifrågasatt uppgraderingar om de inte tillför någon nytta för webbplatsen eller redaktörerna. Men det är dags att vända blad och tänka nytt.

Jag tror att problemet med tidigare uppgraderingar många gånger har berott på att den nya versionen har innehållet för många nya saker. Om det har gått ett år mellan versionerna, har man hunnit utveckla mängder med nya saker, som riskerar att skapa en konflikt med det gamla. Det har gjort uppgraderingarna riskfyllda, svåra och krångliga. Det innebär att de estimeras till en hög prislapp, kunderna tycker att det blir för dyrt och man väljer att inte uppgradera. Det blir som ett moment 22 som gör att många idag fortfarande sitter med EPiServer 5.

I och med att det nu släpps nya versioner hela tiden, så är inte en uppgradering lika riskfylld och bör därmed kunna göras mycket oftare. Jag hör ofta utvecklare, avråda kunderna från att uppgradera eftersom det finns risker med det. Don’t fix if it is not broken, är ett vanligt talesätt. Jag hör också många argumentera för att man inte ska gå till den senaste versionen för den innehåller så mycket buggar, så det är bättre att låta andra ta hand om de problemen först, så kan vi uppgradera om ett halvår. Jag förstår verkligen dessa argument, för de kommer av erfarenhet. Men är det så här vi ska ha det? Ska man betala en årlig prenumerationsavgift för sin licens och sedan inte våga uppgradera?

Vi måste ha andra typer av förvaltningsavtal

Det viktigaste i det här läget är att vi alla börjar tänka på den nya releaseprocessen. Det gäller säljare, utvecklare, projektledare och kunderna. När det släpps nya releaser så tätt som det gör nu, kan det omöjligt innebära att det är för många buggar i och att uppgraderingar blir riskfyllda i och med för många stora förändringar. De gamla argumentet håller inte längre och som jag ser det måste vi försöka jobba annorlunda.

Jag vill i första hand att leverantörerna tar sitt ansvar i det här och förändrar sina förvaltningsavtal. Idag är en uppgradering ofta någonting som kunden får beställa, det estimeras och behandlas som ett projekt. Ibland initieras det av leverantören, men allt för ofta kommer det från kunden själv. Detta resulterar ofta i att det inte blir gjort, för att man prioriterar andra saker i den lilla budget man har. I och med den nya releaseprocessen av EPiServer tycker jag att en uppgradering av plattformen ska ingå i förvaltningsavtalet. Hur ofta man gör en uppgradering kan variera från olika avtal, men minst två uppgraderingar per år bör ingå. Kunderna planerar därmed för uppgraderingar i sin förvaltningsbudget och behöver inte äska särskilda pengar för uppgraderingar.

Det centrala är att det inte ska vara något som ska beställas och prioriteras i förhållande till annat. Den avgift man betalar för sin förvaltning, ska inkludera även uppgraderingar. Även om man som kund just nu inte har behov av nya funktioner, så hänger man med i utvecklingen och har möjlighet att aktivera funktioner när behovet uppkommer. Om vi får till ett sådant här arbetssätt, finns det också mycket större möjligheter att påverka releaseprocesser och kvalitet ända tillbaka till produktutvecklingen. Så innan du skriver på ett nytt förvaltningsavtal, se till att uppgraderingar kommer upp på tapeten och in i avtalet.