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