Oliver Davies
5eba6de81a
This is a follow-up to commit 3be9031de8
as each daily email has a `permalink` value that overrides the default
content type permalink.
32 lines
1.3 KiB
Markdown
32 lines
1.3 KiB
Markdown
---
|
|
title: Don't cherry-pick features from a branch to deploy
|
|
date: 2024-04-26
|
|
permalink: daily/2024/04/26/don-t-cherry-pick-features-from-a-branch-to-deploy
|
|
tags:
|
|
- software-development
|
|
- git
|
|
cta: ~
|
|
snippet: |
|
|
Don't cherry-pick features from a branch to deploy
|
|
---
|
|
|
|
I previously worked on a project where, after a code change had been reviewed and merged, it was pushed to a UAT environment for the client to test.
|
|
|
|
This usually resulted in a group of changes pushed to the UAT environment, waiting for the client to test them.
|
|
|
|
They would, and then decide which changes they wanted to be moved to production.
|
|
|
|
Maybe changes 1, 2 and 4 would be asked to be deployed, but not 3 or 5.
|
|
|
|
Someone would then cherry pick the relevant commits onto the mainline branch and deploy them to production.
|
|
|
|
But, if the code isn't the same as on that UAT environment, how do you know it still works?
|
|
|
|
Could a commit have been missed or could not including a non-selected commit have caused a regression or unintended side effects?
|
|
|
|
`git cherry-pick` isn't a command I use often, and definitely not in this scenario.
|
|
|
|
If you want to select which changes go live, feature flags are a better option as you don't need to change the commits or code you're pushing.
|
|
|
|
You push all the commits from UAT to production and enable the feature flags for the things you want to release.
|