How to Build a Bulletproof DevOps Process
A decade ago, if you were to walk into the headquarters of any tech firm, you’d likely find a whole bunch of smart people doing cool things with code. After peeking over their shoulders for a few minutes, you’d also find them all working pretty much independently. The programmers do their thing, send their code to the quality assurance team, and take lunch. The QA team tests for bugs and (assuming they don’t find any), requests that the development team push the code onto the main website.
On paper, that all sounds pretty logical right? Kind of like an assembly line for building websites. If you were to draw it out, it might look something like this:
However, that process is actually severely flawed. These days, most companies have moved away from working that way because it is:
- Time consuming, with a massive delay between initial coding and final deployment.
- Error prone, because programmers work in isolation and not on the final product.
- Expensive, as you need to hire huge teams to keep everything working.
Instead, tech companies today tend to have a more inclusive attitude towards product creation. The idea is to get everyone working together, both the programmers and the development teams. And the best way to do that? DevOps.
What is DevOps?
DevOps started as an idea; the idea that teams of programmers and teams of operations guys could all work together instead of independently. In doing so, the hope was that they could solve all the problems we listed above: quicker time to market, fewer bugs, and cheaper overhead.
With this new and improved way of working, programmers are empowered to test their own code, quickly fix bugs on their own, and easily collaborate with operations departments when they’re ready to push their final code.
This cuts down on the need for large teams and weeks of development time. In some cases, building a great DevOps process can mean that working code can be rolled out in minutes, if not seconds.
The new way of working, the DevOps process, looks like this:
Essentially, everyone gets together, talks about what new features are required, and collaborates on a plan of action. Then, the programmers get to work and develop the new changes. The new code is tested, then deployed on the main server. From there, all the team needs to do is allow users to use (operate) the product. As users interact with it, the team can think about new updates they’d like to include and the whole process starts over again.
This is what’s known as continuous deployment or continuous delivery in DevOps. It’s the new way that tech products are made and, if done right, can help empower your entire team to do bigger things with code.
But how can you get started with DevOps in your own organization? What’s required to create a DevOps process that helps you build better web products? We’re glad you asked…
How to Build a Bulletproof DevOps Process
A killer DevOps process can be built with just three things:
- Lean Methodology
With these three simple ingredients, you can cook up a DevOps workflow that helps you build better products, faster, and with fewer bugs along the way.
How? To start, let’s talk about getting everyone on the same page.
Step 1: Encourage Collaboration From Start to Finish
Let’s say you’ve just finished a meeting with your UX team and they have some concerns about your product. The buttons don’t work the way that a new user would naturally expect them to. Something about it just doesn't feel intuitive and could be the reason why no one is finishing the initial onboarding sequence. In other words, people aren’t using your app because they can’t finish the tutorial.
In the old way of working, this feedback would be recorded and then sent over to the project manager for the programming department. She would have to translate that into something that makes sense to the coders and then get them working on a fix. Hopefully, within a few weeks they’ll have a solution that can be sent to testing.
Here’s the problem: now that the solution has been pushed out, the design department hates the look of it. They want to go back to the old version. After they get their way and everything has been rolled back, the UX team schedules a meeting to ask (as patiently as possible) why their original feedback was ignored. And so on, and so on…
It’s a mess.
In the new way of doing DevOps, every change starts from a culture of collaboration. Anyone with an interest in making your product great (known as a stakeholder) is invited to give feedback on potential changes. Using modern tools, stakeholders can see everyone’s ideas and offer pushback if they foresee a potential problem. In this way, collaboration helps your team only work on updates that provide value for everyone involved.
No more back and forth. No more endless meetings with angry department heads who don’t feel they’re being listened to.
However, collaboration doesn’t stop there. In a truly streamlined DevOps process flow, collaboration should be a key element at every step. Code should be visible to everyone as it moves through each stage so that the entire team is empowered to speak up when they see a problem. This is made possible with tools like Git that facilitate open communication.
In your own organization, look for places that you can encourage more open collaboration between teams. You may need new tools to get everyone on board, or simply look at changing elements of your DevOps culture to be more inclusive.
Step 2: Automate Your Entire DevOps Process
In that hypothetical tech firm from decades ago, you’d have likely seen a lot of manual work going on. When new code is written, it’s manually sent to QA. There, it’s hand-tested by the team and when bugs are found they’re sent back along with a written report. If the code ever makes it through this process, it’s then manually uploaded to the server.
This introduces a lot of problems.
Perhaps the biggest issue is time. Each of those steps requires a human being to oversee and manage it. And each time code is moved along in the process, everything is put on hold while a different human being looks it over and makes changes. If you’re in a competitive market like, say, any market ever… that extra time is expensive.
For the business minded folk, you probably know this as “holding cost”. For the rest of us, think of holding cost as the hypothetical cost of not doing business because your new product is still waiting to be deployed.
That’s why you need to automate the process.
DevOps automation reduces the holding cost of your new products by making testing, debugging, and deployment an insanely fast process. Instead of having a different person at each stage of development, you simply have tools that can test and debug code on their own. When your work is ready to push, an automated deployment process gets it out into the wild with no extra team members required.
As with collaboration, building a fully automated DevOps process will likely require new tools. Fortunately, in today’s world there are a huge selection of tools to choose from. Many will work seamlessly together, helping you move through your new DevOps workflow with ease.
Step 3: Use Lean Principles to Test and Debug
Unless you’ve been avoiding your programming team entirely, you’ve likely heard them mention something about “Lean”. Lean is a pretty huge idea in software development and probably deserves its own article. However, we’ll try to quickly sum it up here, as it relates to DevOps.
Essentially, Lean methodology means reducing wasted time and effort spent on unimportant tasks. These are usually tasks that aren’t helping to make your products more valuable to your customers. Specifically, Lean attempts to reduce wasted time and effort spent waiting (for feedback, changes, debugging, etc.), not publishing work (holding cost), or failing to do things right the first time.
In other words, Lean means emphasizing more value for less effort.
This methodology is a perfect match for DevOps teams because it essentially translates to: collaborate with customers, automate as much as possible, and decrease your time to market.
It also requires that you begin to think realistically about how you’ll handle failure. Far too many websites and apps are created without any process in place for catching and fixing bugs. If you’re going to build a working DevOps process, it’s important that you don’t make this same mistake.
Take inspiration from Lean and look for ways to build “anti-fragile” products— products that are backed up by a rigorous testing and debugging process whose sole purpose is to increase customer value.
Perhaps the easiest way to do this is to ensure your staging environments (where new code is tested) is exactly the same as your production environment (where customers interact with your product). In doing so, you can ensure that new bugs can be tracked and fixed as quickly as possible, before customers ever see the new code.
Again, as with automation and collaboration, there are plenty of tools available to help you do this. In fact, choosing the best DevOps tools is a big part of building a bulletproof DevOps workflow. So let’s take a minute to talk a little about the different DevOps tools and how to find the right ones for you.
Choosing the Right Tools for Your DevOps Process
If you’ve been reading this article and thinking, “Great, but how exactly do I do all of that?…”
Relax. We’re here to help.
We get it. It probably seems a little overwhelming when you look at all the tools available:
Where to start? Which tools should you choose?
Five years ago, you’d have to figure that all out for yourself. You’d have to spend hours looking at different products, comparing features, and trying to figure out which ones are actually worth spending the money on.
Fortunately, in today’s world, there are companies out there that have already done all the legwork. They’re called DevOps Service Providers and essentially they’re like a one-stop-shop for all your continuous deployment needs. The good ones have done their research and built an ecosystem where your programmers can:
- Collaborate with other teams, stakeholders, and each other;
- Write their code openly and easily;
- Immediately test their own work;
- Debug any issues without a QA team; and
- Deploy to production with minimal wasted time.
This means you won’t have to hire three different department heads to manage three different teams. You’ll also empower your programmers, giving them all the tools they need to build their own working code without any micromanagement. What’s more, by working with a DevOps service provider you can help automate just about everything without any extra work on your part.
But whoever you choose to work with, don’t forget to stick to the three core elements of DevOps: Collaboration, Automation, and Lean Methodology. The provider you choose should offer an environment that supports these three principles above all else.
By sticking to those three principles, you’ll be well on your way to building a DevOps process that supports your development goals. Now all you need to do is figure out what you want to build!
If you need more information, please feel free to contact us >>