It’s common to focus on the immediate problems that you’re facing when standing up a new project or server. But what about the next time that you need to perform that process? Will you remember all of the steps you took?
That’s where repeatability comes in. It might not feel like a priority. Until it is. With application development, repeatability addresses inconsistencies in server environments and data that can quickly spiral.
Repeatability provides a high level of consistency in operations. In math and computer science, this is described as idempotent. When an operation is said to be idempotent, it means that there is a form of consistency that when you perform the same action, you can expect the same result. The operation can be repeated as often as necessary without causing unintended effects.
There are many reasons to insist on repeatability in your development process, but the bottom line is that taking the time upfront inevitably saves you a lot of headaches down the road.
Conveying the value of repeatability
Gaining consensus for repeatable processes can be challenging because someone often needs to be burned by it in order to fully appreciate it. It’s especially common when developers haven’t worked on projects through a long-term life cycle. In school, for instance, they’re typically working alone rather than as part of a team. Once a project is complete, they typically don’t think about it again.
But when it comes to applications in the real world, there’s no such thing as “completed.”
Applications are intended to live on for years — or even decades — and they will require maintenance and updates. As requirements change and team members come and go, the need for repeatable processes grows.
The best time to establish repeatable processes was yesterday, but the next best time is today.
Creating headaches or avoiding them?
Repeatable processes help you avoid headaches that can become nightmares. Consider this example:
- Suppose that you need to stand up a Dev environment for a new web app.
- Suppose that you discover that you need to switch to a new hosting provider because the old one is no longer supported.
- Once you get Dev set up, you’ll need to create Staging and Production environments.
If you configure the Dev server manually but don’t write down any of the steps that you took, you’ll have to reconstruct what you did. And while that might not sound too difficult, there’s a good chance that you’ll run into lots of errors. You might not remember which packages you installed or dependencies that you came across. And pretty soon, you’ve created another headache for yourself.
Consider another example:
- Suppose once again that you’re standing up a new Dev environment, but this time you’re doing everything manually because you think it’s faster.
- You install everything on an ad hoc basis and when you try to run your server, you get an error.
- You start installing packages, but the first one doesn’t work. You try another one. That doesn’t work either. You run a few commands to configure the server. Still nothing.
- You keep debugging to work through the series of errors, making adjustments along the way. You finally get everything to work. The only trouble is that you’re not exactly sure which set of steps got things working!
- You move on to stand up your Staging server, but you forget just one step along the way, and now your environments aren’t mirroring each other.
- The project gets prolonged to the point where you don’t stand up your Production environment for months. By that time, one of the packages that you’ve installed on Dev has a different version. The incompatibility isn’t obvious at first, and now something is broken in Production.
- You try to diagnose the error, but your Dev environment doesn’t have the same problem.
What started as a “time saver” became a major challenge in production with no easy road to fixing it. It’s more than a mismatch. It’s time and money chasing bugs and potentially affecting your business.
You can reduce the chance of these types of headaches by insisting on repeatability, and then implementing a robust DevOps program.
Insisting on DevOps
Development Operations, more commonly known as DevOps, is another part of the answer. It’s a framework of practices and processes for software development and IT operations. The part that applies to repeatability has to do with your infrastructure. DevOps standardizes, optimizes, and automates many of the processes required to manage your server operations.
When you insist on repeatability, DevOps takes it to a whole new level with robust toolsets that greatly reduce the chance for errors. You can define your infrastructure as code that drives all of your installations, configurations, deployments, and provisioning. When it’s time for an update, your code is versioned, which allows you to change a line of code rather than log into a server and dig through commands. When it’s time for a new server, you can stand it up and be confident that it’s configured in the same way, down to every detail.
Solving it: DevOps Software Tools
Today’s DevOps tools are more robust than ever, and they can significantly improve your ability to implement repeatable processes.
Following are some common provisioning tools:
- Serverless – An all-in-one development framework for auto-scaling apps on AWS Lambda.
- AWS CloudFormation – A DevOps management tool that lets you model, provision, and manage AWS and third-party resources by treating infrastructure as code.
- Chef – An automation stack for continuous delivery of secure applications and infrastructure.
- Ansible – An open approach to automation to deploy better applications faster.
- Kubernetes – An open-source system for automating the deployment, scaling, and management of containerized applications. Kubernetes monitors your traffic and resource load and spins up multiple versions of your app as needed. This helps your server not to crash and it’s especially helpful if you don’t have the resources available in your cloud environment to do this yourself.
Repeatability is good. Automating repeatability is even better. These tools and others like them help you avoid many nightmare scenarios.
If your organization struggles with mismatches or inconsistencies, there’s good news: You can develop a process of repeatability at any time. You can begin with small steps such as implementing one of the provisioning tools mentioned above. The sooner you start, the more it pays off down the road.
Remember: It’s worth taking the time upfront to do it right. Take the guesswork out of it. Insist on repeatability, and insist that all of your vendors and partners do as well.
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
Jared builds innovative healthcare brands through digital strategy and engaging content that turns heads. He is a keynote speaker, prolific content creator, host of the Healthcare Rap podcast and author of Connect the Docs: Put Digital Health Into Practice.