DevOps Implementation in Your Business: How to Guide

Devops Implementation: How to Guide - featured image

You’ve probably read about all the benefits DevOps offers tech teams once it’s embedded…but how difficult is DevOps implementation in a company that doesn’t currently use it?

If you’re the one who has that responsibility, it’s easy to feel under pressure.

The good news is, with some advance planning, a fair amount of hard work, and lots of communication, it is absolutely possible to implement DevOps successfully.

If you put the work in and take it a step at a time, expect skyrocketing productivity gains, long-term cost savings, and happier, more unified technology function – as well as a place in senior management’s good books.

New call-to-action

Why Implement DevOps?

Before you begin, you might be wondering ‘why DevOps?’ and ‘what advantages would a long and potentially expensive implementation project offer me?’

Think of DevOps as an Agile approach to managing the relationship between your development team and your IT operations team. Those silos that exist currently, which hold everyone back, and result in missed deadlines and inter-departmental bad feelings could be made a thing of the past with a successful DevOps implementation.

Organizations that use DevOps methodology can cut their time-to-release from weeks and months to days and (in some cases) hours. It’s hard not to be tempted by that capacity for speed – whether you want to launch your new, groundbreaking product before any competitors pop up, or simply get a bug fix out quickly to resolve customer complaints.

DevOps will save you time and money by shortening deployment time significantly. But your competitors know this too – as more companies adopt DevOps, you’ll find it increasingly difficult to keep up, so it’s best to be ahead of the curve now than behind it later.

Creating a DevOps implementation plan

Because DevOps is an approach to working rather than something more tangible (like a new software tool), it seems like a pretty intimidating thing to try and implement, right?

The good news is that if you keep a level head, devote enough time to planning, manage expectations, and keep everyone in the loop about what’s happening, DevOps is a change you can manage like any other.

The one essential thing to keep in mind is that DevOps will transform how your organization coordinates both its development projects and its IT operations – and this can have a knock-on effect across the entire workforce.

If, for example, you’re adopting DevOps for deployment speed, are your marketers ready for the increased activity surrounding new releases and features? Does your customer service team have the capacity to deal with the heightened levels of customer service requests that come with each feature release?

All of this means that transparency, communication, and teamwork will be key in making your implementation a smooth and successful one. Use the steps below as a framework for managing and communicating this change.

DevOps Implementation Roadmap

 

1. Initial consultation with key stakeholders

What sort of IT landscape are you implementing DevOps into, and what do you hope it will change?

You’ll never know unless you ask the people who know best – your development and IT operations teams. Consult with them extensively, create some focus groups, and schedule some interviews until you have a solid idea of where you’d best feel the benefits of DevOps.

Doing this before creating any sort of implementation plan, project budget, or timeline is a good idea because:

  • No-one knows your existing IT challenges like your existing IT teams. If you want solid, real-world information about current challenges, productivity bottlenecks, and inter-departmental silos, this is the place to start.
  • Your IT teams are more likely to get on board with the project if they see it as a collaboration, rather than something imposed top-down by management because it’s currently trendy.
  • You’ll be able to identify your DevOps needs more clearly, and this could affect the hires you make.
  • You’ll be able to present potential hires with a clearer picture of what you have now, and where you’re looking to move towards.

Remember: both organizations and people (and people in organizations doubly so) are naturally change-resistant. This is the first stage in getting people on board with your DevOps project, so keep it open and encourage as much discussion as possible.

And…keep it celebratory! This is an exciting change after all, so let your enthusiasm show, talk about it with as many people as you can, and run open meetings. Do everything that’s the opposite of hiding away in your office and implementing it on the sly.

2. Decide which sort of DevOps engineers you need

Now that you’ve got the right info, you’ll have a better idea of the challenges you hope DevOps will solve, and the skills you’d be looking for in any new positions you create.

‘DevOps engineer’ is a pretty broad role description – and whilst very good generalists exist, you might be looking for something more specific. This could include:

  • Release manager: oversees the planning, scheduling, controlling, and release of a software build.
  • Automation expert: fairly self-explanatory. The go-to person for all things automation-related.
  • Software tester: responsible for all DevOps-related software testing.
  • QA lead: ensures quality and adherence to standards across the DevOps function.
  • SecDevOps engineer: takes the lead on embedding the appropriate security measures into your release cycle and across all other DevOps processes.

