Back in the good (bad?) old days, developers wrote code and chucked it over the wall to QA for testing. The QA folks in turn chucked it over the wall to ops.
Too many failed projects to count later, along came Agile. We brought QA into the development process, and in the Extreme Programming case, developers wrote the test plans themselves (with the help of stakeholders), and wouldn’t go home until every test passed. But they still tossed finished code over the wall to ops.
Today, the Cloud is pushing all software teams to automate the operational environment – even if you aren’t actually running production code in a Cloud. Automated ops is the wave of the future.
Automated monitoring, automated management, automated provisioning are the watchwords of the day. But none of these newly minted best practices remove the need for monitoring, management, or provisioning. Instead, they enable a broader range of people to handle the tasks using increasingly lightweight, sophisticated tools. Even developers.
Just as developers added automated testing to their toolbox, today they must add automated monitoring as well. Only we’re not talking about simply watching red lights and green lights. Instead, developers must write their own monitors and every time they roll out some code, they must make sure all the monitors pass. Sound familiar?
DevOps is only a burden on developers if they have inadequate automation tools to handle ops from the perspective of working software, just as Agile was a burden without the appropriate automated testing tools. With the right tools and the right practices – using the tools properly is every bit as important as the tools themselves – continuous build, continuous deployment, and continuous integration are well within reach, or even easy. But if you still find that these activities are too difficult, you’re not doing them properly.
