What’s the recommended best practice for handling hot fixes and patches with Octopus Deploy?
We currently have 4 branches in source control:
TeamCity watches the branches and builds them on commit.
There are additional build configurations that do deployments.
Promotion is currently a process of pulling the latest changes into a branch and then pushing to the build server.
This means that if a critical issue is found in production we can update to the production branch, fix the bug, and push it. In reality this almost never happens, but it has happened on the beta branch.
In essence, we want to maintain the flexibility to release a minor fix to a release that might have already gone to production, without having to promote something like a current alpha to production which might contain significant changes which require additional testing.
The first step would be to produce seperate NuPkg files for each branch. The common convention is to suffix them like this:
YourApp.1.0.0.nupkg <--- Production
So you’d start by having TeamCity produce a NuPkg file with a different ID based on the current branch. Assuming you’re using OctoPack, this can be done by creating a custom NuSpec file and modifying the
<id> element before OctoPack runs. Let me know if you need more details.
When you create a release for each branch you’ll then have release numbers that are also suffixed with the branch; e.g.:
Release 1.0.0 <--- Production
So when looking on the dashboard, it will be possible to see which branch is running in which environment by looking at the suffix. There’s also nothing stopping you from taking release 1.0.1 and deploying it directly to production as a hotfix. Since you’re branching in source control the 1.0.1 production package should only contain the files for production.
Hope this helps and let me know if I’ve missed anything,
Since this is 1½ year old … is this still relevant?
What i’m seeing most places … it that a deployment is either pushed to octo or downloaded from teamcity from the “default” branch.
First to Test, QA, Live … using the promote option.
What are the best options here to create a hotfix? Since there can be other commited in the default branch that might be on “Test” or “QA”.
Thanks for the reply. The advice above is still relevant - if you don’t have branching in place, and have code you don’t want to release to production on the default branch, there’s really not much Octopus can do. A good branching strategy (and then creating a package per branch) is the nicest way to solve this problem.
I watched the https://www.youtube.com/watch?v=JWGLEEm9Qhg which demostrates the integration with TC and Octopus.
But they asume it’s the same branch all the way unless I have missed something. This is what actually made me setup this. But then … I thought about how to do a bug fix … which led me to this thread.
Are there any plan to create a tutorial how how to handle branches so it’s possible to handle bugfixes as you suggest(god forbid a bug should ever end up in the Release on a live site)? I know there are some out there that have more knowledge about such kind of setup than I do.
So the process for a hotfix would be:
- Find the code that’s currently in production (perhaps
master, perhaps it was tagged)
- Create a branch from there, fix the bug
- TeamCity would build the branch, and push the packages to Octopus. Alternatively, Octopus can download the packages from that branch.
Of course, ideally, you wouldn’t just deploy the hotfix to production - you’d deploy to a test environment first. So you’d create a new release, deploy it to test, verify it, then promote it to production. It’s just like any other deployment.
Whether you decide to use tags in packages (e.g., 1.0.0-hotfix) or not is really up to you. There are plenty of branching strategies out there - GitFlow (http://nvie.com/posts/a-successful-git-branching-model/) is one that we use, but nearly any strategy can be made to work.
Hope this helps!