📘 BI-IDO – Úvod do DevOps

🔄 Co je DevOps a proč vznikl

Problémy, které DevOps řeší

• Při vývoji SW je nutná spolupráce více osob v různých rolích (zákazník, analytik/vývojář, administrátor) — každé předání informací/zodpovědností přináší riziko.
• Nasazení nové verze do produkce typicky znamenalo výpadek služby — provádělo se mimo pracovní dobu.
• Nasazení prováděl administrátor manuálně na základě podkladů od vývoje → zdlouhavé, chybové.
• Příčiny chyb mohly být na straně vývoje (chybějící skripty, konfigurace) i provozu (vynechání kroků, nezajištění závislostí).
• Tyto problémy vedly k omezování četnosti nasazování (např. jen 4× za rok).

Přínosy DevOps

• Zkrácení doby pro nasazení nové verze
• Minimalizace rizika vzniku chyby při nasazení
• Častější vydávání nových verzí
• Rychlejší vytváření/obnova prostředí

📝 Sdílení informací v týmu

Pro efektivní spolupráci je nezbytné sdílet informace — ne přes e-mail, ale přes online stránky dostupné všem členům týmu.

Co sdílet

• Základní informace o projektu, kontakty
• Zápisy ze schůzek
• Popis architektury / návrhů řešení

Jaké formáty a nástroje

• Značkovací jazyky: Markdown, AsciiDoc, HTML
• Rich Text / WYSIWYG editory
• GitLab wiki — integrovaná wiki, editace online v prohlížeči i lokálně (naklonováním git repo s wiki stránkami)
• Dokumenty ve formátu Markdown/AsciiDoc přímo v repository — GitLab je automaticky zobrazuje v HTML podobě

🎯 Správa úkolů a chyb (Issue Tracking)

Pomáhá vyřešit organizaci práce v týmu — evidenci, přidělování, plánování a kontrolu plnění úkolů.

Názvosloví (není sjednocené)

Různé systémy používají různé názvy: Ticket, Issue, Bug, Task

Evidované informace u úkolu

