Skip to content

Commit

Permalink
Merge pull request #468 from jamescrowley/patch-1
Browse files Browse the repository at this point in the history
Fix namespaces of imports in OctoTools example
  • Loading branch information
forki committed Jun 15, 2014
2 parents 10f0ca6 + aba1b5d commit ebed663
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions help/octopusdeploy.md
Original file line number Diff line number Diff line change
Expand Up @@ -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" }
Expand All @@ -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" }
Expand All @@ -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
Expand Down

0 comments on commit ebed663

Please sign in to comment.