As a reader of anything technical, you have likely heard the buzz about DevOps. You may already be familiar with this concept (in which case you can safely skip this article), but if you’re even a little fuzzy about it or the development culture that has grown up around it, this article should help you understand what DevOps is, how it works, and what it can do for you and your company.

DevOps defined

DevOps is a set of concepts, practices, and tools that promotes the integration and automation of processes and procedures for software development and operations (IT) teams. DevOps enables a software development organization to build, test, and release software with more confidence and greater velocity. Traditional software development methodologies generally partitioned these teams, but DevOps breaks down those barriers and improves collaboration to help development organizations better serve customers and better respond to ever-changing market conditions.

DevOps is not a silver bullet. A change in mindset, a shift in an organization’s culture is usually necessary to build trust and collaboration between development and operations. However, by learning to work together, establishing automation for processes, and ultimately integrating development, build, test, and release processes into a single workflow, these teams can foster innovation and more quickly deliver tested, high-value, high-quality features.

Why does DevOps matter?

In the last few decades, software and internet connectivity have significantly transformed the way businesses operate. The software we create as developers forms the core infrastructure for factories, logistics companies, retail outlets, hospitals, banks, and other organizations in just about any industry you can imagine. As our customers’ businesses grow and expand, the software we provide must do the same to support these customers and make them more efficient. When you or your customers identify an area of strategic growth, the ability to respond to that opportunity quickly and incrementally will enable you to stay ahead of your competition and enable your customers to stay ahead of their competition.

Keep in mind, however, that not everyone will think that faster is better. Managers, operations teams, and developers may have reservations about delivering software more frequently. Can the software be tested adequately? Can it be put through rigorous compliance verification? Can customers be motivated to adopt frequent releases? These are valid challenges to DevOps and require careful consideration. As you work through these issues, keep in mind that fundamentally, DevOps promotes a test-driven development paradigm. For example, to ensure that features are adequately tested, build validation for features as you develop them. To ensure compliance, build automated tests that validate your compliance policy. When interstate or international customers have divergent compliance practices or ever-changing policies, keep yourself in a position to react quickly by expanding automated tests to accommodate the complexity. In all cases, work to build higher confidence in your tests every time you release. And to get customers to adopt more frequent releases, make sure you understand customer pain points, and make sure releases address those issues directly. These efforts will go a long way toward promoting adoption.

Listening to customers and reacting quickly to concerns is key in DevOps. If you lower the barrier to incorporating software releases and ensure that releases continually deliver value, customers will find a way to adopt software releases more frequently.

Common DevOps practices

In addition to understanding the general DevOps mindset, there are a number of specific DevOps practices you should become familiar with. The following practices form the core of DevOps—i.e., the fundamental building blocks implemented by development and operations teams. Mastering these concepts can transform a business and set the stage for rapid growth. Each of these practices could easily be the subject of an entire article, but the following summaries should give you the basics.

Continuous integration

The practice of continuous integration (CI) is one of the most straightforward ways to increase the efficiency of a development team. With CI, code is regularly merged into a central source repository, and builds and testing are automated. This leads to improved software quality by enabling development teams to more quickly find and fix bugs, and it is the first step to more frequent software releases.

Continuous delivery

Continuous delivery (CD) takes CI to the next level. After automated builds and testing, CD processes deploy builds to a testing environment for more extensive testing and then to a production environment once testing is complete. With CD, a version of the software with the most recent changes is automatically staged and ready for release.

Microservice architecture

Microservice architecture is a pattern where business logic is broken up into small chunks that can operate independently. This requires a shift in how developers conceive of and build software, but it makes software easier to test, easier to maintain, and more suitable for CD. If each component of your software can be revised and released individually, you can limit released features to those that you are confident are ready for consumption.

Infrastructure as code

Infrastructure as code is the practice of using configuration files to set up and maintain system environments for development. This can be very effective, even if it is the only DevOps practice an organization implements. The key to this practice is a thorough understanding of build, test, and production environments. Once you have this, you can use a variety of readily available tools to establish requirements for your various environments by setting up configuration files and an archive of installers. Rather than devoting hours of dedicated development or operations time to creating a new development, test, or deployment environment, you can instead instruct your automated processes to create it for you. This practice leads to repeatable, correctly configured environments. Additionally, this increased reliability can be a key element in a good disaster recovery plan.

Monitoring

Another way to increase your ability to react quickly and build reliable software is to actively monitor and log what is happening (uptime, errors, events, etc.) in all aspects of your software infrastructure. By generating thorough metrics that show how the system is operating, and by using tools to analyze and consume that data, a team can quickly determine a problem’s root cause, often before the problem appears to users. As you improve your understanding of monitored data, you can devise alert systems to bring anomalies to your teams’ attention, enabling them to correct issues as soon as possible.

Lean development

Lean development has its origins in agile development methodologies but often coincides with a DevOps culture. A lean software development team is one that seeks to optimize its processes and procedures iteratively throughout the development process. Through team retrospectives, A/B testing, minimal feature rollouts, and making product decisions as late as possible, lean development teams are able to become more efficient and to react quickly to changing market conditions. Lean development embraces the “fail fast” concept, which takes failures and bugs as opportunities to learn and document what does and does not work. By learning quickly from failures, an organization can rapidly improve its processes while improving the features and products it produces in future iterations. Since iterations are frequent, failures have minimal impact to customers and provide you with an opportunity to remedy software issues and build a better product in less time.

How can my company adopt DevOps?

Adoption of any one of these practices is a good first step on the path to DevOps, but usually the biggest change that needs to be made is a shift in culture. Every organization is different, but removing the division between development and operations is a good start. Consider engaging engineers that understand both disciplines to bridge the gap between development and operations or to roll operational functions directly into engineering roles. The goal is to improve the efficiency of development and the reliability of operations by whatever means necessary, enabling the two disciplines to work together to develop tests and automation for more efficient processes.

Empowered developers will often take ownership of infrastructure systems and make immediate improvements to the way that internal operations run, with rippling effects from the way code is managed to the way software is deployed to customers. They may also find better ways to integrate existing quality assurance and security practices into automation to improve the overall reliability of your systems. When you manage your infrastructure as code, developers become a key piece in the life cycle of the product.

The practices outlined above build on one another and can be adopted incrementally. Adopt CI to iterate faster with confidence that changes are tested. Adopt CD to stage builds so that they are always ready for rollout to customers. Use the microservice architecture pattern to compartmentalize software and business functions into individual pieces for separate maintenance and distribution. Manage your infrastructure as code to make systems resilient, repeatable, and well documented. Set up active and accurate monitoring to understand system health and to be alerted to potential bugs before customers are affected. And as a lean development team, use the information from monitoring to turn around fixes and new features rapidly.

The real path to DevOps is available when you open doors and empower your teams with the tools they need to be more efficient. Coach them and guide them along the way, promote collaboration and communication, and let your employees do the rest.