Sidehistorik
...
DevOps and Continues Delivery concepts extending the traditional concepts of the traditional Developer vs. Sysadmin thinking, where a common stage is that Sysadmins deploys, while Developers does not interact with Stage- or Production-environments.
Dette er ikke nødvendigvis koliderende tankegange, men man bør overvejer og implementere lidt anderledes regler og godkendelsesprocedurer, da jeg (belært af små 10 år på Sysadmin siden) må erkende:
| Info |
|---|
Udvikleres synsvinkel på klassiske dyder og procedurer er som regel koncentreret om helt andre aspekter end dem som en Sysadmin eller driftsansvarlig person fokuserer på - for udvikleren har typisk et fokus på at komme hurtigt i mål med nye features og/eller deployments, - somme tider på bekostning af tests og datadiciplin. Giver man udvikleren - eller tvinger han sig adgang - til Produktionsmiljøet kan man som Sysadmin godt anse slaget for tabt. |
These are not nesesarily colliding ways of thinking, but requires some thinking and implementation that enforces special rules and approval-procedures, since (learned over 10 years as Sysadmin):
| Info |
|---|
The Developers Point Of View on classic vertuas and procedures are typically focus in a complete other maner than those of the Sysadmin - The Developer has a focus on getting quickly to the next finish line with features and deployment - sometimes the cost are giving a little slack on test and deployment deciplin. Giving the Developer access to Deployment in the Stage or Production without enforcing special rules and approval-procedures, do consider the battle lost |
During DevOps eller Continues Delivery one should implement rules, procedures and technically based access/approval workflows where deployment depends on successfully in the previous enviroments, to prevent utilsigtet eller forhastet deployment from de Developers Ved DevOps eller Continues Delivery bør man evt implementere regler, procedurer eller mere tekniske funderede adgange som godkendelser eller workflows hvor deployment afhænger af success tests i de miljøer der er før det ønskede miljø for deployment, for at forhindre utilsigtet eller forhastet deployment fra udviklerens side.
| Advarsel |
|---|
Do also give data 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. |
...
Environments
Vores absolutte minimum må væreThe minimum should be:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Endnu eller endnu bedreEven better:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
Creating the recipe and doing deployment
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:
...