Remember we introduced the DevOps pipeline as seen by GitLab in previous chapter. This screenshot shows the various GitLab stages:

In this chapter, we will present several aspects of the entire pipeline as we try to use it in our example project. The first phase is defined as Manage, and it sounds a bit weird as the first part, but it is a continuous process spanning the entire pipeline, and GitLab provides tools for it. The next stage will be Plan, in which you refine and prioritize and set timelines. Then you start the Create phase where the tasks are executed to produce solutions. After creating your product, you need to test different aspects of it in the Verify phase. After verifying the product you will package it for deployment.

To explain the GitLab workflow in more detail, we will present a use case that is going to be used throughout this chapter to demonstrate features in GitLab. For some features you will need the most comprehensive GitLab license.

Imagine a company called Event Horizon. They want to build a solution for managing events (for humans). For instance, you can use their solution to arrange invitations to a party.

We introduce User1, who is a backend engineer, and is tasked with creating a backend for this solution. Then we also have User2, who is currently product owner of this product. They are both part of the IT department of the company. Then we have User3, who is part of the marketing department.

User1 and User2 have both been made members of the IT group in GitLab. User3 is a member of the marketing group, but has reporter access to IT.

Let's help them create this product (minimally) and demonstrate how they can use GitLab for this.

In the meeting where both users and developers are present (the Release planning in XP, or Sprint 0 when using Scrum) it is decided that these are following requirements:

1. We want to build an app to help organize events.
2. It needs to use email to communicate.
3. We are creating a list of invitees in advance.
4. Invitees can interactively indicate if they will attend.
5. Non-functional requirement: documentation is very important.
6. Non-functional requirement: we want to automate as much as possible.
7. Non-functional requirement: the tool used should enhance collaboration.
8. Non-functional requirement: the code used should be reviewed by at least one other person.

At the end of the meeting, the requirements are prioritized and the developers talk without the customers about the possibilities with GitLab as a product. This phase is the subject of the next section.