3 ms·
I actually look at from another perspective: It seems to have stemmed from Ops teams saying "What can we do let dev teams build what they want, but in a way we
by mugsie 12y ago
I actually look at from another perspective:
It seems to have stemmed from Ops teams saying "What can we do let dev teams build what they want, but in a way we can support it"
e.g. - a system needs an entry in the /etc/hosts file (a bad example I know, but a nice simple one for the basic use case)
old method: Dev files a Jira ticket, and the Ops team make it part of their golden images for production.
new method: Dev makes a change in the Config Management DB. Gets reviewed by a member of Ops, who either approves, or makes a suggestion to change it. Change gets tested against staging, then merged, and the system gets updated.
Ops know what the system needs, Dev knows how long it will take, and has an understanding of how it is deployed in real life.
- icedchai 12y agoActual new method: dev logs in to production server, changes something live as part of a emergency / hot fix. It never gets documented anywhere.
- toomuchtodo 12y agoI wouldn't go that far. Its documented on the system when it gets hot imaged and the image is never rebuilt from the config mgmt tool again /s
- dreamfactory2 12y agoso not code as infrastructure and therefore precisely not devops
- icedchai 12y agoyes, but that adhoc activity is what many (incorrectly) perceive as "devops", so still relevant.