How to set the initial environment per project

Legacy Uncategorised
1

We have the following development process:

  • developer commits to forks github repo
  • developer does work and commits to a branch in their forked repo
  • developer creates pull request to merge into either “development branch” or “feature branch” if it is not ready for development branch
  • code is reviewed and then merged into the main github repo.
  • At this point Teamcity will pick up the commit, build the code and create a package and release for Octopus (the package will have the branch name in it to ensure it is obvious that it is not a release candidate).
  • Octopus would deploy it to our Azure environment depending on the project.
  • When the work is deemed to be ready for a release the development branch would be merged into a new release branch with a name of release-X.Y.Z. This would again be picked up by a Teamcity build process (different one so that Octopus can know it will go to a different environment)
  • This release candidate package is what would be released to the customers test environment and then promoted to their live.

The issue I am having is that I can not see how to let some projects have a different “start” environment. I.e. the release candidate would not want to use our Dev Azure environment. In fact as some of our customers insist that they host the final application we have a test on their server then the live, so the process can not be the same for dev to release. This process is different to our dev, as we generally have azure web apps so that dynamic feature branches can be created and destroyed quickly, easily and cost effectively.

As described above we create a separate package for each release candidate as a manual step has happened, i.e. a developer has merged code into another branch). So we cannot simply promote from dev all the way through to live.

To address this I had created two projects, one for the website in dev, another for the project release candidate.

  • the dev would deploy to our azure env, creating machines as required.
  • the release candidate would be deploying to their server.

Each has its own release packages in OD created (using the same library package feed (that’s why each package would have tagging to indicate if it is pre release or not).

Once I create a release, either manually or via Teamcity, I do not seem to be able to “skip” the Azure environment or even better not have it as an option for that project and be able to deploy it to the customers test environment.

How would I go about setting this up please?

Regards

2

Hi Jon,

Thanks for getting in touch! It looks like you are after both our Lifecycle and Channels feature.
Octopus uses Lifecycles to manage promotion through different environments while Channels are used to manage branching and versioning within the project.
In your situation, you would be able to set up two different Channels, one for dev, and one for release. Each Channel could be given a different Lifecycle, as an example.

Create your Lifecycles:

Development Lifecycle
Release Lifecycle

Now your Channels:

Development Branch: Assign Development Lifecycle
Release Branch: Assign Release Lifecycle

Once you have created the Lifecycles and Channels you assign your Channels a Lifecycle and set up some rules for what release qualifies for what Channel.
You can then set up a Tag in the versioning rules for your Channel so that as soon as, say fancynewpackage.1.0.0-prerelease gets built and pushed to the server using ARC the channel will pick up the -prerelease tag and make sure the correct version is used for a particular release.

We have some fantastic documentation on Lifecycles and Channels that I recommend reading before you implement them as to get a better understanding of how they work as a whole. I have linked to both documentation pages below and a walkthrough blog post for Channels.



Let me know if that helps, or if you have any further questions.:slight_smile:

Best Regards,
Daniel

3

That worked great, thank you.

4

Hi Jon,

No worries at all! I’m glad I could help.

Regards,
Daniel