Hello, it's me again! Today I want to share you about our how we manage our development progress in using GIT. Actually, our project has a must-have rule from our course about development management, but we extend it a bit so we can have the most suitable development management but also not contradicting our main project rule.
[master]
So, as you know, there is a master branch on our (and should be every) git branch. Master is the place for our published code. CI/CD will automatically deploy our master recently pushed code to the production environment.
Besides master, there are two branches more that related to deployment, sit-uat.
[sit-uat]
The sit-uat branch is a branch for our to be reviewed per-sprint code. Before we pushed our merged code to our master, we put all of our sprint code into sit-uat. Sit-uat branch will auto-deploy the code to the sit-uat environment and after the sprint ended, the sprint review will only review our project from the sit-uat environment.
Development branches:
[AT-n]
When a sprint just started, every story should have their individual branch that inherits from sit-uat. We have a convention to create a story branch to increase readability. The convention is, every story branch should have AT-n prefix on its name, and n is for the story number.
[AT-n-m]
This is actually our innovation for the development management. Actually, our must-have rule only strict our development management until AT-n. But when we try to manage a lot of tasks per-story on a single branch, the trouble of managing other people codes is somewhat a frustration. So we have decided to add task branch that inherits its parent which is story branch.
[coldfix]
When there is a feedback during sprint review and we have to change our code (again), in sit-uat, we have to perform it on another branch so-called coldfix, so we can keep the sit-uat changes clean.
Because our project is also an educational project, so every development branches should not be deleted, and the merge request should not be squashed, so our lecturers can keep track on every individual progress. The unsquashed commit sometimes leads to unreadability on the master branch because there are a lot of commits given from every story and every people. So, we create commit and merge request convention to help others that want to read our commit log.
Commit convention:
[AT-n] - commit: [RED/GREEN/REFRACTOR] [AT-n-m-k] [commit-messages]
where:
n = story number
m = task number
k = 1 - test, 2 - implementation
Merge requests:
[branch-name] #[issue-name] [merge-title]
We also have our merge request pipeline so our code has to be reviewed perfectly before we merged into another branch.
Merge Request Pipeline:
[AT-n-m] -> [AT-n]
prerequisite: Reviewed by 2 engineers from related stack (backend/frontend)
[AT-n] -> [sit_uat]
prerequisite: Reviewed by all engineers from related stack, and 2 from cross-stack (to ensure that cross-stack requirements has been delivered)
That's it! Thank you for reading!
0 komentar:
Post a Comment