Branches should reflect your supported versions or your CI controls. Tags can be used as placeholder where supported versions can be branched.
A supported version means you will either A. You're actively applying udates while working towards a new version. B. Willing to hotpatch so you don't release new functionality not ready for production.
If you are using git you can't avoid branches (clone is a branch) but they are also freely available.
Well you're totally right, local branches represent branching, but again they're hopefully short lived, and or kept in parity with the long lived branches on origin. Also could you elaborate on what you mean by branches representing the CI controls?
When you decide that your CI system is taking too long, but not sufficient to indicate product health, you might say 'develop' will run more than smoke tests, but master will execute performance metrics.
Hopefully it is not worse where you don't do testing on your branches at all.
So you're talking about using branches to define the environments for your CICD... I found it highly innefficient. The pipeline between development and production should be streamlined, and is the artifact that results from CI the one that should be promoted between environments instead of the code between branches. And yes that artifact should be completely tested for it to be promoted between environments.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Branches should reflect your supported versions or your CI controls. Tags can be used as placeholder where supported versions can be branched.
A supported version means you will either A. You're actively applying udates while working towards a new version. B. Willing to hotpatch so you don't release new functionality not ready for production.
If you are using git you can't avoid branches (clone is a branch) but they are also freely available.
Well you're totally right, local branches represent branching, but again they're hopefully short lived, and or kept in parity with the long lived branches on origin. Also could you elaborate on what you mean by branches representing the CI controls?
When you decide that your CI system is taking too long, but not sufficient to indicate product health, you might say 'develop' will run more than smoke tests, but master will execute performance metrics.
Hopefully it is not worse where you don't do testing on your branches at all.
So you're talking about using branches to define the environments for your CICD... I found it highly innefficient. The pipeline between development and production should be streamlined, and is the artifact that results from CI the one that should be promoted between environments instead of the code between branches. And yes that artifact should be completely tested for it to be promoted between environments.