Software Development Life Cycle: Day 1 Best Practices
Welcome to Day 1 of the software development life cycle — what now? We’ve already covered Day 0 server provisioning, and you should be ready to start writing code that will support your DevOps initiatives and make your life easier …or are you? Put some of our wisdom and experience at work for Day 1 of the software life cycle, and make sure you’re fully prepared to handle common pitfalls and problems that can become ongoing issues for Day 2.
Table of Contents:
- What is the Software Development Life Cycle?
- What Does Day 1 Mean in the Software Development Lifecycle?
- Day 1 Software Development Life Cycle Do’s and Don’ts
- Puppet’s Role Within Day 1 of the Software Development Life Cycle
What is the Software Development Life Cycle?
The “software development life cycle” is a framework to help define the different phases of software development. In this case, Day 0, Day 1, and Day 2 describe each step for a deployment, including initial installation, testing, and maintenance. The goal of this organization is to make the process linear, efficient, and repeatable.
You might have seen other frameworks for the software development life cycle — different names, different ways to organize this process, etc. But the important thing is to think of these phases, or days, consistently across your organization and add structure and process to a roll out that might otherwise become overwhelming due to scale and complexity.
Some people call dinner “supper,” but it’s essentially the same way of referring to a meal at the end of the day. For the sake of this series, we’re using Day 0, Day 1, and Day 2 as the framework for the software life cycle.
What Does Day 1 Mean in the Software Development Life Cycle?
Day 1 describes the first day within the software development life cycle where the work, and the development, actually begins. Teams can start bringing their initial plan from Day 0 to life and create infrastructure that will support their software.
Day 1 is all about implementation. To provide a Puppet-specific example, this would be the phase within the life cycle where Puppet is installed on your servers and it’s time to “Puppetize” or manage a configuration. You might start writing code for NTP (Network Time Protocol) with Puppet, to keep all the clocks on your various devices synchronized for consistency.
The gates are open, the horses are ready to run on Day 1 — it can be an exciting part of the process to start seeing your plans put into place across an organization and start tackling things that were frustrating, manual, and time-consuming.
This is why it’s so important to follow a strong plan for Day 1 and stick to goals that you set for Day 0. As we’ll explore, it’s easy to try and do everything all at once and end up making mistakes.
Day 1 Software Development Life Cycle Do’s and Don’ts
These “do’s and don’ts” for the software development life cycle come with collective years of experience through Puppet and beyond. Here are a few important things to keep in mind for Day 1.
Break One Thing at a Time
The biggest mistake that you can make on Day 1 is simply taking on too much at once. It’s understandable — even using Puppet as an example, you’re probably ready to address a long list of problems and inefficiencies that have piled up across your infrastructure and become a major problem. Puppet is installed on your server after Day 0 and you’re ready to knock out the whole list at once.
While Puppet can address most of what you’ll want to accomplish, it’s not reasonable to handle everything at once. Start small, pick one project, and see it through to completion.
You can start small by managing something you think that you already have managed, for example. something as simple and small as a login message. Implementing a consistent login message will be quick and easy, but it will also show you how many of your boxes are not currently in compliance. You might have thought you were working with consistency and find just how off the mark you were about something as simple as that login message — what else will you find when you start small?
Don’t “boil the ocean,” just break one thing at a time. As you begin to manage configurations, you will discover the services which were configured in a non-standard way. Some can be made standard to be sure, but often there are reasons for the exceptions. It’s easy to become overwhelmed on Day 1, even with the best intentions and plans in place, if you’re setting unrealistic timelines and trying to implement more than one change at a time.
Follow Recommended Design Practices
Why start from scratch? If you’re using Puppet, the Puppet Forge can provide you with recommended design practices from the start with whatever you are trying to implement on Day 1. From roles, profiles, how you structure your code base, and more — you don’t have to do this alone, and very likely someone has already done it using Puppet in the past.
This can apply to other tools you might be using the software development life cycle to manage — very likely, there are recommendations that can prevent you from making early mistakes.
Communication + Visibility = Better Decisions
Good decision making happens when there is visibility across the entire organization — it sounds like simple advice, but this can be tricky. Organizations often have multiple all responsible for part of the functionality of the same servers. In order to find out who is responsible for a tool or an update, you have to be aware of all the pieces to solve the mystery.
The best organizations have one place where the entire software development life cycle is coordinated. If there are multiple teams managing multiple tasks, those boundaries are clearly established and everyone across the org knows who manages what.
The team that handles a tool like Puppet might come from sys engineering or DevOps — there are a lot of variations in titles and responsibilities to describe the same kind of role. Often, organizations think of a platform like Puppet as something that only one team is responsible for. But even for the sake of having input into design, it’s important to get other teams involved in what is happening with Puppet or any other software you might be using within the software development life cycle.
Using Puppet as an example, here are a few common risks when the designated "Puppet team" doesn't get other teams involved:
- The design can be wrong or limited, because there's something important that they couldn't account for that other teams' SMEs already know.
- It is unclear which component "owns" a specific item on the system and people find out when there's a conflict/overlap.
- The managing team surprises other teams by overwriting custom configurations with corporate standards.
Failure happens when teams aren’t communicating with each other. Either they are duplicating efforts by fighting for the same thing or they are limiting what a tool can do because no one has buy-in to the value of the software.
Another issue is overlap — without communication and visibility, one team might be handling implementation, one might be handling apps, but what happens when these intersect with shared platforms or tools? Day 1 problems, and problems that continue into Day 2, will always be present without strong communication and visibility into the entire software development life cycle.
Don’t Rush Toward Day 2
When are you ready to move ahead to Day 2, or rather, the continued management and maintenance that occurs after deployment? Like our recommendation about not boiling the entire ocean at once, you’re ready to move onto Day 2 once you’re making smart implementations one at a time.
Here’s a checklist to know whether you’re ready for Day 2 in the software development life cycle:
- Is your entire team aware of what you’ll be rolling out — not just the people who will be writing and executing the direct code?
- Is there ongoing communication and visibility of Day 1 work to the entire team?
- Have you mapped out which changes you will make, and in what order?
- Are you following any recommended design practices, or have you done a little research into what those would look like for your desired changes?
“Don’t rush!” is easier said than done — but making sure that each change is properly tested, and managing one change at a time, will make the difference between your life cycle’s success and failure.
Puppet’s Role Within Day 1 of the Software Development Life Cycle
Day 1 is where Puppet goes to work for your organization. With a platform like Puppet Enterprise, you can start rolling out enterprise-wide patch management automation, application delivery, and even continuous compliance. There are an almost infinite number of things you can automate and deploy using Puppet, making sure your systems are scalable and synchronized.
That’s why Day 1 is such a “big deal” with Puppet — you can do so much, it’s important to start with one thing at a time. It’s easy to want to start out Puppetizing everything, but our advice is to start small, just based on experience helping organizations around the world automate tasks and make their lives easier.
Want to learn more about the kinds of things that Puppet can do for you, right on Day 1? We offer a free trial of Puppet with no time limit or commitment, so you can put 10 nodes anywhere and start automating something small or big.