De er helt avhengige av å slippe kode til serverne mellom ti og 15 ganger i døgnet

[Martin Braathen Røise]

De er helt avhengige av å slippe kode til serverne mellom ti og 15 ganger i døgnet

[NFNGOW6W]

Er dette en reklameartikkel for Evry?

[Stefan Landrø]

Overskriften kan virke noe misvisende. Når man jobber med kontinuerlige leveranser i et DevOps-miljø gir det stor mening i å slippe kode til produksjonsmiljøene straks koden er ferdig skrevet og testet. Da bygger man ikke opp store releaser som skal slippes noen få ganger i året, med den risikoen det medfører. I tillegg oppnår man en ekstremt kort time to market når man kan teste ut ny funksjonalitet og gjøre kontinuerlige forbedringer.

 

Hilsen

 

Stefan Landrø, Digipost

[bepsays]

Overskriften kan virke noe misvisende. Når man jobber med kontinuerlige leveranser i et DevOps-miljø gir det stor mening i å slippe kode til produksjonsmiljøene straks koden er ferdig skrevet og testet. Da bygger man ikke opp store releaser som skal slippes noen få ganger i året, med den risikoen det medfører. I tillegg oppnår man en ekstremt kort time to market når man kan teste ut ny funksjonalitet og gjøre kontinuerlige forbedringer.

 

Hilsen

 

Stefan Landrø, Digipost

 

Men skjer dette 10-15 ganger i døgnet?

 

Og hva legger dere da i "ferdig skrevet og testet"?

 

Dere er én av to leverandører av Digital postkasse, og da kunne det være nyttig med litt info om dette, som en input til spørsmålet "hvor er dataene mine sikrest?"

Endret 2. desember 2016 av bepsays

[quantum]

Som det står er hensikten å slippe ferdig kode i produksjon når den er ferdig, altså implementert og testet, med en gang, fremfor å samle opp store antall endringer i store releaser. Det er ikke noen spesiell forskjell på betydningen av "ferdig skrevet og testet" om man prodsetter 10-15 ganger i døgnet eller mer, eller 2-4 ganger i året.

Forutsetningen her er å ha en fullstendig automatisert produksjonssettingslinje slik at faren for manuelle feil under prosedyren er minimal, og det er altså det man tilstreber i et DevOps-miljø. Da øker ikke risikoen for feil selv om antall prodsettinger øker. Videre sitter man med akkurat de samme endringene som kan være testet på akkurat samme mer eller mindre grundige måte som om man hadde sjeldnere prodsettinger, slik at risikoen for feil i implementasjonen er omtrent den samme. (Dog; når man praktiserer DevOps og CI er man i praksis også ofte flinkere med tester og testdekning enn om man holder på med manuelle rutiner og lav prodsettingstakt.) Men så får man altså til slutt gevinsten ved at hver prodsetting er isolert til å inneholde et veldig lavt antall endringer, som da gjør situasjonen mye mer kontrollerbar når noe faktisk går feil. Det er enkelt å rulle tilbake, siden det er veldig lite annen uberørt funksjonalitet som er prodsatt samtidig, og det er vesentlig enklere å feilsøke, siden feil jo som regel følger av endringer og omfanget av potensielle endringer som kan ha forårsaket feilen er veldig lavt.

Hvor dataene er sikrest kommer i ganske stor grad av andre forhold enn hyppigheten av prodsettinger. Ved lange prodsettingssykluser hører det dog logisk med at ferske sikkerhetsoppdateringer på ymse komponenter ikke havner like raskt i produksjon.

Endret 2. desember 2016 av quantum

[Slartubart]

Det finnes en mellomting mellom 10-15 ganger i døgnet og 2-4 ganger i året. Just sayin..

[bepsays]

Som det står er hensikten å slippe ferdig kode i produksjon når den er ferdig, altså implementert og testet, med en gang, fremfor å samle opp store antall endringer i store releaser. Det er ikke noen spesiell forskjell på betydningen av "ferdig skrevet og testet" om man prodsetter 10-15 ganger i døgnet eller mer, eller 2-4 ganger i året.

 

Forutsetningen her er å ha en fullstendig automatisert produksjonssettingslinje slik at faren for manuelle feil under prosedyren er minimal, og det er altså det man tilstreber i et DevOps-miljø. Da øker ikke risikoen for feil selv om antall prodsettinger øker. Videre sitter man med akkurat de samme endringene som kan være testet på akkurat samme mer eller mindre grundige måte som om man hadde sjeldnere prodsettinger, slik at risikoen for feil i implementasjonen er omtrent den samme. (Dog; når man praktiserer DevOps og CI er man i praksis også ofte flinkere med tester og testdekning enn om man holder på med manuelle rutiner og lav prodsettingstakt.) Men så får man altså til slutt gevinsten ved at hver prodsetting er isolert til å inneholde et veldig lavt antall endringer, som da gjør situasjonen mye mer kontrollerbar når noe faktisk går feil. Det er enkelt å rulle tilbake, siden det er veldig lite annen uberørt funksjonalitet som er prodsatt samtidig, og det er vesentlig enklere å feilsøke, siden feil jo som regel følger av endringer og omfanget av potensielle endringer som kan ha forårsaket feilen er veldig lavt.

 

