Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
- main
Production copy of the code base, at ANY point in time this branch must be able to replace production code at the drop of a pebble.
- UAT
Stable code that can be tested by business users and should be deployed in a production like environment, used as last line of defence before merging to prod
- dev
The unstable branch the dev(s) are working merging features into and ensuring merge conflicts are caught early.
- feature/xyz
The branches of mayhem, where new features / bugs / hot fixes / whatever you want are being developed.
---
Where this gets complex depends on the pipeline or deployment strategy being used,
Features are typically cut from either UAT, if it's for extending something in progress or has a dependency on something In progress, or main if it's a new feature.
How you move up the branches and environments could be 1 at a time which leads to waterfall deployments, or feature to dev, feature to UAT, feature to main if the features are small enough and lack dependencies.
--
At least that's how I operate the madness. -
@C0D4 the one thing that really trips me up is the DB migrations. Realistically, every release would be forced to have scripts ready to go back and forth, but for my tiny company it just doesn’t seem to be worth the effort.I want to implement it, but with us releasing new stuff every 2~4 weeks I cannot see it happening any time soon.
-
@lorentz you are correct about branch getting cut from one brwnch and merging into another. it has a high probability of getting conflicts but those can be resolved by taking a pull of the release-x.y.z branch.
this is intentionally done so that every feature brsnch is just [old stable code + 1 new feature code] and not [old stable code + multiple new feature code that are still in testing]
if anyone is feeling a bit rowdy, then they can directly cur a branch from release-x.y.z branch too -
@dotenvironment I think normally dev testing should be robust enough to allow building other features around the existing code. QA should not result in structural changes.
i asked my senior "why we need a develop branch" and his reply was "-_-" , literally an emoji.
Ok ,well this might be a stupid question, but i have been in this organisation for 6 months and all this time these guys have not been able to make a proper release. either they miss commits while cherry picking, or they end up reverting stuff, or they are delaying the releases due to QA disapprovals, backend issues or management issues.
i proposed a simpler vcs :
1. `uat` is the source of truth
2. for every release we create a temporary branch `release-x.y.z` from `uat`
3. then we develop every feature in a branch cut from `uat` as `feat-abc`, code in it , and merge it back to `release-x.y.z`
4. finally we merge `release-x.y.z` into `uat`
where is develop branch supposed to be cut?
which branch is supposed to be cut from develop?
which branch is supposed to merge into develop?
where is develop supposed to be merged?
no one has answers to these fucking questions. but still they wanna confuse the whole team of 15+ android and ios devs about how to use which procedure
fml :/
rant