Rules to Better Octopus Deploy

​​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  1. Do you avoid auto generated version numbers?

    Every release needs to have a version number. However, version numbers need to be generated during the Build phase not the Release.

    ​Imagine the following scenario: Your Build system generates a NuGet package with version 1.0.4.5 that is pushed to Octopus Deploy NuGet feed. In Octopus Deploy you create a release using the default configuration. When you create a new release you will see 0.0.1 instead of 1.0.4.5. As you can imagine, it is impossible to tell from the release what version number of the application was really deployed. Hence you should change the versioning and use the package version instead.



    Bad Example - Version number is auto-generated by Octopus Deploy

    ​​​

    Good Example - Version number is inherited from a NuGet package​
  2. Do you know how to integrate RayGun with Octopus Deploy?

    One of the best features of RayGun is the ability to track crash reports against deployments. This feature allows you to tell if a particular deployment has introduced a lot of new bugs or caused a regression of exceptions. ​

    To set it up:​

    1. Under Deployments
    2. Select Octopus Deploy (Set up)
      raygun-octopus-1.jpg

      Raygun will product you with a PowerShell script to add into your octopus deployment steps that will call the RayGun API and log a new deployment

    3. Trigger a new deployment
    4. Then you’ll see the deployment in RayGun
      raygun-octopus-2.png

      Drilling into a deployment you’ll see:

      • New errors
      • Regressions
      • Recurring errors
      raygun-octopus-3.jpg
      Figure: Good Example – Now you can measure the quality of your deployments
  3. Do you point Home directory to a different drive?

    ​​​When you run Octopus Deploy setup the application installs to you %Program Files%\Octopus Deploy folder. If you installed Octopus Server you will see Server subfolder and if you installed Octopus Tentacle then it will be Tentacle. However, this is a folder where Octopus Deploy bits live, not your applications, packages, etc. Those artifacts live in the Home folder that you specify during the Octopus Setup Wizard the first time you configure the Server/Tentacle.​

    By default the Home directory points to %SystemDrive%\Octopus which is not great. The main reason is that the Home folder is constantly growing and clogging up your OS drive. So you need to point the Home folder to a new drive e.g. D:\Octopus

    2016-05-30_12-18-02.png
    ​​Bad Example - Home directory is pointing to %SystemDrive%​​

    2016-05-30_12-29-09.png
    ​​​Good Example - Home directory is pointing to another drive​
  4. Do you set retention policy?

    Octopus Deploy will by default keep all packages (NuGet, ZIP, …) as well as files deployed on all Tentacles. Because of that your hard drive will fill up very fast as you keep pushing in more packages and creating more releases, especially if you are using Continuous Integration and pushing out new packages with every commit to a repository.

    That's why you need to set up a retention policy. Octopus Deploy supports two options:
    • Retention policy for packages
    • Retention policy for deployments (via Lifecycle phases)
    You should set up both.

    Package Policy​


    2016-05-30_15-00-04.png
    ​Bad Example - Retention policy is set to Keep forever​​

    ​​

    ​​2016-05-30_15-00-29.png

    ​Good Example - Retention policy is set to a number of days​


    Lifecycle Policy

    2016-05-30_15-01-55.png

    Bad Example - Lifecycle's retention policy is set to Keep all​

    ​​

    2016-05-30_15-49-37.png

    ​Good Example - Lifecycle's retention policy is set to 3 Releases