GitLab in software development – part 2: Code Review
GitLab allows placing the number of the relevant application already in the description of the commit. That enables us to create a connection between two stages of the software development process: the declaration itself and the commit with an assigned application.
If the application and code are in the same project, you can add #xxx to the description of the commit, replacing xxx with the entry number. Otherwise, you can add the entire URL to the application (https://gitlab.com/ <username> / <project> / request / <xxx>).
Of course, “gitlab.com” needs to be replaced with the URL of your GitLab instance.
A small note: Combining the first commit with the application will significantly improve your process traceability with the GitLab Cycle Analytics tool. This tool measures the time spent planning the implementation, i.e.the time between the creation of the application and the first commit.
When we send data to a functional branch, GitLab will recognize the changes and ask for the creation of a Merge Request (MR). Each MR has a title (summary of implementation) and description supported by Markdown. In the description, we can briefly present what changes the MR provides and mention the related applications and MRs (creating a connection between them).
If the commit or MR solves the issue problem, we can create patterns for closing issues. This solution will allow automating this process when the said commit or MR connects to the default branch in the project.
Consider the following example:
MR in this description will perform the following operations:
- after executing the merge, it will close the application #xxx and https://gitlab.com/ <username> / <projekt> / zgloszenia / <xxx>,
- will display the picture,
- send an e-mail notification to users @Maria, @Janina, and @Janusz.
We can assign the MR to ourselves until we finish the work and then assign it to the person who will write the review. We can also repeatedly assign MR to different people, for example, when we need several reviews.
MRs can also be tagged and added to milestones so that it’s easier to organize and prioritize work in the project.
When we add or edit a file, and then commit to the new branch from the interface instead of the command line, we can still create a new merge request. Just check the start box and the new merge request with these changes so that GitLab automatically creates a new MR after executing the commit.
A small note: We must remember to add a closing pattern to our MR to be able to track the process using the GitLab Cycle Analytics tool. It examines the “coding” stage, i.e., the time between the push in the first commit and the merge request, which is related to this commit.
What’s new here is the currently developed Review Apps tool, which allows placing the application in a dynamic environment. As a result, we can view changes based on the branch name for a given merge request. I invite you to learn more about it by reading this example use case.
WIP MR or Work in Progress Merge Request (Merge Request draft) is GitLab’s way of preventing premature MRs merges. Just add the WIP prefix before the MR name, and it will not be merged until you delete it.
When your changes are ready for merge, delete the WIP prefix. You can do it manually by editing the application or using the shortcut available under the MR’s description.
A new feature here is the WIP prefix that can be quickly added to the merge request using the /wip command. Just enter it in the comment or description of the MR.
After creating a merge request, we can collect feedback from team members or colleagues. The GitLab interface is equipped with options for adding comments in the line of code, answering and closing them.
We can also get a link to a single line of code by clicking on its number.
The history of commits is available from the interface level and also allows us to track changes between different versions of a given file.
If we encounter a conflict during merge execution, we can easily solve it from the user interface or edit the file manually:
Build, test, implement
GitLab CI is an advanced mechanism for Continous Integration, Continuous Deployment, and Continuous Delivery, which we can use to execute scripts just the way we want.
The heart of the tool is the Yaml file called .gitlab-ci.yml, located in the project’s repository. To use the CI templates, we add a new file named .gitlab-ci.yml in the web interface. We will then have access to a drop-down list with many templates for different applications from which we can choose the best one for our project.
The Koding integration option allows running the entire production environment in the cloud. Such a solution gives us the opportunity to perform a checkout or merge request, and the entire operation takes place in a completely integrated environment.
Examples of use
The GitLab CI tool can be used in the following ways:
- construction of any static page generators and implementation of websites using GitLab Pages,
- website implementation for pre-production and production environments,
- building applications for the iOS system,
- construction and implementation of Docker Image using the GitLab Container Registry tool.
We present some more examples of GitLab CI projects here.
Feedback: Cycle analysis
If we use GitLab Workflow, we can collect feedback using the GitLab Cycle Analytics tool. It measures the time the team needed to complete the transition from idea to production, taking into account the various stages of the entire process:
- Application – the time between the creation of the application and assignment to a milestone or to the list on the notice board,
- Planning – time measured from the end of the application to the first commit,
- Coding – the time from the end of planning to the creation of a merge request,
- Tests – execution time of the entire CI process for a given merge request,
- Overview – the time between the creation of merge request and merge,
- Staging – the time between merge and production implementation,
- Production – the sum of all stages: the time between the application’s creation and the implementation of the production code.