Promotion: how to deal with multiple releases and release notes

Legacy Modelling
1

Current process:

  1. There are dev, qa, master branches
  2. new feature is developed in a new branch created from master
  3. developer merges feature into dev branch
  4. Team City deploys code to dev environment
  5. developer merges feature into qa branch
  6. Team City deploys code to qa environment
  7. developer merges feature into master branch
  8. Team City deploys code to production environment

I want to consider changes to this workflow and I think we could benefit from the promotion feature. I plan on introducing new staging environment that will receive deployments for the master branch. No direct deployments will be allowed into the Production environment, but deployments will need to be promoted from Staging to the Production. New workflow looks like this:

  1. dev, qa, master branches
  2. new feature is developed in new branch created from master
  3. developer merges feature into dev branch
  4. Team City deploys code to dev environment
  5. developer merges feature into qa branch
  6. Team City deploys code to qa environment
  7. developer merges feature into master branch
  8. Team City deploys code to staging
  9. Deployment Manager promotes release to Production

My question is about promotion feature:

Let’s say two developers have merged into master branch. Team City created two relases: A1 and A2. Both releases were deployed to stating environment. A1 first, then A2. There are now two releases that can be promoted to Production. Obviously A2 includes A1, is there a way to prevent A1 from being promoted once A2 has been promoted?

Also, I’m a little unclear on how to deal with release notes in the promotion model. A1 has release notes and A2 has release notes. When A2 is promoted, it includes the code from A1 but not the release notes.

I’m sure that I’m not fully understanding the benefits and function of the promotion model. Perhaps we won’t even benefit from it.

Can you please help me to reconcile my questions and misunderstanding?

Thank you,
Alex

2

Hi Alex,

There is nothing to prevent an earlier release from being promoted. Users often need to deploy previous releases if they have a problem with their latest release. You can block an individual release from being deployed, so you could potentially call the Octopus API from TeamCity to block earlier releases with a little work, but in practice this is extra complexity for little benefit. Just set your permissions so that only the Deployment Manager can deploy to Production (which you probably already do) if this is a concern.

Release notes: it’s really up to you to include the release notes you need to include. And that’s going to be entirely dependent on your branching strategy and how you are building your release notes. For example, at Octopus we tag issues in our issue tracker with the release they are planned to go out in, and have a script that builds release notes based on that. If a release doesn’t make it to production we can re-tag so the release notes go in to the next release instead. There is nothing automatic in Octopus to do this for you. It might be as simple as just showing the release notes for all releases somewhere, even if they didn’t go to PROD, then people will see the v1.2 and v1.1 release notes, and assume everything from v1.1 is in v1.2 even if v1.1 never went to prod directly.

The major benefit of promotions is when your workflow is set up such that you can push packages into one end of Octopus and then promote through environments, such that the same package that passes QA is the one that gets deployed to production. In your proposed workflow you get the benefit of confirming that the exact package you are planning to ship to Prod deploys successfully in an environment that is hopefully very similar to your Prod environment, and you also have a chance to do a final round of QA to ensure features that have been developed and tested separately until this point don’t cause problems.

A common approach is to promote from even earlier in the flow, so that more of your QA process happens on a package that can potentially go directly to Prod, but that obviously depends on the rest of your development process and branching strategy.

I hope that helps.

Regards,
Mark