What is Gitlab?

Gitlab is a web-based DevOps lifecycle management tool.

GitLab uses Git for version control — meaning you can track every change you or someone you’d like to blame has ever made.

It’s great because you can see who introduced the bug.

Gitlab Provides features like: -

1. CI/CD pipeline feature

2. Collaboration on code and project management

3. Monitoring and security tool Automates --> Build, test, deploy

CI/CD: -

In simple terms these are just lines of code that are written in a text file named “.gitlab-ci.yml” which helps in automation.

Professionally it is a method of frequently delivering apps to customers by introducing automation into the stages of app development.

CI/CD Pipelines are magical scripts that:

1. Work flawlessly when you don’t need them.

2. Explode when your manager is watching.

Fail with error messages that might as well say:

Something broke. Not telling you what. Figure it out. Good luck.

The best part?
You run it again and it passes.
For no reason.

CI → Continuous Integration

1. It means Build → Test → Merge
   Build the code in your text editor then test it locally and then push it to the branch which will have the pipeline that will perform testing and then merge to your main branch

2. This is about building and testing your code. Every time you push code or merge into a branch, GitLab automatically runs jobs like:

   1. Compile / Build

   2. Run tests

   3. Static code checks / linting

   4. Code quality / security scans

Goal of CI: Ensure code is correct, tested, and stable before moving forward.

Think of CI as "Does the code work?"

CD → Continuous Delivery/ Continuous Deployment

1. Continuous Delivery: -

   Code is packaged and ready for release, but someone should give the approval for deployment

   Requires manual approval

2. Continuous Deployment: -

   Code is automatically deployed to production whenever CI passes.

Goal of CD: - Deliver new features to users quickly and safely.

Think of CD as "Ship the working code to servers / cloud / production."

Example of CI / CD: -

Let’s say I am having a python project that performs some rocket science. Now if I will perform some actions on this python code …

1. Created a dev branch and made some changes to it.

2. Pushed code to dev branch

3. Then created a Merge Request → dev → main

4. When the merge happened, GitLab pipeline ran and generated your .exe artifact

Now, where is CI?

CI (Continuous Integration)

This is everything that happens when I am pushing code or create a merge request.
In my case:

• I pushed code to dev.

• Pipeline checks/builds the code.

• It compiles and creates .exe inside artifacts.

• It confirms "My code does not explode (yet)."

So, build + test + artifact creation = CI

CI = Making sure your code compiles and behaves before merging.

CD (Continuous Delivery / Deployment)

Now here’s the twist:

Did the .exe automatically get deployed or copied anywhere (like a server, environment, or production machine)?
Or did it just stay inside GitLab artifacts, waiting for someone to download it manually?

If the .exe is just created and stored →
→ This is only CI.
No deployment happened yet.

If pipeline automatically pushes the .exe to some server / environment →
→ That is CD.