|
|
|
|
|
|
by beat
4440 days ago
|
|
|
In the traditional development/operations divide, developers often have no access to and little insight into the production environment where their code will be run. As such, they cobble together whatever makes it work, and then "throw it over the wall" to operations, where it has to run in a very different environment. This makes for hellish manual deployments, done on multi-day phone calls with ops staff who don't understand how the code works talking to developers who don't understand the rules and procedures of ops. If you see places where production code has to run in WebSphere or Weblogic because it's "enterprise", but want developers working in Tomcat to save money, run away. This leads to situations where operations starts providing "developer resources" in terms of servers, dba support, maven repositories, etc, that turn into a tar pit where development gets stuck in incomprehensible bureaucracy, and "hack" around the system in order to actually get anything done. And then security or someone else in ops finds some little skunkworks dev system and has a fit because developers don't understand what they're playing with - or worse, they find out about the skunkworks because they get pulled in to fix what developers screwed up, with their own managers howling about who's gonna pay for it... So to me, the beauty of DevOps is getting dev and ops working together in concert from the start to create a consistent development/production environment, where the same automation can be used to maintain both. This is a win for everyone. |
|
|
You can wax poetic about how it used to be, or complain about people being overworked all you want, but that's an issue of expectations. Personally I never want to go back to two week "integration" processes and multi-day manual deployments.
DevOps to me is an exercise in not making things more complciated than they have to be on the config/deploy side.