Sidehistorik
Purpose
To make good Changes and SOP's
Formål
For at man kan lave gode Changes og SOP'er (Standard Operating Procedures) er det ligesom at være en kok der skal lære at lave god mad, eller måske den matra man kører indenfor militæret - gentagelse, gentagelse, igen, igen..
Målet er at ende med en god opskrift, så vi kan "lave god mad" hvergang Det kalder jeg "Cookbook" princippet
Lad os starte med de systemer vi normalt har at arbejde med:
- its similar to beeing a chef that need to learn how to make a good dish, or a marine that need to perform a certain function really good, as in: repetition, repetition....
In short, the goal is to end up with a solid recipe, to make the same "good meal" every time - That the Cookbook principle for me
First, lets have a look at the environments we (commonly) deal with in an every days Service Operation environment:
System | Purpose | Who can deploy here? | The good and bad stuff |
---|---|---|---|
Development | Basic or custom development, this can be on the developers own systems or a development setup | Developer | A voliatile environment with a potentionally high number of changes and no control. Very flexible and agile for high productivity |
Test | Testing what has been released via development | Developer | A voliatile environment with a potentionally high number of changes |
Stage | Deployment and testing of the release after test in Test | Sysadmin (And/or Developer if DevOps is used) | A known/controlled environment |
System | Formål | Hvem kan deploye her | Gode/dårlige ting |
Development | Grundudvikling, dette kan ofte være udviklerens egen maskine eller viruelle systemer | Developer | Flygtigt miljø med mange ændringer og ingen kontrol Meget flexibelt med mulighed for stor produktivitet |
Test | Test af det der er udviklet på Development | Developer | Flygtigt miljø med mulige ukendte ændringer |
Stage | Deployment af det der er udviklet på Development og teste på Test | Sysadmin (Evt. Developer ved DevOps) | Kendt miljø under Change kontrol. Få eller ingen ændringer |
Production | Sysadmin (Evt. Developer ved DevOps) | Kendt miljø under Change kontrol. Få eller ingen ændringer og skal til enhver tid matche Stage miljøet |
And/or Developer if DevOps is used) | A known/controlled environment - few and controlled changes that has be have been performed in Stage. |
The environments from above is not the only ones, in many (large) setups we can have several othersDer kan sagtens existere flere miljøer end de 4 ovenstående - f.eks er disse relativt normale:
System | Formål | Hvem kan deploye her | Gode/dårlige ting |
---|---|---|---|
UAT | User Acceptance Test | Sysadmin (Evt. Developer ved DevOps) | Kendt miljø under Change kontrol. Få eller ingen ændringer og skal til enhver tid matche Stage miljøet |
integration | Test omkring integrationer med andre systemer, f.eks import/export/synkronisering | Sysadmin (Evt. Developer ved DevOps) | Kendt miljø under Change kontrol. Få eller ingen ændringer og skal til enhver tid matche Stage miljøet |
DevOps
DevOps og Continues Delivery koncepterne bryder lidt med den traditionelle Udvikler vs. Sysadmin tanke, idet at man ofte antager at Sysadmins blot kan deploye, mens udviklere ikke kan arbejde (overhovedet) i Stage eller Produktionsmiljøer.
...
Advarsel |
---|
Der er også datasikker- og datafortrolighed at tænke over, når udviklere gives nogen som helst form for adgang til Stage eller Prod, som ofte indeholder personhenførbar eller fortrolig data, både fordi at antallet af personer med tilgang simpelthen udviddes, sekundært fordi udvikleren [potentielt] har mulighed for at udnytte softwaren til at udtrække fortroligt data udenom normale foranstaltninger.
Sekundært er der IT Revisionsmæssigt gode grunde til at funktionsadskille. |
Miljøer
Vores absolutte minimum må være:
...
Gliffy Diagram | ||||
---|---|---|---|---|
|
Oprettelse af opskrift og gennemførsel
Ligemeget hvor mange systemer eller rettere niveauer der er på vores platform, har vi mulighed for at forbedre vores opskrift op gennem de forskellige niveauer fra Development til Production, og med dagens teknologier indenfor virtualisering hvor vi kan rulle en server eller et system tilbage til et tidligere state på meget kort tid (via snapshot teknologi) - kan man indenfor de forskellige systemer sagtens gentage processen flere gange:
Gliffy Diagram | ||||
---|---|---|---|---|
|
Fra opskrift til SOP
En opskrift i kogebogen er ofte kun fremadrettet, dvs. tanken om at gå tilbage er ikke altid med i opskriften, ofte har vi ved fejl bare rullet tilbage til et snapshot og startet forfra.
...