As part of my ongoing attempts at continuous improvement in our deployments, I’ve started using TDS 5.5’s ability to use custom post deploy steps so that we can tackle common annoying deployment issues. Today, we’ll learn about the File Remover!

The Problem

Over the course of a project, things get refactored. It’s just a fact of life. Typically, however, this leaves orphaned files. Lonely little CSHTML views and abandoned config files that just sit on the servers, requiring manual intervention to remove them. A server here or there is no problem to manually update, but when you start talking about dozens of servers that need manual fixes to remove files in all sorts of locations, the human error factor starts to become too much of a risk. 
 

The Solution 

The File Remover has a very simple job: it removes files! You give it a pipe-delimited list of relative paths that are in the web root that you want gone and it will look for them and clean those out for you. No more wondering if that renamed CSS file is still sitting on the server. Configure during development when you make the change and the deployments will take care of that!

TDS Post Deploy Steps -The File Remover

Installation and Usage 

I typically recommend that this script run for all configurations. You want this cleaning stuff out everywhere, that’s why you are installing it. The example instructions from Hedgehog will show you how to add a deploy step to your TDS project. Installing the File Remover for all configurations is slightly different. On the wrapping ItemGroup, instead of specifying a Condition, just leave it blank. 

You can see an example TDS project in the GitHub project for the script

What you’ll see in the logs 

When the File Remover runs, it will log any files it attempts to remove and inform you whether the file was found or not and whether it was able to successfully remove it. 

TDS Post Deploy Steps -The File Remover


comments powered by Disqus