Why GitLab?

When working on projects, it’s always easier to keep organized when you have everything in one place. This is especially true when working on such projects which require many different steps, or even more so when you work on multiple projects at once. In such scenarios, good organization is the key.

For developers, this is a very real and very common scenario. Bringing an application from an idea to a finished product takes a lot of complicated steps, and frequently includes many people or even different teams working on the same project.

Enter GitLab: an all-in-one solution that allows keeping all phases of your project in one place.

Since GitLab was developed as an expanded Git, we first need to explain what Git is.

So, what exactly is Git?

Git stands for an open-source control system, designed to handle everything from small to very large projects with speed and efficiency. The primary purpose of Git is to handle many changes in one or more projects which contain and so to track progress over time.
Git is created not only for professionals but also for non-technical users to monitor and track all their project files.

Why GitLab?

When we “expand” a Git to GitLab, we get the full-service repository and complete DevOps platform that allows all users to perform all the tasks in the project. By all tasks, we mean, every step as a part of every bigger phase or milestone, from project planning and source code management to monitoring and security. The main benefit of GitLab is to allow all team members to collaborate all the time through every phase and all to build better software and achieve the best possible results.

Why do DevOps supporters love GitLab?

Before this kind of platform, the developers’ work was to think ten steps ahead. Multitasking and “thinking five steps ahead” is often part of a developer`s work, but only when we speak about the code and application functionalities. However, we don`t expect them to think also about the platform where the same application needs to come to life. Also, we often have more than one developer who works on the same project, so how can they track each other’s work? What if one, for some reason, needs to continue the colleague`s job? How should other developers identify the difficulties which the first one was facing and at what time? How will the automation tests for the code be written? Does anyone else need to run this code? How hard is it to reproduce the right environment to test it?

The GitLab platform answers this question with its simplicity and automation. GitLab application offers tracking from planning to creation, build, verify, security testing, deploying, and monitoring to automate the entire DevOps life cycle. We use it also for the high availability and replication and scalability and available for using on-premises or cloud storage together with wiki, issue-tracking, and CI/CD pipeline features.

We won’t be going too much into detail as we covered the DevOps topic fully in our “What is DevOps and why is it important” blog post, but in the meantime, we will continue with the listing of the main phases of the projects and try to explain how GitLab can support and assist us with it, with a combination of all kinds of toolsets.

How can GitLab assist us?

Each project consists of many or fewer milestones, while each of them contains small tasks that are needed to move the project from the idea to the completed phase. We mark off the ten main phases; most of them are essential for every project, but this list is a little bit adjusted to our field.

IDEA: The beginning of every new proposal or project.

It’s the phase (or rather a state instead of phase) where we start with the research and identification of opportunities and challenges. This state usually begins with a brainstorming session: a chit chat with colleagues, collecting inspiration, developing the idea. During this phase, we will use Mattermost, an open-source online chat service.

ISSUE: The best possible way to test your idea.

Once you`ve done your research, you need to test your theory by creating scenarios for any potential issue you can come up with. Usually, if you and your collaborators find a way to polish and improve your idea to find the solution for the mentioned issue, you are on the right track. The Issues List and Issue references can help you to track, test, and work on multiple issues at the same time.

PLAN: The final step before getting to work.

Once you`ve successfully tested your idea for any possible threat, it’s time to create a workflow for the realization of the project. The tool where you decided to work, should allow you to create and implement all phases for the project, assign the responsible people on the tasks inside the stages, create a timeline, and prioritize and organize all workflows. To complete all this, GitLab jumps in with the Issue Board.

CODE: Let’s create some magic.

Now we have the whole project workflow divided into milestones plus we did our job with the preparation and organization of all the tools and assets, we are ready to write our code. When you start writing the code, step by step, with GitLab Snippets, you can store and also share bits of code and text with your colleagues. You can adjust the Snippets to private or public, the only difference is that the public is always related to some project, but the private can be independent if you need it for any reason.

COMMIT: Pieces of puzzles.

We are working on the code, step by step, and piece by piece, and usually, there are many back and forth actions. For that reason, we often decide to write a code locally, and then, once we’re done with the code, either as a whole or just an iteration we will commit our code and push to our GitLab repository.

TEST: Automation test.

We have now committed the code to the repository, and we would like to test it to see if everything works as supposed to. GitLab jumps in with GitLab CI, a built-in tool for Continuous Integration, Continuous Deployment, and Continuous Delivery.

REVIEW: Nice job.

We are one step closer. Our script passed the test and tests were successful, and now we are ready to get our code reviewed and approved. For this step, we can use the Merge request to merge one branch into another. Before the completion of the process, our colleague or manager will, if everything is ok, approve it and push a commit with their final review.

STAGING: First sneak-peak.

Until now, we could see the code only in lines, but deploying our code to the staging environment allows us to check the replica of our application and confirm if everything worked as we were expecting or if we still need adjustments. GitLab allows us to see a list of environments and deployments which are available for any project.

PRODUCTION: Completed and published.

We thoroughly checked our code, went through the staging environment, and we are happy with the result since everything is working and looking as expected. Good job. Now we are ready to deploy the code to our production environment!

FEEDBACK: Project overview.

We finished our project, but our work is still not over. It is time to look back and analyze all the phase phases and detect if we were facing any difficulties and how we could improve it to make the next project even more efficient. We use Cycle Analytics for feedback on the time we spent on crucial stages of our process. Also, the Milestones tool allows us the complete insight and overview of all project phases by a dedicated team, specific date, type of assignment, etc.

Example: Analytics – commits of the one-month period for one project (source: https://gitlab.gnome.org)

All these phases can be tracked on our GitLab Issue board. The fluctuation of the tasks on the board is easy, and we can continuously move our tasks in different columns according to the project phase, Backend, Fronted, UX, To-do, Doing, Done, Waiting for review (or whatever we called them).

When looking back on the subject, there were many opportunities where we could elaborate in much more details. However, we didn’t want to stray too much off the subject, so we tried to keep it short and simple. Our goal was to bring GitLab closer to you as we believe planning shouldn’t be one of the challenges you’re facing when working on a project.

Do you use GitLab in your day to day work? Let us know in the comments below or leave a comment on social media. And as always, if you have any questions related to GitLab, feel free to get in touch.