this post was submitted on 08 Jun 2023
20 points (100.0% liked)
Programming
13376 readers
2 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
have you looked at Git Flow? Its pretty solid.
My team has a develop branch from which we branch feature branches. On it we commit our stuff and when we think its feature complete we build a snapshot version of it so that our QA can test it. Once that test was successful, and the code has been peer reviewed, it will be merged back onto develop.
PRs will be auto built so that the feature can be integrated and automated tested.
There is trunk based way. Although I have not used it heavily at work. https://trunkbaseddevelopment.com/
My team is very small (3 people). We mostly trust each other on just merging away without PR reviews. Although we ask for reviews when in doubt during development, not when ready to merge. Mostly for asking ideas on where to put stuff.
On my previous work, we were like a 15+ dev team, doing mandatory PR reviews before merging and doing the shotgun request (ping @review_channel and pray). I hated it.
So we use that, and that works well. What does your peer review process look like? Is it pretty loosy-goosy, or do you have hard and fast guidelines and checklists?
Its pretty much loosy-goosy with only a limit of how many checks are required (including a fully built build) to be able to merge.
Do you have automated builds for every snapshot that needs to be tested or is QA running them locally?
We have a pipeline (realised on Jenkins with jenkinfiles) that is triggered by changes on a Branch a PR was made for. Another pipeline then is responsible for providing the Application for QA testing.