February 22, 2023

DevOps Best Practices – How to Get Started When Nothing Works

DevOps

By

When DevOps tools fail or stall, DevOps best practices swoop in to save the day and help you refocus on what matters: the mentality, the culture, and the working patterns within your team or your organization.     

Table of Contents:  

What Are DevOps Best Practices?     

DevOps best practices are an encompassing framework of a mentality, rather than a set of tools, that can help move your DevOps goals forward when put in place across the entire Dev team.     

Puppet is a hugely popular infrastructure automation with a ton of DevOps capabilities and use-case potential — but it takes great people, all aligned behind a single goal, to use tools like Puppet to make DevOps happen.     

Good tools have always been around within the DevOps space, but that doesn’t mean that IT teams are using them to their full potential. The problem starts at the very foundation of DevOps, with fundamental process issues for continuous integration and continuous deployment (CI/CD).     

We’ll use the example of a bank that used Puppet, with a large team of employees and sensitive user data handled every day. For this large bank, their “center of excellence” for testing was used exclusively by the mainframe teams. We just assume that like software companies, other organizations are set up with the proper tooling and concepts to handle testing and other key DevOps functions – this is not always the case.     

Another common assumption is that DevOps developers are always from a Dev background, when often they come from the Ops background and find the terms and tooling new or different than what they’re used to. If everyone is speaking different languages, the barrier to success is high.     

This is where DevOps best practices come into place: to start building the proper foundation before problems begin.     

Understanding Models vs. Tools vs. Mentality    

If we look at organizations that are following DevOps best practices, have great security hygiene, and in the case of Puppet users, are ahead of the game for automation: what do they have in common?     

Putting aside the tools they have in place, how are different roles supporting developer roles from the very beginning? It takes a different mentality to provide developers with clear instructions on what tools they should be using, and how they should be testing and verifying their code before it goes into production.     

There is ownership at all levels to ask the right questions of themselves, and on behalf of their DevOps team, before code begins.     

Developing the Right Mentality:    

For Tool Builders: What does "crawl → walk → run" look like for your users? What level of sophistication do you presume already exists on a team before your promising new tech can make an impact?   

For IT/Ops Leaders: How are you making space on your teams to improve and automate more things? If you can’t “hire your way” out of issues, how can you better train your people? Improvement takes both time and an appetite for change.    

For Hands-On Ops: Chances are good that the infrastructure environment you manage is probably "target rich" for automation. What manual activities are taking up the bulk of your time? Are there any low-risk areas in which you can start implementing new, automation approaches?    

Building a Standard Framework for DevOps Best Practices    

Once you’ve started asking the right questions, you’re ready to build a standard framework for your developers to follow. Standard best practices and patterns give developers confidence in their own application teams to develop, test, and release their own code.    

What is important to developers? A strong framework helps them understand:  

  1. How they should develop  
  2. How they should test  
  3. How they should deploy    

Developers often struggle with testing their pipeline, which represents the steps that happen when you release a code, and the number of steps that need to happen in sequence.     

Standardized frameworks, created from the ground up, can help create a pipeline that is strong and repeatable. Does your development team start from a set of clear instructions from the start? Is the pipeline for deployment standardized, documented, and shared? Do other parts of the business, like change management, have visibility into the pipeline?     

Defining DevOps Best Practices for Your Unique Needs    

Another aspect of the standardized framework — and pipeline — is giving developers the ability to deploy and test when they need to. This is an opportunity for leaders to relinquish control of manual processes.     

Let’s use the example of Continuous Delivery for Puppet Enterprise (CD4PE). This tool steers organizations away from the need to have a central team that “owns” Puppet. In the past, this central team would control the green light for testing and deployment. This green light is, by its nature, manual. Developers have an extra step before they can begin to release code.     

Within CD4PE, developers have freedom to test and deploy using Puppet Enterprise without siloes between the central control team DevOps. This is because the DevOps workflows are built into the tool, and there is automatic visibility into how the changes will impact the environment when made.     

Aside from solutions like CD4PE, how can teams who manage which projects are greenlit for testing and deployment give back some of that power to DevOps?     When things are stuck in production, or backlogged, or larger initiatives and “pie in the sky” projects just aren’t moving forward — maybe it’s time to look holistically at the entire framework. Who are the people who are making decisions on behalf of DevOps, and are they the right folks for that job?     

If you’re working with Puppet Enterprise currently and want to dive into how a solution like CD4PE could help with your strategic framework, don’t miss our additional resources and reading on the topic:    

Learn more About Continuous Delivery for Puppet Enterprise    

David Sandilands

Senior Solutions Architect

David Sandilands is a senior solutions architect.