DevOps is a thing and it works... kind of
DevOps is a thing and is true and does exist... It however isn't a magic bullet for everything. It's not like extreme programming (i.e. sitting two devs together, or in this case sitting a dev and op together).
From a Dev Perspective, you have to be very used to using proper check-in/check-out of code repos while working on projects. From an Op Perspective, you have to get used to automating things and making things repeatable, you're normally aiming for more "small/short" outages rather than less "long/prolonged" outages.
Essentially, it works really well with applications that can scale across lots of servers (i.e. large scale web apps), or software that's provided to customers via a website/api and that ilk of stuff. In relatively large enterprises, internal services can also be built in this way.
Like anything in IT, you have to consider if and why you should do the DevOps on something.
Most people structure a bunch of "Ops" guys that can either use 1) hypervisors 2) public/private cloud 3) containers - and importantly, can also do some scripting/tying things together with Config Management tools like Puppet/Chef/Ansible/Others etc. The job of the Op is to then automate the arse off everything in sight. i.e. that server that does that thing? yep, make it built itself and get the code on it, and test stuff works, then join a pool. Oh, and if possible, let us specify if it's production/test/dev etc and put the appropriate environment variables/datasets on it.
The point of the Op is to understand the codebase/system at hand, and make delivery of that system to customers entirely repeatable and easy to deploy/build. That then changes how you deliver stuff to customers, you can literally kill an environment and build a new one immediately and quickly, and know you'll get the same thing each time. Essentially, your infrastructure starts turning into code. Basically, it improves everything.
Additionally, you also normally bolt Project Managers/Product Managers/Business People into the mix and discuss what's being done next/what's important. In the end, though you need to be more sociable, you get a bit more of a voice into that's stupid because of Y so how about doing it with X instead.
It does work, but it's not for everyone/everything, some things just aren't worth the effort, though as the software/systems to automate get easier/better understood, I think more things will come into this methodology, because it eats ITIL for breakfast - if done well... Otherwise it sucks
Biting the hand that feeds IT
