Of all things that go in to building software, my favorite part is releasing code to production. It’s nice when users can finally benefit from all your hard work knowing that perhaps you made their jobs a little bit better.
And whether you’re building an internal line-of-business website, a downloadable product, or a new version of a SaaS app, performing some post-release maintenance should be a key step in your process.
Ideally any post-release maintenance should be done very early in your next development cycle to ensure anything that might break gets caught well before your next release date. Personally, I prefer to do these things in the first couple days after a release. That tends to be a slower-paced time period before development goes pedal-to-the-metal again.
Below is a number of tasks that should be performed as part of your post-release maintenance. These are .NET-flavored, but obviously would apply to other technology stacks as well.
Visual Studio Updates
Updates to Visual Studio itself are usually few and far between, but don’t forget about your addons and extensions. Take a look to see if things like ReSharper, PostSharp, and Web Essentials have new versions.
For the most part, you should be able to update your Nuget packages without any side effects. Depending on your usage, there might be an occasional Nuget package you don’t want to update, but those are usually the exception to the rule.
Other 3rd Party Libraries
While it seems just about every library has a Nuget package these days, there are still plenty that do not. Don’t forget about your non-Nuget dependencies.
Front-End Libraries and Frameworks
Many people (of which I am one) prefer to manage their UI-specific dependencies outside of Nuget. Things like jQuery, Bootstrap, and Font Awesome are updated frequently and can sometimes cause breaking changes in your app. The post-release time period is a good time to test out their latest versions.
Tag the Release
It’s very important to tag (or label) your released code in source control. This gives you an official source of record for *exactly* what you released and allows you to safely issue patches based on that version. Be sure to tag your source code from the correct location, such as from trunk/master or the release branch, whichever one you released from.
Delete the Release Branch
If you did indeed release from a branch (i.e. a “release branch”), then now is the time to delete it. Once you’ve tagged the release, there’s really no need to keep the release branch around just to take up space. Of course, if you didn’t release from a branch, there’s no branch to delete (don’t delete trunk/master!)
Visual Studio Solution and Project Cleanup
Inevitably you might need some project cleanup. Reorganizing solution folders, consolidating projects, and adding/removing projects is good housekeeping to perform during your post-release maintenance.
Update Build Scripts
Any Visual Studio solution and project changes you make might also require corresponding changes to your build scripts, so be sure to make the necessary adjustments to those as well.
Update Developer Onboarding Documentation
Assuming you have a developer onboarding document (and if you don’t I suggest you write one), now is the time to update it with new tools and processes.
One often overlooked task in the post-release maintenance is cleaning up your development and test databases. These are easy to ignore and keep chugging along, but sometimes you need to get rid of old, irrelevant, bad data or start with a fresh database entirely.
I’ve found that the biggest upside in all this is that these tasks help reduce technical debt. Things like older library versions, unused branches, outdated documentation, and stale test data are time sinks that can lead to bloated code, so it’s best to “weed the garden” on a consistent basis.
Featured Image: All rights reserved by JJSlash04