gib's blog

Effective Project Management with GitLab

Why GitLab?

Project management can be done with different tools and platforms. Our team decided to opt for "Full Stack GitLab" so that our lists of tasks are kept close to our codebase. In this way, we can easily integrate tasks with our personal Git branches without needing to do integration setup.

Work Flow

At the beginning of the Software project sprint phases, our team decided to abide to this following project management work flow:

  1. Define the tasks and put them in the Gitlab Issue Boards. By default, the issue's label is Todo.

gib's blog

  1. Let's say there is a task called User Cart Items Page. If I were to take that task, I would name the branch where I would work on as PBI_User_Cart_Items_Page. By doing this, the project is more structured and the branching system is cleaner.

  2. If I'm doing the task, I should move the card to the Doing board.

gib's blog

  1. While working on the task, I should make my commit messages descriptive.

gib's blog

  1. Once I'm done working on my task, I should create a merge request.

gib's blog

  1. Now here's the chance for the GitLab pipeline to check my code coverage and code quality. Other than that, my friends can also review my code and discuss more about the code that I have made.

gib's blog

  1. If all is good, I can then merge my branch to the target branch.

But Why?

  1. Why not use Linear or Trello?

Those are really good tools, but we have an opportunity to unite our project management tool with our codebase in GitLab Issues. With its minimum setup and intuitive interface, in my opinion, this is the best option for my team to manage our backlogs.

It's so easy to add backlogs, assign team members to a task, create related issues, see how our team is doing, and link a backlog with a merge request. Everything just feels connected to each other with minimum effort. Our team is able to get a sense of our progress with GitLab Issues. It's that good for us.

  1. Why create merge request descriptions?

Honestly, this step can be quite tedious. However, the benefits that it offers are so rich.

Merge request comments can act as a form of documentation of our code, specifically in the code handled in the merge request. An example of this merge request, where I refactored some Typesense usage to use pgvector instead (due to some cost and issues). I needed to document these changes as I categorize this as a major change, because we're changing the system of our events creation and search, one of the most important features of our app.

However, it might be tedious if we have to manually create the sections of the merge request description. To solve this, we set up a merge request template (as of now it's only for the backend) to guide us on what to write on the merge request. In this way, merge requests descriptions can be more uniform and quicker to write.

Bottom Line

GitLab is surprisingly a swiss army knife for project development. Our team is really comfortable in using it and our team really gets the benefits of using it. Better progress checking, easy codebase integration, and elegant code discussions are benefits that our team get by using this platform.