Blog

All Blog Posts

Reducing Downtime During Custom Software Deployment

Reduce custom software downtime during deployment

As an IT professional, I’ve been used to scheduling deployments in “off hours” (nights and weekends) and babysitting systems as they updated…often slowly. That's the joy of working in outsourcing software development.

Times have changed, and for many custom software systems, there is no reliable “off hour” time. You may have seen alerts from applications you use about upcoming maintenance and downtime, and if you look closely, the timeframes are often in the wee hours of the morning in an attempt to minimize user disruption. 

But off-hour deployments aren’t always ideal—for the companies nor the team members doing them. And now that deployments are happening more often thanks to agile/scrum development, system disruptions are all the more inconvenient for everyone. 

For one of our long-term clients, deployment downtime was getting in the way. Leading Edge Fundraising built Launch, a custom software platform that helps sports teams and clubs run fundraisers. Fundraising doesn’t happen only between 9 and 5, and every minute of downtime could cost Launch’s users valuable fundraising dollars. 

We work in 2-week sprints and often have a deployment to push live at the end of each one. Frequent after-hour deployments aren’t beneficial for the client, and aren’t fair to the Far Reach team members who would have to stay up late (or wake up early) to make them happen. 

So we set out to speed up the deployment process. As with many problems in custom software development, someone else had already worked out a solution to our deployment woes. 


Considering teaming up with a software development team?

Download our guide to help you find the right one.

 


Azure Slot Swapping

In many development workflows, pushing a production update means replacing an old deployment with a new one, which means the system is usually down for however long files take to move. 

But with Azure Slot Swapping, we can set up different environments—for example, our standard “test,” “UAT” (user acceptance testing), and “production” environments—and quickly move between these environments. 

For example, we can have a live production environment that users see as well as a “ready to deploy” environment. In the ready to deploy environment, we can run tests, make sure everything’s working as expected, and even give beta access to select users. Once we’re ready, it’s pretty much a click of a button to switch the live environment to point to the newly updated deployment. 

By preparing the new deployment in a pre-production environment and being able to push it live without moving things around, we nearly eliminate downtime and reduce common go-live issues.  

Slot Swapping allows us to move enhancements and bug fixes between development, testing, and live environments with virtually no interruption for end users. 

For Leading Edge Fundraising, this means students who are fundraising won’t run into system errors as they’re taking orders and processing payments. Coaches can review fundraising goals and progress during “off hours,” a common occurrence given their busy schedules. 

Embrace Change

This client is no stranger to iterating. In fact, it’s a core part of who they are. The company has been through several rebranding efforts as it continues to grow the Launch platform, and like the rest of the world, the school fundraising industry was hit hard by the pandemic

But they’ve adapted. This adaptability is what helps agile/scrum processes work and new platforms scale. 

In this instance, a straightforward enhancement is helping users experience fewer frustrations, the system has less downtime, and Far Reach team members can maintain schedule balance, which for most of us, doesn’t include 2 a.m. deployments. 

Are you looking for a long-term software development partner? Reach out.