A Simple Guide for Beginners: Jenkins → GitLab → GitHub → GitOps

Hello!
Are you just starting your DevOps journey or tired of hearing “and we use CI/CD” in interviews? Want to finally understand why code that works on your laptop fails on the server?

This article is your first step toward automation. And it will really be easy.
We’ll break everything down, without overloaded terms and with examples.

What is CI/CD (very simple)

CI/CD is when you press git push and everything else happens automatically.

Let’s break it down:

Real-life example

You and a friend are building a website.

• Without CI: on Friday you try to merge code → hundreds of errors → goodbye weekend.
• With CI: every git push triggers tests → errors are visible immediately.

Tools: from “grandfather” to “trendy”

Jenkins — “the grandfather of CI/CD”

Jenkins is like an old but powerful industrial machine. You can make it do almost anything, but you’ll have to learn to live with it.

How it works

• You install Jenkins on a server
• You write instructions in a Jenkinsfile
• Jenkins watches Git and runs pipelines

Pros

• Maximum flexibility
• Thousands of plugins

Cons

• Maintenance, updates, and operations are on you
• The interface hasn’t changed in many years

For whom
Large companies or projects with historical baggage.

GitLab CI/CD — “all-in-one”

GitLab is not just a GitHub replacement. It’s a whole DevOps suite: CI/CD, Registry, monitoring, security.

How to get started in 5 minutes

1. Create a repository
2. Add the file .gitlab-ci.yml:

stages:
  - test
  - build

test:
  stage: test
  script:
    - echo "Запускаю тесты..."

build:
  stage: build
  script:
    - echo "Собираю Docker-образ..."

3. Do a git push — and the pipeline will start automatically.

Pros

• Nothing to deploy
• Everything in one dashboard: code → build → container → deploy
• Generous free CI minutes

Cons

• If the team is already on GitHub, migration can be difficult

For whom Teams that need everything out of the box.

GitHub Actions — CI/CD right inside GitHub

Have your code on GitHub? Then CI/CD is already waiting for you.

Create the folder .github/workflows/.

Example: run tests on every push

name: Тесты

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Запуск тестов
        run: echo "Тут мог бы быть pytest"

Pros

• Marketplace with a huge number of ready-made actions
• Free for public repositories
• Easy integration with clouds and services

Cons

• Minute limits for private repositories

For whom For everyone already using GitHub. The de-facto standard.

Runner — who runs the jobs

A pipeline is a recipe.
A runner is the chef who cooks from the recipe.

GitOps — the “Pro” level

GitOps is an approach where Git is the single source of truth.

Simple principle

• You change YAML in Git → the cluster updates automatically
• Manual kubectl apply → considered bad practice

Why it’s powerful

• Configurations are reproducible
• Logs and change history are always available
• The server always reflects the “state from Git”

GitOps tools

Which tool to choose

Set up your first pipeline (5 minutes)

1. Create a private repository on GitHub
2. Add the file .github/workflows/ci.yml:

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Привет, CI/CD! 👋"
      - run: echo "Тесты пройдены ✅"

3. Do a git push and open the Actions tab

Done — your first CI/CD is working.

Useful tips

1. Start simple: build → test.
2. Don’t store passwords in the repository — use Secrets.
3. Run deployments only from the main branch.
4. Pipelines should be short and clear.

Conclusion

You have already taken the first step.
Today — simple CI.
In a week — running tests.
In a month — building Docker images.
In six months — GitOps and automatic deployments.

CI/CD is not magic. It’s just automation of your usual development steps.
And you can definitely do it.