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.
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.