What is DevOps?
DevOps is a software development framework that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other IT professionals, (including Product Managers/Product Owners, IT Operations, IT Infrastructure, Enterprise QA, Release Management and Change Advisory Board). The framework acknowledges and supports the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve application performance in production.
The evolution of DevOps.
Many IT organizations do not have a formal DevOps program in place today, however a 2014 CIO survey stated 88% of CIO have it on their roadmap, up from 66% in 2013. The concept was first introduced back in 2009 as the Agile Software Development methods began to mature and evolve. DevOps was born out of the need to study the hand-off between software development and IT operations. In order for development teams to get in a consistent production release cadence, Agile leaders quickly learned IT operations would need to be become part of the “agile team”. However, anyone who has worked in IT understands, there is a natural friction between developers and operations. It won’t surprise you that most developers find the deploying of software outside their job duties and IT operations will likely tell you developers are sloppy with their handoff, often leaving out critical deployment instructions or configuration changes. Yet, when it doesn't work in a lab outside of Dev, it often requires both teams to figure it out - causing even more frustration within these teams.
A successful DevOps program will strengthen the relationship between development and operations, giving them a common goal: Delivering quality software, faster, as one team!
Here are 3 tips to help you get your DevOps program off the ground.
#1 – Create a DevOps cross functional “Team”.
Break down walls between development and operations by creating a DevOps “Team”. Similar to scrum teams, a DevOps team starts better when they’re able to self organize. Being a members of the DevOps Team is a part time team activity, we don’t want to create another silo by removing them from their functional teams. These members come together each week to meet and collaborate, then go back to their functional teams. However, just like with any team, it’s best it if has a captain and a coach. There are two ways to approach this, one way is to have co-captains and co-coaches, ideally one from development and one from operations who share the responsibility. The second approach is to assign a Captain and Coach from one group. If this is the way you want to go, I would suggest the IT Infrastructure team take lead, simply for no other reason than they’re usually “accountable” for anything in production, so having them lead the program will give it a better chance for success.
There is natural friction that occurs on DevOps team. The captains participate in the day-to-day and the coaches (Directors or Senior Directors) meet with the captains every other week and with the entire team in a DevOps “All-Hands” once a month. The best thing to do is embrace the friction and coach through it, lead by example, setting the positive tone, focusing on collaboration and growth. Again, the intent is to create a cross functional team, as it matures, the coaching can move to monthly and all-hands to quarterly gatherings.
When considering the make-up of the team, it’s easy to think it terms of senior developers and operations, but I think this is a mistake. Just like any team, if it’s too small or too big, it will never get out of the starting blocks, or make it around the track. I would look at Operations Team first for core members: Lab/Deployment Manager, Application Installation Engineer & Release Manager. From the Development Team, add the Build Master and Sr. Scrum Master. Then to finish it out, add your QA manager and scrum Product Owner. Resist growing it too big, keep the core team to 6-8 people.
#2 – Agree on the tactical mission of the Devops Team.
DevOps means different things to different people. As you charter the team and have your kickoff meeting, use it to define the teams goals. I suggest defining them as tactical goals. Order is important, so consider:
- Reduce application deployment time through each of the various environments by adopting “Continuous Delivery”. As organizations mature, the number of environments typically grow beyond the typical (Development, Staging & Production) environments found at most to startups to (Development1, Development2, QA1, QA2, SIT (System Integration Testing), UAT (User Acceptance Testing), Training, Performance, Pre-Production and Production). To recap, a startup will use 2 labs + production for 3 environments. A large enterprise, with a business critical application, could easily have 9 labs + production for 10 environments. We call this the delivery pipeline. I’ve witnessed first hand, teams that take 3 business days to move a release into just one of these environments. “Continuous Delivery” is the ability to seamlessly deliver the code, data and configuration changes to any environment, at any time within hours, not days.
- Reduce application development “rework”. The faster you can deploy a release to an environment, the faster you’ll be able to get feedback on how the release is functioning, enabling more bug fixes and enhancements to the code. Without a highly orchestrated deployment process between Development and Operations, you’ll find both teams waste a huge amount of time chasing complex integration, data and configuration glitches. This often involves the development team, which means instead of coding the team is debugging the environment, which adds no value to the business and often puts the developer behind in their current sprint, causing stress. It’s also very frustrating for the IT Ops pros who often wonder why nothing ever works the first time it is deployed. This feeds dissention, damages camaraderie and reinforces the silos you’re trying the bust down. There is no way you can get into a regular release cadence if you’re constantly building break-fix release patches.
- Reduce bottlenecks between functional teams. Developers, QA Testers, User Acceptance Testers, Perf Testers, and IT Ops Deployment resources are typically all on a slightly shifted cadence with competing priorities for their time. I’ve seen releases not get cleared for production, resulting in missing a release date because QA resources we’re busy testing other products. I’ve seen UAT resources pulled, or absent, resulting in no business sign-off. I’ve seen performance testing getting a late start, then failing, resulting in the whole release being cancelled costing the company tens of thousands in loss productivity. A solid release management program within DevOps, focuing on communication and alignment on deliverables is key to ironing out these challenges.
These are my favorite things to start with. They’re big rocks and will make a difference in your organization if you haven’t tackled these areas yet. Have the team talk about the various metrics they’re going to track in order to measure improvement.
#3 – New tools are a must! Have your DevOps team do their own vendor bake-off.
The tools available to automate the creation and teardown of environments, server configuration, application deployment, data refreshing and managing the artifacts and status changes for your Change Advisory Board (CAB) are maturing very nicely. Vendors are leap frogging each other with every release so my suggestion is to have your newly formed DevOps team ask these vendors to come in and give you a demo to see if their products compliment your processes and environment. As a Microsoft .NET shop we used Microsoft TFS to build our release packages, OctopusDeploy for .NET to automate our deployment processes across environments and CHEF for our configuration management. Puppet Labs is also a major contender in this space and a leader in launching containers which allows you to manage infrastructure as code. I’ve also heard some good comments about IBM’s tools, including UrbanCode and Bluemix.
If you want to get really good at something, do it a lot. It doesn’t matter if we’re talking about mastering the game of golf or mastering our ability to get quality software in the hands of our customers, faster. Think of software deployment as software delivery. A new feature is of no value until it is delivered to production. To get really good at moving a release through various environments, do it daily. To get good at software builds, turn on gated check-ins and build with every check-in. When your team becomes great at software delivery, your developers will actually be spending more time writing code, fixing defects and adding value for your company. They'll be happier as a result and your IT Ops pros will spend more time monitoring applications and less fixing. It all starts with embracing DevOps and challenging the team to improve their craft. Good luck, call if you need help and use the comment section below to add your views.
P.S. If you enjoyed this post, please post a comment below and consider sharing it on Facebook, LinkedIn, Twitter or Reddit.