Over a million developers have joined DZone.

5 Things Nobody Tells You About DevOps

There are some harsh truths to employing devops. We have a look at them in this article.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today


Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}