The buzzword to end all buzzwords: “DevOps”. It’s a term that’s taken the software industry by storm over the past few years, but even with the popularity of the term, there are a lot of unknowns around what it even means. Let’s explore what it is, why it matters, and how it can transform your team and organization.
What is DevOps?
At its simplest, DevOps is a set of practices and strategies to automate software development and manage the operations around it. DevOps aims to change the culture around how software is developed in order to promote efficient and effective cycles. This can be in the form of automated builds, testing, or releasing software into various environments, among many other things.
Even though a major catalyst in a DevOps pipeline is the technology running the show, it’s just as much a cultural shift as it is a technical implementation. Whether it’s getting your team onboard with new processes such as branching strategies and pull requests to manage your source code to no longer doing manual deployments, the team’s culture must be ready to adapt to these changes.
Why Does it Matter?
Just like we continue to develop software to meet the needs of our product owners, stakeholders, and clients, software developers can also be a stakeholder of their own development process. Every efficiency added into our development workflows has a net benefit to the end product, including:
- Reduced time doing manual testing
- Minimized risks from a production release by having reproducible releases and known artifacts from a standardized build
- Being able to tie live monitoring and analytics against the application
- Better planned optimizations within the system that we’re building
By reducing the overhead required to manage the development process, the more time we can spend writing meaningful code!
How Do You Start?
The DevOps pipeline can be broken down into five tiers. Each of these tiers can be evaluated, analyzed, and built-out separately. But, ultimately, the goal is to unify them into one well-oiled machine. Identifying what the tiers are, as well as what potential changes can be made, can turn an organization that has never used a DevOps process into one that is fully automated through the entire pipeline.
1. Planning
Before work can be done, work needs to be defined. DevOps goes hand-in-hand with agile processes, including Scrum or Kanban, to help define the work that needs to be done. Having a solid work definition and prioritization strategy can help ensure that the feature you’re working on is the right one.
2. Code and Data
Source code is the lifeblood of an application, and as such, we should do our due diligence when managing it. Implementing source code management strategies, such as branch policies and peer review via pull requests, can greatly increase the quality of code – as well as the quality of the application.
Data is equally as important as the source code, though it often goes without as much care. Building data management strategies into your application, like managing your database schema as code or introducing data migrations to safely upgrade your data and datastores, can increase the integrity of your application and user data.
3. Build and Test
One of the first areas often explored in DevOps is the build process. Automating the building of source code and managing the artifacts of the build are often an “easy win” when starting the DevOps process. However, there is more that can be done!
Pairing an automated build with your code review process can validate that the code will integrate into your master or trunk branch before doing the actual merge. Adding automated unit testing into the build process can catch a bad build before it even sees an environment.
4. Release and Deploy
Once artifacts have been built and are ready to move to an environment, the release process of your application can be analyzed. This may be as simple as copying assets to a web server, deploying your database-as-code to a database server, or releasing a mobile application into App Center or other app stores.
As part of the release process, other activities can be introduced. For example, after releasing to a QA or User Acceptance Testing environment, automated integration or load tests can be executed to ensure application and data integrity – as well as ensuring that acceptable performance levels are continuing to be maintained. This can all happen before reaching a production environment, minimizing potential risks before a live user ever loads a page or updates to the latest version of your app.
Introducing other methodologies, such as infrastructure-as-code and container orchestration, can improve release scenarios by managing the destination infrastructure to be in a known and reliable state. Automated data replication or syncing can also be integrated to bring production-like data into your test environments to have more realistic testing and load scenarios.
5. Monitor and Analyze
Once the application has made it to production, keeping an eye on how things are going is vital in reliability and down-time mitigation. By monitoring key areas of your application to ensure that up-time, performance, and data integrity are maintained, you can be proactive in addressing any potential issues.
Introducing analytics can show actual use case scenarios, as well as real user performance of the application. Taking real metrics can help determine which area of the application could use future development via new feature or tackling bugs or performance issues.
Back to Planning
Once the application is live and being monitored and analyzed, now isn’t the time to stop! It’s time to start thinking about the next features and how to continuously improve the application. This doesn’t even need to wait for one feature to finish; in a well-oiled workflow, continued development-through-to-release can be done in parallel.
