CI/CD dla małego projektu webowego - idea i mini-pipeline

Cel prezentacji

Co przekazesz słuchaczom?

Po tej prezentacji słuchacze będą w stanie:

Zrozumiec różnicę miedzy CI a CD
Wiedzieć dlaczego automatyzacja jest ważna
Zaprojektowac prosty pipeline dla projektu webowego
Zrozumiec podstawowe etapy: lint, test, build, deploy
Unikac typowych błędów (np. sekrety w repo)

Plan prezentacji (8-12 min)

Wprowadzenie (2 min)
- Co to jest CI/CD i dlaczego warto
- Problem: “reczne wdrazanie jest meczace i podatne na błędy”
- Historia: od ręcznego deploy do automatyzacji
CI - Continuous Integration (3 min)
- Automatyczne sprawdzanie jakosci
- Lint, testy, build
- Kiedy uruchamiać (push, PR)
CD - Continuous Delivery/Deployment (2 min)
- Automatyczne wdrazanie
- Środowiska: dev, staging, production
- Różnica: Delivery vs Deployment
Mini-pipeline w praktyce (3 min)
- Przykład dla prostego projektu
- GitHub Actions / GitLab CI
- Sekrety i bezpieczeństwo
Podsumowanie (2 min)
- Korzyści z CI/CD
- Pytania i dyskusja

Kluczowe zagadnienia

CI vs CD - różnicę

Continuous Integration - automatyczne sprawdzanie jakosci kodu przy każdej zmianie.

Co robi:

Uruchamia testy automatyczne
Sprawdza formatowanie kodu (lint)
Buduje aplikacje
Sprawdza czy kod się kompiluje

Kiedy: Przy każdym pushu lub Pull Request

Dlaczego CI/CD?

Bez CI/CD

Reczne uruchamianie testow
“U mnie działa” - błędy na produkcji
Długie deploy przez FTP
Strach przed zmianami
Konflikty przy merge

Z CI/CD

Automatyczne testy przy każdym pushu
Szybkie wykrywanie błędów
Deploy jednym kliknieciem
Pewnosc jakosci
Czeste, małe zmiany

Etapy pipeline

Typowy pipeline CI/CD

Etap	Co robi	Przykład
1. Checkout	Pobiera kod z repo	`git clone`
2. Install	Instaluje zależności	`npm install`, `composer install`
3. Lint	Sprawdza formatowanie	`eslint`, `phpcs`
4. Test	Uruchamia testy	`phpunit`, `jest`
5. Build	Buduje aplikacje	`npm run build`, `webpack`
6. Deploy	Wdraza na serwer	`rsync`, `ssh`, `docker`

Sugestie wizualne

Slajd 1: Pipeline - schemat

+--------+    +--------+    +--------+    +--------+    +--------+
| Commit | -> |  Lint  | -> |  Test  | -> | Build  | -> | Deploy |
+--------+    +--------+    +--------+    +--------+    +--------+
    |             |             |             |             |
    v             v             v             v             v
 [Git]        [ESLint]      [PHPUnit]    [Webpack]     [Serwer]

Jeśli ktorys etap FAIL --> Pipeline STOP --> Powiadomienie

Slajd 2: Środowiska

+----------------+    +----------------+    +----------------+
|  Development   | -> |    Staging     | -> |   Production   |
+----------------+    +----------------+    +----------------+
| - Lokalne      |    | - Kopia prod   |    | - Użytkownicy  |
| - Testy dev    |    | - Testy QA     |    | - Realne dane  |
| - Szybkie zmiany    | - Pre-release  |    | - Stabilnosc   |
+----------------+    +----------------+    +----------------+

Slajd 3: GitHub Actions - workflow

on: push           # Kiedy uruchomić
jobs:
  test:            # Nazwa job
    runs-on: ubuntu-latest
    steps:
      - Checkout   # Pobierz kod
      - Install    # Zainstaluj zależności
      - Lint       # Sprawdz formatowanie
      - Test       # Uruchom testy
      - Build      # Zbuduj aplikacje
      - Deploy     # Wdraz (opcjonalnie)

