Roll back workflow

I’ve setup an Octpus Server, Tentacle, NuGet feed and deployed a simple web application a couple of times. I wanted to try rolling back to a previously deployed version to see how it would all work. I had 3 versions of the web application deployed to the target server via nuget, with my IIS site pointing at the latest version.

In the Octopus portal, I selected my project, view history and selected the last version I wanted to roll back to, clicked deploy and assigned it to the target server. The deployment was marked a SUCCESS, but the IIS site was not pointed to this version. The log stated that the package/version was already installed. I performed the same steps, but this time I marked the deployement as a forced deployment. The package was re-uploaded to the target server, the IIS site updated, and everything worked ok.

Is the force rollback option the way I should be executing a rollback? I’m a little concerned that when I deployed a previous version without the force deploy option, it was marked as a success, and the dashboard showed that the target server was currently running the previous version, when in fact it was not. As I am the only one doing deployments right now, I can work around this. Even when I open it up to some of the other developers, I can educate them the proper process, but I want to make sure I understand what that process should be.

Hi Adam,

Yes, the force option is the way to do a rollback. If a package is already installed, Octopus will skip it by default, on the assumption that it has already been installed and so you may not want to install it again.

However, settings like IIS would make a lot of sense to restore. Even if a package was previously installed, the IIS settings should still be updated to ensure they reflect the latest installed version. I’ll try to fix this in the next build.

Hope that helps and thanks for asking,

Paul

This issue still seems to be a problem in the current version (1.5.1.1652). If I redeploy a previously deployed release, it doesn’t update IIS to point to the directory for that release.

Is there any reason that it shouldn’t work that way? Selecting the “force re-deploy” option isn’t a big deal, but seems a bit confusing.