In order to communicate with the Octopus Deploy API you will need an API key to authenticate with.

It is a good idea to create an account in Octopus Deploy for your Continuous Integration systems (eg: TeamCity) - and then generate a new API key for that account, that can be safely used from within your build process.

Octopus Deploy relies on the concept of a release, which should be an immutable NuGet Package which has been built, tested, packaged and published from your Continuous Integration systems - which you can of course completely manage with your FAKE script.

So once you have created a project you are able to create and push a release into Octopus Deploy. This can be done through the Octopus UI, command line tool, or in our case - from a FAKE script.

In this instance both the releaseOptions and octoParams contain assumed default values that will fail by default. CreateRelease allows you to also deploy the release at the same time, but since we're not interested in doing this at this moment - we'll set our deployOptions to None.

You can automatically deploy a release when you create it, but using the optional deploy options when you create your release.

This is often a good idea when you want your FAKE build script to continue on to a second set of perhaps slower, unit tests that exercise behaviours in a more complete and perhaps integrated environment.

Finally when you are absolutely happy that your release is good to go the next stage (be that some manual or exploratory testing, or perhaps a staging environment). We can use a DeployRelease command to promote an existing release to the next environment: