Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Actual new method: dev logs in to production server, changes something live as part of a emergency / hot fix. It never gets documented anywhere.


I 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


so not code as infrastructure and therefore precisely not devops


yes, but that adhoc activity is what many (incorrectly) perceive as "devops", so still relevant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: