Milestones to DevOps Integration

The challenge that every business constantly faces is how to remain relevant to its customers. In a world where changes are happening around us at breakneck speeds, the tools we create and support as development teams need to be cycled faster and more efficiently than ever before. While there are still some legacy applications that see updates quarterly or annually, those days for nearly all of us are well in the past. Now development lifecycles are typically measured in days, hours, and even minutes.

For development organizations that are not yet using these expedited development lifecycles, the challenge is significant, and it can appear as though the chasm for adoption is growing and that the rest of the development world is leaving you behind.

Fear not. Regardless of the size or complexity of your organization, there is a path that will get you up and running on the DevOps road.

When looking at DevOps from across the chasm, the list of reasons to delay the migration can be easy to justify. If nothing else, then for the reason that status quo is just easier to manage. Other common justifications may include things like an unknown, or unproven ROI, lack of management support, or an incompatible culture. All of these things have been discussed and answered in various articles. For example, for anyone interested in learning about the ROI of a DevOps migration, David Linwood wrote a highly recommended article titled Which metrics assist in DevOps proving its ROI?.  And as Matt Werner recently discussed in his article DevOps: Culture and Process, the issues regarding a lack of support from management, or an incompatible culture, continue to decrease.

So regardless of whether the timing is perfect now or sometime in the future, this article should provide some valuable insight into where to get started and how to cross that chasm.

What would DevOps look like for us?

There is no one DevOps model to point at and say, this is what you can expect. It will be different for every business and every team. It’s the essence of methodologies and principles that can be applied and adapted to your organization’s specific needs. Because every organization has different needs, cultures, models, and environments, no two implementations will ever be the same. We can only look at what others have done and get ideas of what we can do and might be able to accomplish within our own organizations.

However, you need to know that DevOps is simply not the end-all solution for every single product and every situation. There are some scenarios where DevOps implementation may not be the right solution to improve efficiency. That said, you will likely be able to pick and choose bits and pieces of what others are doing and apply them to your organization. Make sure you’re realistic in your goals. We shouldn’t point at DevOps case studies and say, “Why try? We’ll never achieve that.” When in reality these case studies are to be used as motivation to help us see the possibilities. This is similar to the way we look at pictures in a magazine to get ideas of what might work for us.

Where to Start

At the onset, we need to be realistic about our goals and expectations. These changes will not result in rainbows and unicorns overnight. The migration to DevOps is a journey, not a destination. It’s important to recognize that all those processes and successes we read about in DevOps case studies happen because they found a starting point, took the first step and are now further along down the DevOps road. And like every other organization running DevOps, they continue to make iterative changes and enhancements to their processes and model as they go.

So now to get you on that same road to DevOps success, all that’s needed is to take your own first steps. These steps will give you a good framework to start with.

Identify a Starting Point

The easiest path to DevOps is to identify a starting point. Pick a specific project or project team and use them as the pilot program. Identify what works and what doesn’t. Make iterative changes as needed till it’s running smoothly. The things that you will want to pay special attention to are:

1. Processes – With the implementation of any type of changes, it’s important to identify what the processes should look like once the change has been made. This is no exception. At a minimum, you should define a starting point for what those processes need to be and then plan to make iterative changes to continue to improve upon them as you learn what works and what doesn’t.

2. Metrics – It’s important to be able to point to some form of metrics to show if your DevOps changes are leading you in the right direction. You will need to start with a set of baseline metrics to measure what things were like prior to your DevOps changes. From there, you can further use these metrics to enhance the process along the way. Preexisting metrics and KPIs may not directly carry over to a DevOps development environment. So, some thought should be given to identify new metrics to support the key objectives. These new metrics should be focused on key business objectives, development agility, issue resolution efficiency and the customer experience.

3. Product Quality – The measurement of quality is really nothing more than measuring the absence of issues. So, to effectively measure the improvement of quality, you would need to have sufficient baseline data of some sort to show the number of issues before DevOps implementation. This can include the number of issues per cutover, reported issues per month, or any number of other related metrics.

4. Communication – It’s important to have good communication throughout an effective DevOps environment. This ensures that when coding changes are made, the new code doesn’t sit idle, but that it immediately moves to the next stage in the DevOps lifecycle. The other part of communication is in providing transparency to what is happening throughout the team. With so many iterations of code being worked on at various stages of the lifecycle, it’s critical that there is a way to easily track and report defined KPIs.

5. Accountability – This is something that will vary greatly from one organization to another. Because the Continuous Release methodology is about using smaller code segments, or modules, for each release, this allows each developer to specialize in their own respective modules of the application. So, when a problem occurs in their assigned modules of the code, they can be held accountable for it and manage the quick resolution of issues that arise.