• Identifikátor (např. #123)
• Název a popis
• Milník (Milestone) — termín, do kterého má být úkol dokončen
• Priorita: blocker, critical, major, minor, trivial
• Severita — dopad na uživatele
• Typ: defect/bug, enhancement, task
• Závislosti mezi úkoly
• Odhadovaná pracnost a skutečně strávený čas
• Stav a způsob vyřešení

Specifické informace dle typu úkolu

• Chyba v produkci: použitý prohlížeč, OS, verze aplikace, postup pro reprodukci
• Záznam o testu: testovací scénář, prostředí

Většina nástrojů umožňuje rozšiřovat množství evidovaných informací a přizpůsobit workflow.

🔁 Typický životní cyklus úkolu/chyby

Z uzavřeného se může vrátit na Znovuotevřený (Reopened).

Způsoby vyřešení

🦊 GitLab Issue Management

V GitLabu se úkol nazývá Issue. Životní cyklus je zjednodušen na: open → closed.

• Lze rozšířit pomocí štítků (labels): assigned, in-progress, in-test, apod.
• Board (nástěnka) — přehled tiketů a stavů, rozšiřitelný o nové sloupce dle štítků; změna stavu přetažením (drag & drop).
• Priorita řešena formou prioritních štítků.

Odhadování a vykazování času

• Vkládání komentářů: /estimate 15m, /spend 5m, /remove_time_spent
• Jednotky: d (dny), h (hodiny), m (minuty), s (sekundy)
• GitLab automaticky sčítá a zobrazuje Spent vs. Est.

Automatické zavírání Issues pomocí commitu

• Popis commitu musí obsahovat Fix #id (např. Fix #121)
• Commit musí být začleněn do default větve (push / merge)
• Odkaz na issue pomocí #číslo

Milníky (Milestones)

Umožňují plánovat termíny dokončení úkolů. GitLab umožňuje sledovat jejich plnění — zobrazuje progress bar.

🛠️ Používané nástroje pro správu úkolů

📂 Správa a sdílení zdrojových kódů (SCM)

Hlavní přínosy verzovacích systémů

• Sdílení souborů v rámci týmu
• Verzování — kompletní historie každého souboru, možnost se vrátit k libovolné verzi
• Omezení rizika ztráty dat — možnost obnovy; pro ochranu proti ztrátě disku je nutný vzdálený repositář

Centralizované vs. distribuované systémy

Principy řešení spolupráce

🌿 Git Workflows — strategie větvení

Workflow = dohoda v rámci týmu, jakým způsobem se bude pracovat s větvemi v repository. Existují různé varianty, každá vhodná pro jiný typ projektu.

Git Flow

GitHub Flow

GitLab Flow

🧪 Typologie testů

Testování je klíčovou součástí zajištění kvality SW. Testy se dělí podle několika hledisek.

Podle úrovně / rozsahu

Podle účelu

• Funkční testy — ověřují, že aplikace dělá to, co má (správnost výstupů)
• Nefunkční testy — výkonové, zátěžové, bezpečnostní, testy použitelnosti
• Regresní testy — ověřují, že nová změna „nerozbila" existující funkcionalitu
• Smoke testy — rychlá povinná sada testů v CI, ověřující základní funkčnost
• Kvalifikační testy — kombinace automatických a manuálních testů před dodávkou

⬛⬜ Black Box vs. White Box testování

🤖 Automatizace testů

Cílem je zajistit opakovatelné a spolehlivé spouštění testů bez manuálního zásahu.

Princip AAA (Arrange – Act – Assert)

Příklad unit testu (Java + JUnit)

@Test
void shouldPassWhenValidPhoneWithPrefix() {
    // Arrange
    PhoneValidator phoneValidator = new PhoneValidator();
    // Act
    boolean valid = phoneValidator.validatePhone("+420 721 123 456");
    // Assert
    Assertions.assertTrue(valid);
}

Testovací dvojníci (Test Doubles)

Při unit testování potřebujeme izolovat testovanou jednotku od závislostí (databáze, externí služby). K tomu slouží testovací dvojníci:

• Stub — vrací předem definované odpovědi (nahrazuje skutečnou implementaci)
• Mock — kromě vracení odpovědí ověřuje, zda byla volána očekávaná metoda (verifikace interakce)

Příklad s mockem (Mockito)

@Test
void testDeliveryCreatedWhenOrderIsPaid() {
    // Arrange
    DeliveryService deliveryService = Mockito.mock(DeliveryService.class);
    PaymentService paymentService = Mockito.mock(PaymentService.class);
    OrderRepository orderRepo = Mockito.mock(OrderRepository.class);
    ShoppingService service = new ShoppingService(
        deliveryService, paymentService, orderRepo);
    Order dummyOrder = new Order(1);
    when(paymentService.isOrderPaid(1)).thenReturn(true);
    when(orderRepo.findById(1)).thenReturn(dummyOrder);
    // Act
    service.finishOrder(1);
    // Assert
    verify(deliveryService).createDelivery(dummyOrder);
}

🔍 Statická analýza kódu

Typy problémů, které odhaluje

1. Technický dluh (Maintainability)

• Neomezuje funkcionalitu, ale prodlužuje vývoj nových funkčností
• Nepoužívané importy, zakomentovaný kód
• Literály v kódu místo konstant (magic numbers)
• Příliš složitá větvení (špatná čitelnost, zdroj chyb)
• Nedodržování jmenných konvencí
• Nejčastější důvody: časový tlak, nedostatek zkušeností

2. Duplikace kódu – DRY princip

• Don't Repeat Yourself — při změně nutno upravit na všech místech
• ⚠️ Ne vždy je stejný kód porušením DRY — pokud spolu logicky nesouvisí, nejedná se o duplicitu (každý blok má jiný důvod ke změně)
• Duplikace dat: správné uložení v DB + pojmenované konstanty místo opakování literálu

3. Problémy se spolehlivostí (Reliability)

• Použití proměnné, která může být null
• Podmínky, které se vždy vyhodnotí jako true/false
• Nepoužité proměnné

4. Problémy se zabezpečením (Security)

• SQL dotazy sestavované spojováním stringů (SQL injection)
• Hesla uložená ve zdrojovém kódu
• Připojení do databáze bez hesla

SonarQube – hlavní nástroj

• Ukazuje aktuální stav i historický vývoj kvality
• Odděluje problémy v novém kódu vs. původním kódu (motivace pro vývojáře)
• Automaticky přiřadí problém autorovi dané části kódu (přes Git)
• 4 metriky: Security, Reliability, Maintainability, Security Hotspots

Quality Gates

• Podmínky minimální kvality — lze definovat kritéria nad novým i celkovým kódem
• Kritéria: pokrytí testy, duplikace, bezpečnost, spolehlivost, udržovatelnost
• Pokud projekt nesplní Quality Gate → build selže

Řešení nalezených problémů

• Fixed — opraveno přímo v kódu, uzavře se při další analýze
• False Positive — nejedná se o skutečný problém
• Won't Fix — problém není relevantní pro daný kontext

Další nástroje

FindBugs, PMD (Java), PHPStan (PHP), ESLint (JavaScript)

Spouštění

• Jako plugin v buildovacím nástroji: mvn sonar:sonar (Maven), Gradle, dotnet
• Jako samostatný CMD nástroj
• Konfigurace: sonar.host.url, sonar.projectKey, sonar.token

👁️ Code Review (Posouzení kódu)

Princip procesu

1. Autor vytvoří Merge Request / Pull Request
2. Přiřadí se reviewer (posuzovatel)
3. Reviewer přidává komentáře a návrhy na změny (suggestions)
4. Autor zapracuje připomínky nebo vyřeší v diskuzi
5. Po vyřešení všech připomínek se provede sloučení (merge)

🛡️ Zranitelnosti aplikací

OWASP TOP 10 (2021)

Další bezpečnostní databáze

• CWE (Common Weakness Enumeration) — obsáhlá databáze typů bezpečnostních problémů, TOP 25 zranitelností, detailnější než OWASP
• CVE (Common Vulnerabilities and Exposures) — zranitelnosti v konkrétních produktech/knihovnách

Kontrola zranitelností v knihovnách

• Bezpečnostní problém se může dostat do aplikace použitím zranitelné knihovny
• Kontrola probíhá automaticky při sestavení + v pravidelných intervalech (zranitelnost se může objevit i bez změny kódu)
• Nástroje využívají veřejné databáze známých zranitelností (CVE)
• Součástí závislosti by vždy měla být konkrétní verze — jinak nemusí být výsledek sestavení vždy stejný

NPM specifika verzování závislostí

• ^ (caret) — zachovává MAJOR verzi (povoluje MINOR a PATCH aktualizace)
• ~ (tilde) — zachovává MAJOR.MINOR verzi (povoluje jen PATCH)
• package-lock.json — obsahuje přesné verze použité při sestavení, musí se verzovat v Gitu → zajišťuje totožný výsledek na všech prostředích

OWASP Dependency Check

• Stahuje aktuální seznam známých zranitelností při spuštění
• Lze spouštět jako plugin pro Maven/Gradle nebo z příkazové řádky
• V pipeline hrozí překročení limitu stahování → řešení: lokální DB zranitelností + cache

🔄 CI/CD – Kontinuální integrace a nasazení

Problémy, které CI/CD řeší

• Různá vývojová prostředí → v CI probíhá sestavení na pevně definovaném prostředí → výsledek je vždy stejný
• Manuální kroky jsou zdrojem chyb → proces se popisuje skripty/konfigurací, které se verzují
• Spouštěné úlohy trvají dlouho → běží na samostatném serveru, nezatěžují počítač vývojáře
• Při problému je vývojář ihned notifikován (e-mail) a měl by problém okamžitě opravit

🏗️ Nástroje pro sestavení aplikace (Build Tools)

Umožňují připravit skripty pro automatické a opakovatelné sestavení. Odstraňují specifika prostředí každého vývojáře.

Společné vlastnosti

• Wrapper — malá binárka verzovaná se zdrojovým kódem → všichni používají stejnou verzi nástroje
• Správa závislostí — definice potřebných knihoven v konfiguračním souboru, automatické stahování z repository (veřejných i privátních)
• Stažené knihovny se ukládají lokálně (cache) — nestahují se opakovaně
• Součástí závislosti musí být specifikace konkrétní verze

Přehled nástrojů

⚡ Definice Pipeline

Struktura pipeline

• Skládá se z úloh (jobs/tasks/steps)
• Úlohy se seskupují do fází (stages)
• Fáze se spouštějí sekvenčně
• Úlohy v rámci jedné fáze se mohou spouštět paralelně
• Následující fáze se spustí až po dokončení předchozí

Spouštění pipeline

• Při změně kódu — repo notifikuje CI server, nebo CI server kontroluje repo v intervalech
• V pravidelných intervalech (scheduled) — např. kontrola zranitelností (CRON syntaxe)
• Automatické nebo manuální spouštění úloh (when: manual)

Důležité koncepty

• Proměnné (variables) — nahrazují hodnoty při spuštění, zamezují duplikaci, lze skrýt (security)
• Artefakty — výstupy úloh, sdílejí se mezi úlohami (jedna vytvoří balíček, jiná ho nasadí)
• Cache — úložiště pro závislosti/knihovny, které se opakovaně používají; řízena klíčem ($CI_COMMIT_REF_NAME pro větev, $CI_JOB_NAME pro úlohu). Sestavení musí fungovat i bez cache!

GitLab CI – konfigurace

• Uložena v souboru .gitlab-ci.yml v git repository (formát YAML)
• Termíny: Pipeline → Stage → Job
• Omezení spouštění na vybrané větve: only: [master]
• allow_failure — určuje, zda je dokončení úlohy vyžadováno pro úspěch pipeline
• Plánovač: CRON syntaxe (5 hodnot: minuty, hodiny, den v měsíci, měsíc, den v týdnu)

Nástroje pro CI/CD

GitLab CI, Jenkins, Bitbucket Pipelines, Bamboo, Circle CI, GitHub Actions

📦 Release Management

Sémantické verzování (SemVer)

Plánování release

• Zahrnují se pouze dokončené a otestované funkčnosti
• Plánování pomocí systému pro správu úkolů (milníky)
• Na úrovni kódu řízeno větvemi dle workflow — nová funkčnost nesloučena, dokud nemá být dodána

Feature Flag

• Umožňuje přidat do release funkčnosti, které zatím nebudou dostupné zákazníkovi
• Dostupnost řízena přepínačem za běhu aplikace
• Strategie: dle prostředí, pouze vybraným uživatelům, určitému procentu uživatelů
• V kódu = podmínky pro zpřístupnění funkčnosti
• GitLab: Deploy → Feature Flags

🖥️ Nasazení aplikace a správa prostředí

Nasazení aplikace

• Vyžaduje často nasazení více komponent (aplikace + databáze)
• Databáze je složitější — obsahuje data, která nesmí být ztracena; skripty nejsou opakovatelně spustitelné, změny nejsou transakční
• Řešení: Flyway, Liquibase — nástroje pro migrace DB

Flyway – typy migrací

• Verzované (V3__create_table.sql) — neopakovatelné, pro konkrétní verzi
• Undo (U3__create_table.sql) — pro návrat k předchozí verzi
• Opakovatelné (R__create_function.sql) — spouštěny vždy (procedury, funkce)
• Baseline (B2__create_database.sql) — úplné migrace pro nové prostředí
• Aktuální verze DB uložena v tabulce flyway_schema_history

Typy prostředí

Pravidla správy prostředí

• Jeden artefakt pro všechna prostředí (konfigurace je mimo aplikaci)
• Prostředí si mají být co nejpodobnější (čím blíže produkci, tím více)
• Minimalizovat manuální zásahy; neprovádět manuální změny na produkci
• Nemazat staré soubory, raději přesunout (snadný rollback)
• Izolace prostředí — zabránit přístupu testovacího prostředí k produkčním datům (emaily → MailHog, externí služby → Mocky/SoapUI)

Konfigurace specifická pro prostředí

• Zdrojové kódy nezávislé na prostředí
• Konfigurace společná = v aplikaci; specifická = mimo aplikaci (proměnné CI/CD, konfigurace nástrojů)
• Citlivé informace: šifrování, maskování, řízení přístupu
• Chráněné větve + chráněné proměnné + manuální potvrzení nasazení

Příprava testovacích dat

• Generování — náhodná/konstantní data, generátory reálných dat (Mockaroo)
• Anonymizace produkčních dat — slovníkové metody, mikroagregace; pozor na nedostatečnou anonymizaci (pole poznámka, dokumenty)

🐳 Kontejnerizace

Princip virtualizace

Technika abstrakce zdrojů počítače umožňující spuštění více kopií OS na jednom stroji. Ošetřuje: instrukční sadu, plánování procesů, správu paměti, periferie.

4 druhy virtualizace

VM vs. Kontejner

Kontejnerová primitiva (Linux)

• Namespaces (jmenné prostory) — oddělují PID, UID, souborový systém, síť
• Cgroups (kontrolní skupiny) — omezují CPU, paměť, I/O
• SELinux / AppArmor — zabraňují přístupu mimo kontejner
• Seccomp & Capabilities — omezují přístup k zařízením a práva root

Systémový vs. aplikační kontejner

• Systémový — celý OS, init démon, více procesů (LXC, OpenVZ, BSD Jails)
• Aplikační — pouze 1 proces, nejznámější: Docker

Přínosy kontejnerizace (Docker)

• Formát distribuce SW — nese všechny závislosti ve správných verzích
• Běží stejně ve všech prostředích (dev/test/prod) → řeší „Works on my machine"
• Vyšší hustota na serveru (menší režie než VM)
• Lepší využití paměti a místa na disku (sdílený FS, vrstvy)
• Pro administrátora: všechny aplikace vypadají stejně (nezáleží na jazyku)

Docker – klíčové koncepty

• Dockerfile — konfigurační soubor pro sestavení obrazu (FROM, RUN, COPY, CMD, EXPOSE, VOLUME, ENV, ENTRYPOINT)
• Vrstvy — každý řádek Dockerfile = jedna vrstva; sdílení a kešování vrstev šetří místo a šířku pásma
• Registry — repozitáře obrazů (Docker Hub, Quay.io, GitLab Container Registry, Nexus, Artifactory)
• Svazky (Volumes) — perzistentní data mimo vrstvený FS, nezávislé na změně kontejneru
• Docker Compose — definice a spouštění aplikací z více kontejnerů (compose.yaml, YAML), docker compose up/down

Integrace s CI

• Dockerfile součástí pipeline — automatické sestavení a push do registry
• Webhook na službu, která si stáhne kód a sestaví kontejner
• Pokročilé: Fabric8 plugin pro Maven, Tekton Pipelines pro Kubernetes