Before looking externally (and factoring in all the costs associated with new hires), investigate whether there’s anyone internally who’d be interested in a change of role. Both software engineers and IT ops staff can make great DevOps engineers, and hiring internally will take advantage of that bank of operational knowledge employees build up by working in the same place for a while. It’s also reassuring, particularly for those resistant to DevOps implementation, to have a sense of continuity to the change.

If you’re hiring more than one DevOps engineer, a good balance is to hire some externally and mix them in with a couple of internal hires. You’ll get both the fresh experience and enthusiasm that new talent brings, and the operational knowledge built up by seasoned employees too.

3. Create a project budget and timeline

Now that you know what sort of person you want to hire, and what challenges you think they can help solve, you’ll no doubt want to shout about the potential benefits from the rooftops.

Before you go all out, however, make sure that you can confidently answer:

  • ‘When is this happening?’
  • ‘How much will this cost, and what benefits do you expect to see from it?’

Creating a realistic, reassuring timeline

Tempting as it is to try and get your project done at breakneck speed, take a step back, and allow yourself time to think things through. If you implement poorly, hire the wrong people, or don’t allow an appropriate amount of ‘bedding in’ time, you won’t feel any of the benefits you’re after.

Your DevOps implementation timeline should include:

  • Time to hire
  • Time to onboard
  • Time to get the function up and running
  • Time to train

Whatever you do, don’t assume your work is done once the new hires have arrived on their first day. People don’t want to be told: “the new hires will start on the 18th March.” They want more detail than that. Rather than milestone dates, divorced from any context, aim for a more real-world approach.

Something like:

“We’ll be hiring over the next three months, with a proposed start date of 18th March. For the first couple of months after that, the DevOps team will be working towards some process improvements in consultation with key IT stakeholders. We’re aiming to have the first of these go live on 1st July.”

You don’t have to give all the details in the world, but you do need to give a sense of planning and purpose. Reassure people that there’s more to it than ‘new hire starts, everything changes suddenly’.

The budget

Your budget for implementing DevOps should cover:

  • The first year’s salary for each DevOps engineer you hire.
  • Hiring costs ($4,000 to $8,000 per hire, depending on which study you read and which hiring methods you use).
  • New software – a new DevOps hire is useless without the tools to do the job. You might already have some of these, though you’ll probably need to purchase others. Don’t forget – more user subscriptions to software packages you rely on day-to-day, like team messaging services and productivity software, need to be factored in as well.
  • New hardware and office equipment. New laptop, desktop, and company phones required? Add those costs here.
  • Any training courses your DevOps hires will need to complete. These costs may be higher if you’re training someone up internally rather than bringing in someone more experienced.

As a quick aside, you should be looking at the following types of software as part of a DevOps investment – for more detail, check out our blog on what DevOps engineers do day-to-day.

  • Automation tools: for automation of your delivery pipeline.
  • Containerization software: contain apps (and their configuration files and libraries) in their own operating environments so they can run across different machines.
  • Configuration management software: allows DevOps teams to configure, manage, and automate your infrastructure.
  • Monitoring software: monitors your infrastructure for issues and helps with speedy resolution of any problems.

Next, think about what you want to get back from your DevOps investment and when you might achieve this. In the long term, a DevOps investment can cut your time to market, increase organizational security, resolve IT issues faster, and result in happier, more connected teams that are easier to manage and more likely to stay working for your organization.

This last point is overlooked far more often than it should be. Remember that there’s a big shortage of IT professionals right now – especially software engineers – so if they’re unhappy, your technical-oriented teams can and will jump ship for something that suits them better.

Then, start to figure out how to quantify this. This will inevitably require a few estimates rather than precise calculations – but you should be able to get to a relatively useful indicative figure here. If there’s any doubt, remember to understate rather than overstate – it’s always better to exceed your promises than to fall short, particularly where justifying it to senior management is concerned.

4. Decide on some project KPIs

One mistake that businesses of all kinds make is that once a change has ‘gone live’ in their organization, they leave it and don’t check back in to see whether everything is running as it should.

