// Engineering Log
CI/CD: from "it worked on my machine" to automated deployment
Published on 2025-11-14
// Fast route
This article belongs to the topic Deploy and reliability.
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 pushand everything else happens automatically.
Let’s break it down:
| Abbreviation | What it means | Why it’s needed |
|---|---|---|
| CI (Continuous Integration) | Continuous integration | So code from different developers doesn’t break each other |
| CD (Continuous Delivery / Deployment) | Continuous delivery | So updates can be rolled out with one button — or without a button at all |
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 pushtriggers 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
- Create a repository
- Add the file
.gitlab-ci.yml:
stages:
- test
- build
test:
stage: test
script:
- echo "Запускаю тесты..."
build:
stage: build
script:
- echo "Собираю Docker-образ..."
- 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.
| Platform | Types of Runners |
|---|---|
| GitLab | Shared and Self-hosted |
| GitHub | Hosted (GitHub VMs) and Self-hosted |
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
| Tool | Description |
|---|---|
| Argo CD | A pretty dashboard. You can see Desired and Actual state. |
| Flux CD | Minimalist. Everything is managed via Git, almost no UI. |
Which tool to choose
| Situation | Choice |
|---|---|
| You store code on GitHub | GitHub Actions |
| You want everything in one place | GitLab CI |
| Complex historical infrastructure | Jenkins |
| Kubernetes + automation | GitHub/GitLab + Argo/Flux |
Set up your first pipeline (5 minutes)
- Create a private repository on GitHub
- 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 "Тесты пройдены ✅"
- Do a
git pushand open the Actions tab
Done — your first CI/CD is working.
Useful tips
- Start simple:
build → test. - Don’t store passwords in the repository — use Secrets.
- Run deployments only from the
mainbranch. - 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.
// Similar task
If you are dealing with something similar
This article belongs to one of the main working topics. You can keep reading on the topic, go to the homepage to understand what I do, or open the service pages directly.
Article topic
Deploy and reliability
Docker, CI/CD, releases, monitoring, observability, and incident handling.
Typical tasks behind this topic
- Set up deployment without manual chaos
- Add monitoring, alerts, and baseline observability
- Investigate incidents and stabilize production
// Next step
If you need help with this topic, not just another article, it is better to go straight to the service page. The homepage and topic collection stay available as secondary routes.
Open services// Reviews
Related reviews
I came with an expensive request to configure a VPS server, but during the consultation Mikhail suggested a much simpler, more affordable solution. In the end I saved time and money. Mikhail — a true expert who works for the client's result, not for the fee. I recommend him!
I came with an expensive request to configure a VPS server, but during the consultation Mikhail suggested a much simpler and more cost-effective solution. In the end I saved budget and time. Mikhail — a true expert who …
VPS setup, server setup
2026-05-12 · ★ 5/5
Excellent work! Set up the server very quickly, installed the control panel, and configured the IP. Definitely recommend!
Excellent work! Very quickly set up the server, installed the panel, configured the IP I can definitely recommend it!
Everything was excellent; helped promptly and professionally. Thank you — I recommend them to the community.
Everything's great, helped promptly and professionally, thank you, I recommend it to the community
VPS setup, server setup
2026-04-16 · ★ 5/5
There were several issues concerning both the technical side and overall understanding. Mikhail responded quickly, resolved the technical problems, and helped me understand them — many thanks. I'm satisfied with the result.
There were several issues concerning both the technical side and overall understanding. Mikhail responded quickly to the request, helped sort things out and resolved the technical problems and helped clarify …
VPS setup, server setup
2026-02-18 · ★ 5/5
Everything was done quickly and efficiently. I recommend.
Everything was done quickly and efficiently. I recommend.
VPS setup, server setup
2026-01-17 · ★ 5/5
Everything went well; the contractor responded quickly to questions and helped resolve the issue. Thanks!
Everything went well, the contractor responded quickly to questions and helped resolve the issue. Thank you!
VPS setup, server setup
2025-12-16 · ★ 5/5
// Contact
Need help?
Get in touch with me and I'll help solve the problem
// Related