6. Customer Experience – The litmus test for any development team can be measured in the customers’ experience. This can be determined by any number of quantifiable metrics or even satisfaction survey questions such as: Do they like working with the team when issues arise? Do they feel the issues were addressed in a timely manner?There are a number of questions that could be asked, but the key thing is that the interactions that they have with the development team improve once the DevOps methodology is implemented. From there, it’s a matter of iterative improvements as the processes are further refined and bottlenecks are identified and eliminated.

Start with the Right Team – To kick off a DevOps pilot program, it’s important to start with the right team. Here are some things to consider when selecting the right team.

1. Willing to try new approaches – While this team will eventually become your DevOps flagship, the early stages of transition could be a bit rough. They will need to be flexible and willing to try new things that are different to what has been done in the past.

2. Work well in cross-functional teams – Part of the DevOps model is the ability to effectively operate in cross-functional teams. Each DevOps team can consist of developers, testers, operations, and other areas as is appropriate within your organization. With each of these different areas of responsibility, they will need to work both within and outside of their organization to make sure that the team is properly aligned with the greater organizational goals and objectives.

3. Willing to challenge traditional thinking – As with any new organizational change, in order for things to improve, things must change. Because every organization is fundamentally different, it’s impossible to implement off-the-shelf processes and expect them to work. This is where outside-the-box thinking is needed. Ideally, this should be a collaborative effort, with regular input from the entire team to identify issues and bottlenecks and create solutions to improve the process. This is hands-down the best way expedite the transition process.

While in smaller organizations this DevOps transformation might be a smooth standalone effort, larger organizations will require additional thought on how to effectively integrate with and meet the needs of existing functions and methodologies like ITIL, Enterprise Architecture, Security, Compliance, and others. Depending on the level of controls, interdependency and their pliability, some of these will have easier solutions than others.

Microservices – This is not necessarily a requirement, but it’s certainly something to consider as you identify where to get started. Microservices is defined as the compartmented management of different segments of the complete solution. For example, if you have an e-commerce website, one microservice might be the transaction itself, another might be the shopping cart, and another the wish list and so forth. Each Microservice team functions as a standalone product team, managing every aspect of their respective function including coding, testing, design, database, delivery, etc.  Depending on the organization, the adoption of using Microservices could simplify and expedite the migration to a DevOps model.

Automation and Management Solutions are Key

The goal of having a successful transition to DevOps is to make it sustainable. You will need to see enough of a benefit in your measurable efficiencies to justify continued efforts in the migration process. The key to making these changes sustainable will be in integrating various tools to automate key elements of the lifecycle to improve efficiency. Areas to consider automation typically include testing and code handoff, though your organization may be able to see benefits in other areas as well.

Another area in which you’ll see significant gains in efficiency is in the adoption of lifecycle and methodology management tools. Here are a few to consider:

1. Test Automation Tools – Depending on the type of application, the environment, and the type of testing needed, there are likely dozens of available solutions. The one thing to keep in mind is that you will want to make sure it’s a solution that will not only work with your application and environment but will also scale appropriately for your organization.

2. Test Management Solutions – Depending on your type of coding, there are a number of tests that will need to be run, tracked, managed and communicated. The challenge is to find a good test management solution that works on an enterprise scale. Management of test plans, direct integration with thousands of the most popular testing solutions and test automation tools, diverse methodology support, audit trails, advanced reporting, and status clarity are just a few of the features to look for.

3. Release Management – The backbone of any smooth-running DevOps initiative is a solid solution to effectively track and manage code throughout the release process. Plutora Release manages every detail of every release, regardless of the frequency of releases, number or location of teams, or the diverse methodologies used. This will allow you to track every detail and provide stakeholders with amazing clarity for real-time status and issue management.

4. Environment Management – Testing is good, but if it’s not tested in an environment that is similar to the production environment, it really doesn’t matter how well it was tested. The challenge is to create a test environment that effectively mimics the production environment when your production environment is highly complex, with hundreds or thousands of interdependencies and unique variables. While there may be a handful of solutions available, Plutora has a solution designed for just such a challenge, and it’s amazing.

5. Deployment Management – When a new code release is ready for production but the update affects critical operational services, you have to get it right the first time. How do you do this when the deployment effort involves planning, collaboration and coordination with dozens of teams in a variety of locations? The answer once again is Plutora. Plutora Release is an enterprise solution designed for the enterprise. It’s the solution that manages highly complex, ultra-secure, and mission-critical cutovers with ease. It also provides improved team collaboration tools, reliable auditability, improved deployment efficiency, and real-time status visibility to all stakeholders. For increased DevOps efficiency, Plutora is well worth a call.