From 4f318c33f6834c43753087ca5c13716b7ae2be13 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Sat, 27 Apr 2024 13:52:09 +0100 Subject: [PATCH] Add daily email for 2024-04-24 Testing topic branches in isolation --- source/_daily_emails/2024-04-24.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 source/_daily_emails/2024-04-24.md diff --git a/source/_daily_emails/2024-04-24.md b/source/_daily_emails/2024-04-24.md new file mode 100644 index 00000000..1867cb5c --- /dev/null +++ b/source/_daily_emails/2024-04-24.md @@ -0,0 +1,27 @@ +--- +title: Testing topic branches in isolation +date: 2024-04-24 +permalink: archive/2024/04/26/testing-topic-branches-in-isolation +tags: + - software-development + - git +cta: ~ +snippet: | + Do you test topic branches in isolation? +--- + +I was recently asked about setting up different testing environments based on topic (a.k.a. feature) branches. + +When a feature or bug fix was finished, it would create a new environment for it to be tested. + +If it passed testing, the topic branch was merged and it would be included in the next release. + +But, there's no guarantee it still works once it's been merged. + +It could conflict with changes from a different topic branch and no longer work - even if it worked when it was tested in isolation on its own branch. + +To ensure it still works, it will need to be tested again. + +So, what is the benefit of testing it in isolation if it needs to be tested again once it's merged? + +This is why I prefer continuous integration and delivery (CI/CD), as I always know all changes work together and not just in isolation.