Deploy Debug or Release mode in DEV box?

Legacy Uncategorised
1

Hi,

My environments are: localhost, DEV, System Test, User Acceptance, Pre Production and Production by this order.

Many argue that I should deploy to the DEV box in Debug mode and to all other environments in Release mode, because in Release mode you lose debugging symbols.
Others argue that you should test your code in Release mode already in the DEV box, because of the code optimizations.

What’s your view on this?

Is there any Elegant way to deploy Debug or Release depending on the environment using TeamCity + Octopus?

Thanks,
Miguel

2

Hi Miguel,

Thanks for getting in touch. Generally we recommend build your binaries once. If you’re simply promoting the same release along a straight promotion path like you’ve described, build your binaries once is convenient, and there’s less risk that what you test has changed by the time you go to Production.

That being said, internally we use git-flow to work on Octopus Deploy, which means we can ship a pre-release from the release/3.3.0 branch for example, and when happy, we merge that into master, then build and ship 3.3.0 from the same commit/revision.

In your situation, if you think there’s a benefit in building and deploying a “debug” build to your “DEV” environments, and changing to “release” builds for the other environments, go for it! You could also leverage the Channels features in Octopus 3.2 to make this easier.

  1. Your “debug” builds should be versioned with a SemVer pre-release tag, say MyApp.4.1.0-ci0001 and MyApp.4.1.0-ci0002. This way you could create a lifecycle that only goes to Localhost and DEV, tie that to a Dev Channel with a version Rule that only accepts versions with the ci style pre-release tag.

  2. Your “release” builds should be versions without a SemVer pre-release tag, say MyApp.4.1.0 and MyApp.4.1.1. Similarly you could create a lifecycle that goes to System Test, User Acceptance, Pre-Production, and Production, and a Channel with a version Rule that only accepts versions without the pre-release tag.

Take a look at the Channels Walkthrough that describes this behavior in more detail: https://octopus.com/blog/channels-walkthrough

After all of that discussion, my preference is to have the exact same build process, but use git-flow and GitVersion for anything moderately complex.

Hope that helps!
Mike

3

Hi, sorry for dig this back up.

I’m really interested in how you have this configured Michael… We also use git flow and I cannot get Octopus setup to correctly deploy develop branch to one environment and the master branch to staging and the ability to promote to live. Could you go into more detail on the configuration / process of code being checked in, through compiling and into Octopus?

Thanks

4

Hi,

Thanks for getting in touch - I’ve been on vacation, so apologies for the late reply. I’ll provide a quick summary of the building blocks required, and the https://octopus.com/blog/channels-walkthrough I mentioned should help if you need more details.

Note: We now support SemVer 2 in Octopus 3.4 or newer.

  1. Configure the builds for your develop branch to produce SemVer build numbers like 3.2.0-alpha.3 if using Octopus 3.4+, or 3.2.0-alpha.3 if using an earlier version of Octopus.
  2. Configure a Lifecycle in Octopus that goes to your one environment, say Dev, then create a Channel connecting to that Lifecycle. Finally make sure to set Channel Version Rules for your packages, so any releases with alpha will be placed into this Channel.

Once you have this working, you can follow the same steps to configure a Channel for your master builds to be promoted through a different Lifecycle.

Hope that helps!