GitLab Certified Associate Exam
Tags: gitlab, git
Published: 2022-01-15 09:12:02

**What is GitLab**
Gitlab is a complete open source DevOps platform, delivered as a single application, fundamentally changing the way Development, security, and Ops teams collaborate and build software. 

**GitLab Organization**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3r5xqkwywd1jve6zxecf.jpg)

1. 
Groups: Groups are top level organization method. Other programs may introduce it as "Project".

2. 
Subgroup: This is known as nested groups or hierarchical groups and allows you to have up to 20 levels of groups.

3. 
Issues: They are always associated with a specific project, but if you have multiple projects in a group, you can also view all the issues collectively at the group.

4. 
Issue features: Once one create an issue , he can add participants and communicate with them using Comments. He can also assign participants to the issue to help track who is responsible for what.

5. 
Epics: Give you opportunity to manage project , issue etc. much more efficiently . Although it is a Premium feature  . You may read about [this](https://docs.gitlab.com/ee/user/group/epics/#epics)

**How Issue is connected with all GitLab components**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jhkz77ewkcvgxxhiiws3.jpg)

**GitLab Issue Flow**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/px07bd31iv2u31fn9mlv.png)
This is how a a team works with a product starting from a issue:

1. 
Create and discuss a new issue:

- Team creates an issue

- Team applies "Discussion" label

- Team discuss using Comments

2. 
Code creation

- Back end team starts work and developer starts writing code

- Developer assigns issue to themselves

- Developer adds "Working on" label

3. 
Commit and merge request

- Developer creates commits

- Developer pushes commits to a feature

- Developer creates a Merge Request

- Backend team changes labels to "Frontend"

4. 
Deploy to staging

- Frontend developer starts working on issue

- Developer assigns issue to themselves

- Developer adds "Working on" label

- Team reviews and refines code

- Team stages code

- Team changes label to "Staging"

- After successful implementation team changes label to "Ready"

5. 
Ready

- Technical documentation team adds "Docs" label

- Marketing team adds "Marketing" label

- Technical team remove "Docs" label when done

- When done, the marketing team removes "Marketing" label and ads "Production" label

6. 
Deploy and Production

- Release team merges MR and deploys feature to production

- Release team closes issue

**Contribute to GitLab**
Link: https://gitlab.com/gitlab-org/gitlab


**Git Workflow with GitLab**

![Git work flow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/atwnf4da80ert63a5pet.jpg)

- 


[GitLab Cheatsheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf )


**Code Review-Typically Workflow**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7hf042egh53absc1a0to.jpg)

**Code review workflow **

1. 
New Merge Request: 

- Edit files inline on branch

- Commit changes : Squash only or One commit per file in GUI

- Merge request

- Resolve merge conflicts

2. Assign & Reviews

- Assignments

- Changes tab to view differences

- Edit inline

- Make comments inline

- Discussion tab to view comments

3. 
Final Assignment: Assignment feature in GitLab

4.
Final review: 

- Assignments

- Changes tab to view differences

- Edit inline

- Make comments inline

- Discussion tab to view comments

5. Merge approved: Approval feature in GitLab

6. Additional tools for code review: 

- Wiki: A separate system for documentation called [Wiki](https://docs.gitlab.com/ee/user/project/wiki/), is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.


Wikis are very convenient if you don’t want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.


You can create Wiki pages in the web interface or locally using Git since every Wiki is a separate Git repository.

- Web IDE: The [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#web-ide) editor makes it faster and easier to contribute changes to your projects by providing an advanced editor with commit staging.

- Snippets : With GitLab Snippets you can store and share bits of code and text with other users.
[Read more here](https://docs.gitlab.com/ee/user/snippets.html)


**GitLab's CI/CD**
Continuous Integration(CI): is practice of merging all the code that is being produced by developers.

Continuous Delivery(CD): This adds that the software can be released to production at any time, often by automatically pushing changes to a staging system.

Continuous Deployment(CD): this goes further and pushes changes to production automatically.


When someone create a pull req , the request triggers a pipeline to build, test and validate new code prior to merging the changes within the repository.
CI works to integrate code provided by your team in a shared repository. CI helps you catch and reduce bugs early in the development cycle.
CD ensures that the delivery of CI validated code to your application . CD moves verified code to your application faster. 

so CI to detect bug or error and CD to merge the errorless code to push faster.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ljaedq9rekemqkayx2z9.jpg)

**How CI/CD Works**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cq53y419lecoxa7o72l8.png)

**Key Ingredients**
To use GitLab CI/CD , need to define a pipeline within a YAML called

.gitlab-ci.yml: This is a yaml file and is a pipeline definition file. It specified the stages , jobs, and actions that one want to perform. This works as a brain.

![.gitlab-ci.yml](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gisb6bod17tkd0m28lyl.png)

and then install and configure

GitLab Runner: This works as a body and written in Go and run the jobs specified in the YAML file using an API to communicate with Gitlab.

**CI/CD Pipeline**


Basically the pipeline is the process which is done in stage . So what is stage?

1. Stage: This is collection of jobs to be run in parallel. The default stages are Build, Test and Deploy. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rcgm70sp26qdqpcu5t0g.jpg)
Here you can see 4 pipeline stages as Build, Test, Staging, Production

2.
Jobs: these are scripts that perform tasks. The jobs in each stage are executed in parallel. if one job fails, next job  does not get executed.

3. 
Environments : This are where we deploy to. These are specified in the jobs within the ci.yml file. 
ex: Build, Test, Staging, Production

**GitLab and Auto DevOps**
Auto DevOps gives you a pre defined CI/CD configuration which lets you automatically detect, build, test, deploy and monitor your application. This is automatically enabled but you can disable it on Gitlab.

Example CI/CD pipeline: 

- https://gitlab.com/gitlab-examples/ruby-autodeploy

- https://gitlab.com/gitlab-examples/multi-project-pipelines/simple-maven-app

- https://youtu.be/0Tc0YYBxqi4

- https://gitlab.com/gitlab-examples


 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d9cdtwtcy79cumx3ba18.png)

**Publish your website with GitLab Pages**

- 
[How to Publish a Website with GitLab Pages](https://youtu.be/TWqh9MtT4Bg)

- [Deep Dive on Review Apps](https://youtu.be/HblSiPFamDI)