Hvor dataene er sikrest kommer i ganske stor grad av andre forhold enn hyppigheten av prodsettinger. Ved lange prodsettingssykluser hører det dog logisk med at ferske sikkerhetsoppdateringer på ymse komponenter ikke havner like raskt i produksjon.

 

Har dere en publisert endringslogg på disse 10-15 endrigene i døgnet? Hva er dette for endringer? Hvordan versjoner dere dette? Er det alltid siste versjon i produksjon?

 

Jeg forstår DevOps-metoden deres, men har problemer med å forstå behovet for denne endringstakten -- som vel må innebære økt risiko, om enn liten så i alle fall unødvendig, om dere da ikke bare endrer farger og CSS i presentasjonslaget? Og da forstår jeg ikke behovet.

[thorsan]

Hvordan gjør dere release, canary / blue, green e.l.?

[Gjest Slettet-Pqy3rC]

Denslags endringstakt på produksjonstjenere høres ut som en seriøs mangel på testutstyr og/eller utviklingsmål. At man har muligheten til hurtige oppdateringer av produksjon er en god ting, at man kontinuerlig må benytte seg av slikt virker totalt planløst.

Endret 3. desember 2016 av Slettet-Pqy3rC

[quantum]

som vel må innebære økt risiko, om enn liten så i alle fall unødvendig

 

Nå har jeg ingen som helst tilknytning til Digipost, så de må nok svare selv, men min erfaring er altså at man prodsetter ofte for å redusere risiko, ikke øke. Utifra tankegangen beskrevet ovenfor. Hvorfor mener du risikoen øker jo oftere man prodsetter (gitt et devops-regime)?

[quantum]

Det finnes en mellomting mellom 10-15 ganger i døgnet og 2-4 ganger i året. Just sayin..

 

 

Ja, utvilsomt. Jeg antar poenget ditt er at 10-15 ganger i døgnet er for ofte. Poenget er at endringstakten driver prodsettingstakten. Så om man har 10-15 features/funksjoner/endringer ferdig testet i døgnet blir takten 10-15 prodsettinger i døgnet. Så man må enten jobbe saktere, eller ha et argument for å samle opp endringer i større releaser, hvis man vil ha ned takten. Det er kanskje det siste alternativet du tenker på, og spørsmålet er da hvilke fordeler man har ved (å gå tilbake til) dette? 

[quantum]

Denslags endringstakt på produksjonstjenere høres ut som en seriøs mangel på testutstyr og/eller utviklingsmål. At man har muligheten til hurtige oppdateringer av produksjon er en god ting, at man kontinuerlig må benytte seg av slikt virker totalt planløst.

 

For å opprettholde en slik takt er man ekstremt avhengig av (automatisert) testing og testutstyr. Hva man utvikler når, og har som mål, er ikke så veldig hardt bundet til prodsettingstakten. Man kan utvikle akkurat det samme til akkurat samme tidspunkt, enten man prodsetter det umiddelbart eller velger å la det ligge urørt i skuffen et halvt år. Det er ihvertfall min erfaring. 

 

Generelt er det vel slik at man i smidig tankegang prøver å unngå å lage planer basert på antagelser om den ikke helt nære fremtiden. Det kan man forsåvidt se på som en slags mangel på urealistiske planer. Dette har med forutsigbarhet å gjøre, og den varierer i ulike sammenhenger, og påvirker derfor hvilke metodikk som er gunstig i en gitt setting.

Endret 3. desember 2016 av quantum

[TheBoz]

d

[Sandormen]

Det høres ut som de har et godt utvikling/test-miljø. -Ikke bare utvikling, som mange desverre kjører på. -med testing kan man spare masse tid. -En ansatt mer, men penger spart i lengden.

[Angelboy]

Hvis datasenterene ligger i India blir jeg automatisk skeptisk

[Sokkalf™]

Det er nok ikke veldig mange norske, europeiske eller amerikanske selskaper som har datasentrene sine i India. Latency blir uforholdsmessig høy. Det mer vanlige er vel heller at indere har tilgang til å utføre vedlikehold på maskiner på et datasenter i europa etc.

[Civilix]

DevOps eller NoOps?

 

Man må være veldig forsiktig med å ikke kutte ett viktig ledd når man ønsker å øke hastigheten på releases, hvordan står det til med "operations team" hos digipost må man tro? Er de i "skyen"