From c95636c4bce59de31a7b035d8bd1b5304f65b142 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Sun, 28 Apr 2024 23:49:01 +0100 Subject: [PATCH] Add daily email for 2024-04-26 Don't cherry-pick features from a branch to deploy --- source/_daily_emails/2024-04-26.md | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 source/_daily_emails/2024-04-26.md diff --git a/source/_daily_emails/2024-04-26.md b/source/_daily_emails/2024-04-26.md new file mode 100644 index 00000000..483c78a2 --- /dev/null +++ b/source/_daily_emails/2024-04-26.md @@ -0,0 +1,31 @@ +--- +title: Don't cherry-pick features from a branch to deploy +date: 2024-04-26 +permalink: archive/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.