Making unfold build your application locally

By default Unfold performs almost all operations on the target machine of your deployment. This means that the checkout from source control, the building of the project and the creation of the release folder for your application all happen on the remote machine.

The pros and cons of remote builds

This approach has quite some benefits:

• you're sure that all dependencies are satisfied on the remote machine. Sometimes a local build can trick you into thinking that your application runs just fine, but once you start running on a remote machine it appears that assemblies are missing.

• Only the source control differences need to be fetched over the network in order for the target machine to contain the last version of your code. That way we don't have to send the entire application across the wire each time we perform a new deployment.

• Because there's less data to be sent over the network, deployments can happen faster.

Of course, there are also scenarios where performing the build on the remote machine simply isn't possible or wanted.

• Does the deployment server have access to source control? Because unfold takes your code from source control, your deployment target needs access to your source control server. In case of Git for example, you need to set the ssh keys. It also might be that your source control server sits behind a firewall and is simply not accessible from the deployment machine.

• Do you depend on SDKs? Microsoft sometimes makes it particularly hard to build an application on a machine that does not have Visual Studio installed. Especially when depending on SDKs you can run into trouble. It's crazy, for sure, but unfortunately it is a problem that we need to handle for our deployment scenarios

• Do you want the deployment server to access source control?: Maybe you just don't want to give your deployment server access to source control, for whatever reason. No problem, simply switch to local builds.

Switching to local build

Luckily, making Unfold perform the checkout + build on your local machine is very easy. As can be expected, the configuration happens through some Set-Config calls. Two to be precise

Set-Config localbuild $true
Set-Config localbuildpath "c:\path\to\a\local\checkout"

That was easy.

When these two configuration variables are available, Unfold will take the following approach when deploying:

• The source is fetched from source control on your local machine, in the localbuildpath to exact.
• The build is executed on the local machine
• Next, we create the release on the local machine as well.
• Finally the output of the release task put into a zipfile, and that zipfile is copied over the PowerShell Remoting Session, towards the remote machine where it is extracted inside the basePath configuration variable.
• From there on, the normal deployment behaviour can take over again, as all we need to do now is setup the remote machine to use the new release we created.

Conclusion

Unfold makes it easy for you to configure where the build and release of your application needs to happen, all that's needed are two configuration variables.

Whether or not you use the localbuild scenario depends on the following considerations

• Does my deployment machine have access to source control?
• Do I need build dependencies that are not installable/available on the deployment target?
• You just don't want to setup your deployment server to access source control.

Once you've take the decision, the switch is easy.

How Unfold handles rollback

Rollback should be an important aspect of any deployment solution, simply because we tend to mess things up. There are a lot of things that can go wrong, and sometimes you only realize something is broken when the code is already running. Yes, yes, I know, my tests should have full coverage, I should perform user testing on different environments, and my code should be peer reviewed. But even then things can and will go wrong, there's no escaping it.

And when that happens, you find yourself saying: "If only we could revert to the previous version, until we fixed this problem". Well, Unfold is here to help.

Listing the possible versions

As we explained before Unfold keeps old releases around for some time. By default, it keeps the last 5 releases. Before you execute a rollback it's best to check exactly what releases are available. To do so, simply issue the following command in a PowerShell:

.\unfold.ps1 listremoteversions -on dev

The listremoteversions task does nothing special, it just checks which releases are available on the deployment target and prints them in PowerShell the console. The output looks like this

These releases are what is available on the deployment target. The first part of the folder name is the timestamp of deployment, the second part is the short hash of the revision is what deployed from. The number that are in front of the folder names (01, 02, ...) is what we'll use when executing a rollback.

Executing the rollback

Now that you've picked the version you want to rollback to, you can perform the rollback. This command for example will rollback to the third release - on the dev environment:

.\unfold.ps1 rollback -on dev -properties @{to=3}

In short, this will execute the rollback task on the dev environment. The rollback task however, needs a parameter. It needs to know which version to rollback to. For parameters we depend on the properties system of psake, for full documentation check this page.

How rollback works

In a previous post we have explained the default tasks that together compose a deployment. Basically there are two major parts to this. The first part is getting the last version of the code from scm, building and releasing it. The second part deals with setting up IIS and configuring the application.

In this rollback scenario however we don't need to perform the first part. Also, because our system uses psake tasks we can simply re-use those tasks in the rollback flow. As a consequence any task hooks that are attached to - let's say - the setupiis task, will also be executed during rollback, making sure that also your own customizations to the deployment flow will be applied when performing a rollback.

Conclusion

You have now seen how Unfold handles rollback. Rollback is made easy because of two reasons:

• we keep older versions around. Because we do so, there's always something ready to rollback to.
• because we use psake and have split the deployment into several smaller tasks, we can re-use a lot of logic and skip the parts we don't need.

Rollback is now a matter of seconds and very trivial to perform. So go on, mess things up.