DevOps is a big term, wide-reaching and applicable to many things that surround and support software development.
For the uninitiated, DevOps can be hard to understand. Is it a culture? A guideline for development processes? A set of tools? Someone's job?
The answer to all these questions is yes. It's all the above.
In this post, we take a surface-level look at the parts that make up DevOps. We explore the concepts, tools, and unique roles.
In modern development, it's more important than ever to deliver software and updates as quickly and reliably as possible.
The concept behind DevOps, then, is about removing barriers that get in the way of software delivery.
Typical barriers include:
The reason to overcome these barriers is simple: If the product is software, then all processes should work towards delivering that software, not against it.
Let's look at what we must consider when thinking about a DevOps approach.
In traditional organizations, developers and those that support them (such as operations or database teams) are often separate entities with little interaction.
This means each team has its own beliefs, responsibilities, and priorities. While not at odds, often those priorities can clash in pursuit of doing the best for the business.
Embracing DevOps as a culture means to remove that friction by introducing a shared purpose.
The methods to achieve that can differ and depend on how entrenched people are in their ways of working. The aim, however, is to ensure all teams:
In DevOps, if you can automate it, you should automate it.
The benefits of automation are simple:
Teams can focus more on the product
Results are repeatable and predictable
Teams can respond much quicker and flexibly to problems
With that, it's no surprise that Continuous Integration and Continuous Deployment (CI/CD) are such a huge part of DevOps.
Given DevOps' conceptual nature, there are many ways for organizations to approach its adoption.
Alex Yates highlighted 2 approaches worth revisiting in his piece On the naming of "DevOps Engineers".
CALMS is a framework explored in The DevOps Handbook.
CALMS is an acronym where each letter describes the actions needed to adopt DevOps:
Culture - Remove silos and share responsibility
Automation - Reduce time spent on manual tasks
Lean - Streamline processes to reduce wasted time
Measurement - Collect and review data to find areas for improvement
Sharing - Open and honest collaboration between teams
CALMS is also the approach Atlassian took on its path to DevOps culture, using it to measure progress and success. You can read how Atlassian uses CALMS on their DevOps site.
Featured in The DevOps Handbook and DevOps novels The Phoenix Project and The Unicorn Project, The Three Ways boils DevOps down to 3 key principles:
Let's take a quick look at what these principles mean.
The First Way is about refining every process that takes place between the developer and the customer.
This means:
The Second Way is all about faster feedback.
Faster feedback means faster reactions, so you can:
The Third Way is about recognizing that it's okay to take risks and that failure is an important part of learning. It's also about communicating the wins too.
By recognizing this, it allows your teams to:
Given the concept is about a unifying purpose, DevOps is really everyone's role. That said, it's still important everyone knows their responsibilities. Adopting DevOps means adding some specialist roles that sit alongside development staples like coders, QA, designers, and more.
Let's take a quick look at some of the common extra roles needed in DevOps and what they do. Some of the naming conventions and finer responsibilities may differ between organizations.
The exact function of DevOps Engineers is often debated. The consensus, though, is that the role exists so everyone else can perform theirs as smoothly as possible.
Both conductor and problem solver, a DevOps Engineer oversees the bigger picture, managing:
The Build Manager maintains the automation systems that make up Continuous Integration (CI).
This means ensuring code gets compiled, built, tested, and handed off for deployment.
A Release Manager directs builds promoted for release. They communicate what's included in a release and plot their course through a pipeline's environments.
This makes up what we call Continuous Deployment and Continuous Delivery (CD)
Product Managers are almost a conduit between developers and end users.
Working with developers, they help ensure the product has the features and fixes customers’ need.
A Data Analyst scours data to spot patterns and find areas for improvement.
This helps you spot the things that impact user experiences, such as feature problems or product navigation.
Most DevOps approaches agree a product lifecycle should look something like this:
Rinse and repeat!
It's important to find the right tools to help you manage each phase. Let's look at a few examples.
The planning stages are the most important for the direction and future of your product. Effective planning helps you focus on the improvements and features users get at the end of the next lifecycle.
Given a lot of that process can get pretty conceptual, there's a range of tools that allow collaboration and project management.
Slack and Zoom are the main tools, but other popular options include:
Source control is important to any development team. Source control tracks and checks every new piece of code and file change.
Most developers use Git for source control. Git is both a system and philosophy, allowing for distributed development and helping avoid risk through branching.
Code repositories, then, are hosting services for Git-managed code.
Popular options include:
Build servers (also known as CI platforms) can save time by automating:
Code compiling
Code validation tests
Package creation
Popular options include:
We spent the first quarter of 2022 deep-diving into Jenkins and GitHub Actions. Take a read and see if they're for you.
Software packaging tools turn your code into deployable artifacts. You host and deploy these artifacts from package repositories.
Popular options include:
Most code repositories and build servers let you manage releases and deploy to targets in some fashion. However, they don't solve the same problems dedicated release management or deployment tools do.
Other popular options include:
Operations relates to the setup, running, and maintenance of infrastructure for a pipeline.
Popular options include:
Runbooks are also an important feature related to operations.
Monitoring tools scrape your product and related systems for important data. This can inform decisions about performance and customer usage.
Popular options include:
Happy deployments!
This article was first published here.