5 Things Nobody Tells You About DevOps

bas plum had a great article yesterday on devops.com where he lists the five harsh truths about devops. i will summarize his 5 points and add one of my own.

1. there’s no “that’s not my job” in devops
   plum points out that with devops, the development team is responsible for writing the automated scripts that deploy the application. that used to be manual work done by someone in operations. just as in manufacturing, automation will eliminate jobs. typically, that system administrator can be retrained to work in development writing deployment scripts, but programming is a different skill from restoring databases. if you can’t adapt, it’s time to update that resume.
2. not everything should be automated
   plus argues that yes, devops can be made to work on any platform, including the mainframe. no, it’s not confined to projects using agile. you don’t have to use ruby or php, it’ll work for fortran applications too, but be realistic. transforming an application to take advantage of devops is expensive. you should not invest in something that is slated for sunset, or has only one release per year to fix some minor bugs. legacy systems are considered legacy for a reason. focus on the top 20 percent of your portfolio instead.
3. developers will need to get their hands dirty
   some developers like to do one thing, and one thing only: write code. grudgingly, they’ll test, they’ll attend team meetings if they have to, and, if tortured, they’ll write documentation. but forget about getting them to create the installation scripts. according to plum, “that mindset is not going to fly in a devops world. developers need to think about how the application will run as a nonfunctional requirement, and treat it with the same level of importance as security, performance and data privacy. unless they feel ownership of the installation process, monitoring the environment and collecting end-user feedback, you have not really implemented devops.”
4. operations can no longer be ticket-driven
   usually, the operations team doesn’t get involved until someone from the development side opens a ticket for deployment. that’s too late for any kind of meaningful integration. the answer according to plum is not to open a ticket three months earlier; tickets are meant to be assigned, worked and closed within a short period of time. the type of collaboration needed between development and operations is far more complicated, and should be treated like it’s a project. that’s really difficult for most operations organizations. it’s not part of their culture, and they’re not staffed for that.
5. your process is really, really bad
   plum’s last point is that as soon as you start automating your software delivery process, you’ll find out exactly how inefficient it really is: duplicate reviews, inconsistent forms, competing standards, etc. when you take away the people layer, you can’t hide the crazy anymore. you don’t want to take what you have today and force it into an automation tool. you will need to standardize before you optimize, and optimize before you automate. that means a lot of different towers will need to cooperate — something that won’t happen unless there is an outside party driving the cooperation with a big stick.
6. you can’t skip the database
   the point i would like to add is that while leading organizations are increasingly adopting devops, they often find it challenging to support database release automation, while ensuring database updates are delivered rapidly and securely. these challenges have led a number of fortune 500 companies to database downtime caused by out-of-process updates, code overrides, and other database glitches. the database must be treated as a first class citizen in the devops process or it can become the weakest link which hold back the entire development lifecycle.

for more about devops for database download our free ebook: in database automation we trust.