Don’t fall into this trap. You’re not implementing DevOps so that it can solve existing issues but create new ones. Identify some KPIs and track them  religiously to make sure you realize the benefits you wanted when you first started the project

These could be:

  • Budgetary: are you spending less whilst doing more?
  • Time-centered: are you getting releases out quicker?
  • People-centered: do your IT teams report being happier and more productive?

There’s no such thing as too much tracking. Keep a close eye, and don’t beat yourself up if something starts to go south. There will be issues (when have you ever worked on a business project that went 100% to plan, 100% of the time?!) – but if you keep your eyes open, you’ll catch them in good time and be able to take corrective action/

You might realize that a lack of experience in, for example, SecDevOps is holding you back, and either make another hire or invest in more training for your existing team. Tracking your KPIs means this small problem doesn’t go undetected and turn into something more serious further down the line.

5. Share your DevOps implementation plan and ask for honest feedback

You have everything you need to share your DevOps implementation plan with the world. The project timeline and budget are researched, realistic, and raring to go. To use a horrendous corporate metaphor, all your ducks are in a row.

Now’s the time to share your plan with the rest of the organization. Don’t limit this to your tech teams – get the whole organization involved!

Remember those departments we mentioned at the top of this article – the ones like marketing and customer service whose working patterns may also change as a result of a DevOps implementation. They’ll want to be kept in the loop too, so run regular drop-ins and stand-ups where you can field their questions, rather than keeping it among the higher-ups.

What to Expect from DevOps Implementation

Increased collaboration and communication

Successful DevOps implementation means increased alignment between developers, engineers, and system administrators. There should be open channels of communication within the DevOps team at all times. This speeds up the feedback loop, therefore impacting a product’s time to market. All of this creates higher levels of trust and understanding amongst your team, resulting in more effective collaboration.

Better performance and fewer software errors

Traditionally, a software team would independently work on singular pieces of code before receiving feedback. With successful DevOps implementation, you can expect frequent releases and granular feedback which reduces the time needed for error-solving. A DevOps engineer’s testing environment is aligned with that of production. Therefore software will be built to work in all environments.

More testing automation than ever

In order to achieve a seamless feedback loop, constant testing is an important aspect of any successful DevOps implementation. Your DevOps team may look to tools for automated testing such as Testsigma, Selenium, or IBM’s Rational Function Tester.

Saving money on product costs

Once your DevOps implementation is in full swing, you should notice saving money on production costs. This is thanks to constant collaboration and communication meaning that maintenance and new product updates are now consolidated into one department.

Increased client trust and improved client experience

As your clients become aware that your products are tested constantly, automatically, and thoroughly, their confidence will increase leading to a better client experience overall.

What Not to Expect from DevOps Implementation

It’s more than just fancy tools and automation

DevOps engineers have loads of specific tools at their disposal to make sure that the DevOps process goes smoothly. Automation tools allow your DevOps engineers to customize and automate your delivery pipeline. But whilst automation is a key element to your DevOps implementation, cultivating a DevOps culture of open communication and feedback is of equal importance.

You don’t need to overhaul your organizational structure

The best way to successfully implement DevOps into your organization is by getting existing staff involved as much as possible. Train existing team members rather than creating a separate department. In order to gain company-wide buy-in, it’s important to be as transparent and inclusive as possible.

FAQs

What is DevOps?

DevOps is a development strategy that combines software development and IT operations. It brings together the two so that organizations can create and release regular updates to their products much quicker than using the more traditional ‘waterfall’ development model.

What is a DevOps environment?

A DevOps environment is one of constant communication and collaboration between developers and operations teams. This environment allows a DevOps team to practice continuous integration, continuous delivery and continuous monitoring and testing.

What is a DevOps platform?

A DevOps platform is also known as ADOP. It is the combination of open-source tools to create a platform that allows for continuous delivery. For many DevOps teams, their DevOps platforms include tools that allow for continuous storing, building, testing, and release of applications.

Is Docker a DevOps tool?

Docker is an open platform software that allows you to package an application with all of its dependencies into a standardized unit called a container. It is a tool designed for both developers and operations, making it a key tool in any DevOps toolkit. Learn more about Docker in our article here.

New call-to-action