Add daily email for 2024-04-24
Testing topic branches in isolation
This commit is contained in:
parent
a7fa9e4183
commit
4f318c33f6
27
source/_daily_emails/2024-04-24.md
Normal file
27
source/_daily_emails/2024-04-24.md
Normal file
|
@ -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.
|
Loading…
Reference in a new issue