Following good practices in the Day 0, Day 1, and Day 2 software development lifecycle can help you create a consistent environment that is easier to maintain. In this blog, we will deepen your understanding of how to make Day 2 operations succeed, and how high performing teams put Puppet to work on Day 2 to make a stronger, less manual, software development lifecycle.
What is Day 0, Day 1, Day 2 Operations?
Within the software development lifecycle, Day 0, Day 1, and Day 2 operations refer to each stage of the planning, deployment, and management of software across an organization.
Using “days” to describe the different parts of the software development lifecycle is simply using a framework to better understand and manage this (potentially very complex) process.
On Day 0, you’ll be defining the requirements of your rollout, deciding which tools you’ll use to support the initiative, and planning the design of its architecture.
On Day 1, you’ll manage all of the steps for deployment, including communicating and testing.
Back to topWhat is Day 2 Operations?
On Day 2 in your software development lifecycle, you will be actively using the tool that you deployed within Day 0 and Day 1 to manage tasks across your infrastructure as planned.
Day 2 is where the rubber meets the road — ongoing deployments, changes, new releases, are all part of the work that Day 0 and Day 1 have enabled. This is also where the highest performing teams reap the benefits of solid process in place to support their ongoing needs.
Day 2 is also a dangerous place to lose vigilance and rest on the success of your initial deployment — communication, putting out fires, and taking on too much work to make large changes are all potential problems that faced on Day 2.
Back to top6 Tips for Successful Day 2 Operations
With the Puppet team’s expert viewpoint (we’re used by 40,000+ organizations!), we have 6 critical tips to help make sure that Day 2 continues to be a success for your organization within the software development lifecycle.
These tips come from a hard-earned place of expertise, helping customers with common issues at all stages.
Tip 1: Small Changes are the Best Changes
Many teams view risk as something to reduce by making fewer releases farther apart, and as a result they end up making much bigger, more complex changes.
The smaller the change, the lower and more easily-managed the risk is.
What we suggest (and it's supported by results from the State of DevOps Reports we've done in the past) is simple — make more, frequent, small changes for less risk and easier rollback. Fewer, less frequent, and larger changes mean more risk and more difficult rollbacks.
Tip 2: Build, Then Follow, a Consistent Roll Out Sequence
The sequence of a release is not as important as following a consistent sequence — by that we mean, you should have a consistent set of steps for every deployment rather than jumping around to different steps and causing inconsistencies each time. For example, most organizations follow the sequence of development > testing > acceptance > production. If you want to follow a different sequence, there is no issue as long as you follow it consistently and avoid random code slinging everywhere across your environments.
The goal is to have one codebase that can manage any of your server environments. You start with a code change in lower environments for testing, and then promote the same code change upward once it's validated. The way you should characterize the number and names of the environments (e.g. dev, test, acceptance, prod) is that which ones you need, and what you call them, depends on business needs and expectations, but the key with Puppet is to figure out what order to go in and to promote the same change through.
Tip 3: Ensure You Have One (Or Several) Canary Nodes
If the canary croaks, something is wrong. It’s important to build a canary node, AKA a smaller place that you can test out your deployment, before it is sent out into production. Adding this as part of your sequence (see above) is a great way to make sure that you’re not handling a much, much bigger problem later. We also suggest having a few canary nodes that represent different important types of server roles.
Tip 4: Build Strong Communication with the Applications Team
Siloes happen — the server team handles everything with the server, the product management team is busy handling product, etc. But in high performing organizations collaboration across silos is key to shortening the time between conception, implementation and deployment. A process, or even code, can support the collaboration between the applications team and everyone else. What does the application team need, like admin privileges, to run their service? What does the operations team need to manage the servers? What does the security team need to maintain the integrity of the infrastructure? What does the audit team need to demonstrate compliance with standards like CIS, HIPAA, PCI, etc? Without strong communication, you’re adding extra work and confusion to an already complicated cross-team process.
Tip 5: Get Smarter About Configuration Management
Manually fixing issues as they arise is one of the key differentiators between high and low performing teams. Using Puppet for state enforcement as an example — when a problem arises and you need to solve it, take advantage of the ability to write the fix once and know that it will stay fixed everywhere you apply the code. By using code to fix an issue, you go beyond just fixing a single problem. That same code can be applied across multiple servers and by design with Puppet it will continue to repair automatically, forever. Just fix it once — adopt a long-term mindset by rolling out supportive code and prevent your team from putting out endless fires for the same issue.
A risk of continuing to follow old manual processes is that, in addition to doing the same work over and over, you'll sometimes end up fighting with Puppet as it puts things back that you're trying to change. When you have some configuration to manage, start by implementing it in Puppet. When there's a problem, fix it in Puppet instead of by hand.
Tip 6: Start Talking to Compliance at the End of Day 2
Day 2 is where you will start using Puppet to configure your other infrastructure. At the end of Day 2, it’s important to talk to your compliance team if you have one and help them understand how to access data that proves you are in compliance. Puppet can help you adhere to the compliance standards that are specific to your industry, and provide a status check every 30 minutes to indicate whether or not you are compliant.
Back to topHow Puppet Supports Day 0, Day 1, Day 2 in the Software Development Lifecycle
Puppet works in tandem with your Day 2 plans by enforcing your desired state and making sure that everything is deployed the way you want it — today, tomorrow, and for as long as you’d like. You can patch, change, and deploy across your environments at scale to make sure that everything is running according to plan.
With Puppet, you can:
- Reduce the manual effort and time it takes to manage infrastructure
- Improve the reliability and consistency of current infrastructure
- Reduce risk by keeping your organization in compliance
Learn more about how Puppet supports Day 0 and Day 1.
You can try Puppet in your environment without commitment with our free demo and see just how Puppet can support desired state enforcement on Day 0, Day 1, and Day 2 of your software development lifecycle.