Dev/Prod project setup with concurrent releases and branches.

jasonmc's Avatar


20 Apr, 2017 06:53 PM

New user trying to get my project setup.

I have a typical web, db, services deployment. We are using feature, bug, release branches and have different lifecycles setup for dev/test and prod. I am going to leverage channels for branch releases and that seems fine.
Where my concern is focused, is on separating dev and prod. I have 50 - 100 dev branches at any time ( not all need to be deployed at this time). Our releases are built off release branches and we support multiple different versions in prod. I am concerned with the following:
1. Keeping prod and dev separated ( mostly due to strict security restrictions)
2. Having way too many channels in a single project, leading to confusion for operations.
3. I would like to keep my production packages separate from dev

I am considering creating a single project for dev, and a versioned project for each major release, but the burden of managing the project administration is concerning to me w/o some form a template, etc. It seems most of the examples are geared towards single prod releases or even CD environments.

(I also have development cloud environments that we will be spinning up for testing and then will be torn down - that is coming soon, but doesn't seem like a simple thing to setup in Octopus.)

Any guidance would be appreciated.

  1. Support Staff 1 Posted by Rob Pearson on 21 Apr, 2017 06:15 AM

    Rob Pearson's Avatar

    Hi Jason,

    Thanks for getting in touch. I'll look at your concerns first and then come back to your overall approach.

    1. Keeping prod and dev separated ( mostly due to strict security restrictions)

    If you're building off different branches and your package names follow conventions, you should be able to differentiate between DEV and PROD packages/releases by using appropriate channel version rules. The key with this setup is to ensure the version rule for the prod channel was correct so you could only go to prod w/ from a package built off the right branch.

    1. Having way too many channels in a single project, leading to confusion for operations.

    If you created them manually or automatically per feature branch or bug branch, then it would get unwieldy. Octopus doesn't really look great with a large number of channels (this is something we're working on) so that's a valid concern. One of the approaches we've seen is to use a convention and build your packages with something meaningful to the branch included. This can then be inspected in your deployment (i.e. a package step) whereby you can create different websites/virtual directories automatically for each branch based off the package name. With this approach, you can simply have DEV and PROD channels.

    1. I would like to keep my production packages separate from dev

    I'm not totally sure what you mean by this. If you have the package names are structured correctly and you have matching channel version rules, then you should be safe. If this isn't what you mean, can you please elaborate?

    In general, I think you're approach using a project and channels sounds fine. I would avoid recreating projects for multiple releases. The overhead of managing multiple projects would be time consuming and likely error prone. The only other thing to mention is to explore multi-tenant deployments as one scenario that this suits is tenant-per-feature/tenant-per-branch. You also mentioned that you support multiple versions of your website in production which I assume means you deploy the same web app multiple times to the same environment. From our multi-tenant deployments guide.

    Tenants in Octopus Deploy allow you to deploy your projects into multiple isolated containers inside your environments. It's kind of like slicing up your environment into multiple pieces.

    It's definitely an option to keep in mind. I'd recommend walking through the guide to see if you think this would suit your environment.

    Hope this helps.



Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

25 May, 2017 02:43 AM
25 May, 2017 02:39 AM
25 May, 2017 02:36 AM
25 May, 2017 02:34 AM
25 May, 2017 02:22 AM


25 May, 2017 02:08 AM
25 May, 2017 01:10 AM
25 May, 2017 01:04 AM
24 May, 2017 11:59 PM
24 May, 2017 08:55 PM
24 May, 2017 08:14 PM