Demo praktyczne

Przykład 1: Prosty workflow GitHub Actions

name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'

      - name: Install dependencies
        run: composer install

      - name: Run linter
        run: composer run lint

      - name: Run tests
        run: composer run test

Przykład 2: Pipeline z deployem

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          composer install
          composer run test

  deploy:
    needs: test  # Czekaj na testy
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
        run: |
          echo "$SSH_KEY" > key.pem
          chmod 600 key.pem
          rsync -avz -e "ssh -i key.pem" ./public/ user@server:/var/www/app/

Przykład 3: Plik konfiguracyjny GitLab CI

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - composer install
    - composer run lint
    - composer run test

build:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

deploy:
  stage: deploy
  only:
    - main
  script:
    - rsync -avz dist/ user@server:/var/www/app/

Przykład 4: Sekrety - bezpieczne przechowywanie

# DOBRZE - uzywanie sekretow
env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

# ZLE - nigdy nie rob tego!
env:
  DATABASE_URL: "mysql://user:password@localhost/db"  # NIEBEZPIECZNE!
  API_KEY: "sk-1234567890abcdef"  # NIEBEZPIECZNE!

Przykład 5: Prosty skrypt deploy (bez CI)

#!/bin/bash
# deploy.sh - prosty skrypt deploymentu

echo "Starting deployment..."

# 1. Pobierz najnowszy kod
git pull origin main

# 2. Zainstaluj zależności
composer install --no-dev

# 3. Zbuduj assety
npm run build

# 4. Wyczysc cache
php artisan cache:clear

# 5. Uruchom migracje
php artisan migrate --force

echo "Deployment complete!"

Warianty wymagan

Wymagania minimalne:

Wyjaśnienie CI i CD (różnica)
Pokazanie 1 schematu pipeline
Podanie 2 przykładów kontroli jakosci (lint, test)
Omowienie dlaczego automatyzacja jest ważna

Ocena: 3.0 (minimum)

Checklista CI/CD

Co sprawdzić przy konfiguracji?

Czy pipeline uruchamia się automatycznie?
Czy testy sa uruchamiane przed deploy?
Czy sekrety sa przechowywane bezpiecznie?
Czy pipeline FAIL zatrzymuje deploy?
Czy jest powiadomienie o błędach?
Czy można łatwo zrobic rollback?
Czy dokumentacja jest aktualna?
Czy środowisko staging jest podobne do prod?

Bezpieczeństwo w CI/CD

Sekrety i tokeny

NIGDY nie wrzucaj do repozytorium:

Haseł i tokenow API
Kluczy SSH
Plikow .env z produkcyjnymi danymi
Certyfikatow SSL
Connection stringow do baz danych

Uzywaj:

GitHub Secrets / GitLab CI Variables
Vault (HashiCorp)
Environment variables na serwerze
.gitignore dla plikow wrazliwych

Pytania do dyskusji

Pytanie 1

Czym rozni się Continuous Delivery od Continuous Deployment?

Pytanie 2

Co się stanie jeśli test FAIL w środku pipeline?

Pytanie 3

Dlaczego sekrety nie powinny być w kodzie?

Pytanie 4

Jak zrobic rollback jeśli deploy się nie udał?

Typowe błędy do unikniecia

Podpowiedzi do prezentacji

Narzedzia CI/CD

Zalety:

Zintegrowane z GitHub
Darmowe dla publicznych repo
Duży marketplace akcji
Łatwy start

Dla kogo: Projekty na GitHub

Zasoby

GitHub Actions Documentation Oficjalna dokumentacja GitHub Actions.

GitLab CI/CD Documentation Oficjalna dokumentacja GitLab CI/CD.

CI/CD Concepts (MDN) Podstawowe pojecia CI/CD.

OWASP: Secrets Management Bezpieczne przechowywanie sekretow.

The Twelve-Factor App: Build, Release, Run Dobre praktyki deploymentu.

GitHub Actions Marketplace Gotowe akcje do wykorzystania w pipeline.