From aba1b5dd48b56247b6b3490018cd2bab785c557e Mon Sep 17 00:00:00 2001 From: James Crowley Date: Fri, 13 Jun 2014 11:39:56 +0100 Subject: [PATCH] Fix namespaces of imports --- help/octopusdeploy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/help/octopusdeploy.md b/help/octopusdeploy.md index e7b3e2e3a1c..52e854181b7 100644 --- a/help/octopusdeploy.md +++ b/help/octopusdeploy.md @@ -30,7 +30,7 @@ Octopus Deploy relies on the concept of a **release**, which should be an immuta So once you have created a project you are able to create a 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. - open OctoTools + open Fake.OctoTools Target "Release" (fun _ -> let release = { releaseOptions with Project = "Order Processor" } @@ -52,7 +52,7 @@ You can automatically deploy a release when you create it, but using the optiona 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. - open OctoTools + open Fake.OctoTools Target "ReleaseAndDeploy" (fun _ -> let release = { releaseOptions with Project = "Order Processor" } @@ -73,7 +73,7 @@ In this instance we've used the default `deployOptions` and modified the environ 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: - open OctoTools + open Fake.OctoTools Target "PromoteRelease" (fun _ -> let promote = { deployOptions with