Here are five tips to incorporate DevOps into your software delivery process.
Remember: Adoption won’t happen overnight. Anything worth doing requires time and investment, so be patient, hold your teams accountable, and commit to the process.
You may think you're already collaborating efficiently, but development teams are often divided into silos: Developers write code; the operations team deploys the code; QA tests the code; production support repairs applications/servers; and so on. There is minimal communication between the silos and work is often incorrectly executed or redone.
Embracing Agile project management is a major tenant in DevOps culture. Agile works aggressively toward bringing your teams together by restructuring work and introducing feedback along the way. By default, tasks are broken down from larger sets of requirements into manageable chunks, or stories. Work is completed in small iterations, or sprints, that typically run for two weeks.
Defining work in smaller, discrete tasks allows each team function to work on tasks without getting tangled. Another benefit: Code is delivered faster with short iterations, allowing stakeholders to provide feedback more quickly. The result is faster integration of required changes at a lower cost because issues are fixed and improvements are made closer to their introduction. In other words, the work is done when it’s relevant.
And we mean everything! A truly mature DevOps team has automated everything—from their testing to their deployments to provisioning the machines they deploy to. With the advent of cloud computing this has become a more realistic goal for all.
Before, to provision a new environment, add capacity, or triage a corrupt server, you had to physically add or remove hardware to your network. But now that physical management is left to the cloud provider, you can script and deploy a whole environment stack at the click of a button, and it’s ready to use within minutes. Automating a step further applies to deployment of the application itself. Through tools and frameworks available today, we can build, deploy, and test code, at the click of a button.
Best-practice blogs, like Mobify, recommend "treat[ing] your server configuration like developers treat code." Extract out environmentally-specific application properties into XML configuration files that can be stored in source control and applied using a configuration management system. That is the key to automation, and the cornerstone of DevOps.
The only difference between dev and production should really boil down to a set of connection strings and environment variables or, as Humble and Farley put it in Continuous Delivery, "There are differences between deploying software to production and deploying it to testing environments—not least in the level of adrenaline in the blood of the person performing the releases. However, in technical terms, these differences should be encapsulated in a set of configuration files."
This one might be a little hard to swallow for some. We can all relate to the silo’d team structure that Hiscox describes: "we had development teams that threw code over the wall to the release team that deployed it, and then a separate team supported the code once it went to production. In scenarios like this, there is very little empathy between all those different teams. It’s a bit like a relay race and passing the baton — ‘I’ve done my job, now it’s your problem.’”
This cannot be. Everyone is responsible for production, developers and operations alike, and the reasoning is simple. Who better to triage an issue than the person that wrote that code or set up that server in the first place? Furthermore, exposing developers to their “code in the wild” will encourage them to write patterns and make decisions that correlate to how their system will run in production. Simply put, if you don’t task developers with production duties, they won’t write production-optimized code.
The Spotify team has been doing it for years: "developers deploy their code in production by themselves, with or without an ops engineer to hold their hand. This … encourages the dev in question to think seriously about traditionally operations-focused problem areas such as monitoring, logging, packaging, and availability." This forces teams to work very closely with each other because they feel responsible for each other's results.
We all know the importance of a good suite of tests for a software project, and every project starts the same way.
Your goal: 100% code coverage. You start practicing TDD and when the first deadline comes along, you're running a little behind, but you promise yourself that you'll go back and put in all the tests after the sprint wraps up. Before you know it you're barely sitting with five percent coverage. Another scenario: A developer notices several failing tests on his last check-in at the close of a sprint. He comments-out the tests rather than fixing them, promising to address them in the next sprint.
To be successful at DevOps, automated tests have to be written not only for your code coverage, but for your infrastructure scripts as well. If you make a change to your configuration management scripts, there should be a test executed to make sure it compiles properly and passes tests. If you're adding functionality to your application, you should have tests for every scenario.
This is often a time-consuming exercise, but it should be one of the more important habits you maintain. Continuous Delivery asserts that, “If it hurts, do it more frequently, and bring the pain forward." Turn your weakest link into the strongest, and make sure that as your application grows, you're growing the first quadrant of the Agile Testing Quadrants.
The hype around production deployments makes people edgy and extremely nervous. They shouldn't. If you keep these tips in mind, deploying to production should be like any other environment. If you've written your tests and your infrastructure is deployable at the click of a button, then you shouldn't have a problem deploying up or rolling back at will. Etsy has this process so under control that they routinely deploy to their production servers 50 times a day. They've achieved this by fully automating their entire software stack. As a result, each developer has a copy of the production environment at their disposal when making enhancements.
Once the barrier is removed and you can freely deploy to production without hesitation (or nausea), deployment frequency can increase. Then you can deploy in more frequent, smaller segments as you complete your agile stories, instead of deploying everything at the end of your sprint.