Projekty DevOps do portfolio — trzy poziomy i co musi się w nich znaleźć

W portfolio DevOps nie liczy się aplikacja, tylko to, co dzieje się wokół niej: jak jest budowana, wdrażana, monitorowana i ile kosztuje jej utrzymanie. Rekruter nie szuka zrzutów ekranu z narzędzi, ale działającego procesu, który da się uruchomić i sprawdzić. Poniżej trzy poziomy projektów — każdy z zadaniem, obowiązkowymi artefaktami, kryteriami sprawdzenia i typowymi błędami.

Czym projekt DevOps różni się od projektu programisty?

Aplikacja może być prosta — wystarczy API z jednym endpointem. Ocenia się infrastrukturę i proces: pipeline, który naprawdę coś sprawdza, środowisko opisane kodem, kontener, monitoring, dokumentację oraz notatki o kosztach i bezpieczeństwie. Ogólne zasady porządnego repozytorium — README, historia commitów, profil — opisaliśmy osobno w tekście portfolio na GitHubie. Tutaj skupiamy się wyłącznie na tym, co musi dostarczyć projekt DevOps.

Trzy poziomy odpowiadają etapom z planu nauki DevOps od podstaw: kontenery i CI, potem chmura i Infrastructure as Code, na końcu orkiestracja i monitoring.

Poziom 1: aplikacja w kontenerze z pipeline'em CI

Zadanie: prosta aplikacja z bazą danych uruchamiana w kontenerach oraz pipeline, który przy każdym pushu buduje obraz i uruchamia testy.

Obowiązkowe artefakty: Dockerfile, plik docker-compose z aplikacją i bazą, konfiguracja pipeline'u CI, README z instrukcją uruchomienia jednym poleceniem.

Projekt jest gotowy, gdy:

• obraz buduje się na czystej maszynie według README,
• pipeline zatrzymuje zmianę, która psuje testy,
• w repozytorium nie ma haseł — konfiguracja idzie przez zmienne środowiskowe, a w repo jest tylko plik z przykładowymi wartościami.

Typowe błędy: obraz ważący ponad gigabajt, bo zbudowany na pełnym obrazie bazowym; hasło do bazy wpisane w docker-compose; pipeline, który niczego nie testuje, tylko wypisuje komunikat.

Poziom 2: środowisko w chmurze opisane kodem

Zadanie: ta sama aplikacja wdrożona do chmury przez Terraform oraz pipeline, który po zmianie w głównej gałęzi sam wdraża nową wersję.

Obowiązkowe artefakty: pliki Terraform, opis przechowywania stanu (state) w README, pipeline wdrożeniowy, notatka o kosztach — ile kosztuje środowisko miesięcznie i jak je wyłączyć — oraz notatka o bezpieczeństwie: uprawnienia i przechowywanie sekretów.

Projekt jest gotowy, gdy:

• usunięcie środowiska i ponowne utworzenie z kodu daje ten sam wynik,
• w repozytorium ani w historii commitów nie ma kluczy dostępowych,
• pipeline ma tylko te uprawnienia, których potrzebuje,
• koszt środowiska jest opisany, a środowisko da się wyłączyć jednym poleceniem.

Typowe błędy: klucze chmurowe w repozytorium albo w starym commicie; ręczne poprawki w konsoli, których nie ma w kodzie; środowisko zostawione włączone na miesiące.

Poziom 3: klaster z monitoringiem i alertem

Zadanie: aplikacja uruchomiona w Kubernetesie — wystarczy klaster lokalny — wdrażana przez pipeline, z monitoringiem i przynajmniej jednym alertem.

Obowiązkowe artefakty: manifesty albo chart Helm, dashboard z metrykami aplikacji, reguła alertu, runbook — co zrobić krok po kroku, gdy alert się odpali — oraz notatki o kosztach i bezpieczeństwie.

Projekt jest gotowy, gdy:

• aplikacja sama wraca po usunięciu poda,
• alert odpala się, gdy zatrzymasz aplikację — i sprawdziłeś to sam,
• dashboard pokazuje metryki Twojej aplikacji, a nie przykładowe dane,
• kontenery mają ustawione limity zasobów,
• runbook da się wykonać krok po kroku bez zgadywania.

Typowe błędy: dashboard skopiowany z przykładu bez własnych metryk; alert, którego nikt nie przetestował; brak limitów zasobów, przez który jeden kontener potrafi zająć cały węzeł.

Jak projekt ocenia rekruter albo prowadzący?

Osoba sprawdzająca zwykle przechodzi przez podobną listę:

• uruchamia projekt według README, bez pytania autora,
• przegląda historię zmian — widać, jak projekt rósł,
• szuka uzasadnień: dlaczego ten obraz bazowy, ten typ maszyny, ten próg alertu,
• sprawdza, czy autor rozumie koszty i ryzyka swojego środowiska,
• na rozmowie prosi, żeby pokazać, co się stanie przy awarii.

Jeden dopracowany projekt czy trzy?

Lepiej jeden projekt, który przeszedł przez wszystkie trzy poziomy, niż trzy porzucone w połowie. Historia repozytorium, w której aplikacja najpierw dostaje kontener, potem chmurę, a na końcu monitoring, sama w sobie pokazuje, że rozumiesz, po co każdy etap istnieje.

Chcesz budować takie projekty z informacją zwrotną od praktyka? Kurs DevOps prowadzi przez kontenery, CI/CD, Terraform, Kubernetesa i monitoring, a projekty trafiają do Twojego portfolio.