What’s the recommended best practice for handling hot fixes and patches with Octopus Deploy?
We currently have 4 branches in source control:
Trunk
Alpha
Beta
Production
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-trunk.nupkg
YourApp.1.0.0-alpha.nupkg
YourApp.1.0.0-beta.nupkg
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-trunk
Release 1.0.0-alpha
Release 1.0.0-beta
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,
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.
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.
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.