1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн

Для запуску Python-тестів у CI потрібно відтворити ті самі базові дії, що й локально: отримати код, встановити Python і залежності, окремо встановити браузери Playwright, запустити lint/format checks та потрібний набір тестів. pipeline описує весь процес, а stage, job і step — його менші етапи; точна вкладеність і назви залежать від GitHub Actions, GitLab CI, Jenkins, TeamCity, Bamboo чи іншої системи.

Найпоширеніший декларативний формат — YAML. Він дає змогу зберігати pipeline поруч із кодом і однаково описувати послідовність команд, образ середовища, залежності між jobs та умови запуску без окремої мови програмування для кожного CI-продукту.

CI-інтерфейс не виконує тести сам: GitHub або інша система передає job конкретному runner. Це окрема машина чи контейнер, який має отримати репозиторій, інструменти, конфігурацію та мережевий доступ до системи під тестом.

Hosted runner з публічного інтернету може не бачити DEV/STG, доступний лише через VPN або приватну мережу. Тоді потрібен self-hosted runner усередині інфраструктури або інше узгоджене мережеве рішення. Тому питання «де запускатимуться тести?» треба вирішувати разом із доступами, credentials і topology, а не після написання workflow.

Типовий delivery flow складається з отримання dependencies, компіляції або збирання застосунку, створення Docker image, завантаження versioned artifact до Artifactory чи іншого registry та deployment конкретної версії на середовище. Збережені версії дають змогу не просувати несправний build і повернутися до попереднього артефакту.

Різні jobs можуть виконуватися на різних runners: один збирає застосунок, інший запускає system tests, третій виконує scheduled processing. Спеціалізація корисна, коли потрібні різні доступи або ресурси, але додає черги й інфраструктурні обмеження.

Теза «тести без CI нікому не потрібні» занадто категорична. На ранньому етапі локальний запуск поруч із розробником може дати швидший і корисніший feedback, особливо коли deployment pipeline, runners або доступи ще нестабільні. Спочатку команда має довіряти тестам і вміти швидко зрозуміти причину падіння за report, trace, screenshot чи video.

Довгі або нестабільні suites не можна бездумно ставити на критичний шлях hotfix deployment: зайняті runners і нестача ресурсів створять чергу для всієї команди. CI-інтеграцію варто нарощувати після того, як визначено мету набору, тривалість, стабільність і місце його запуску.

Runner повинен отримати base URLs, users, passwords, tokens та інші параметри без commit у репозиторій. У GitHub Actions значення можна зберігати як repository secrets/variables або прив’язувати до environments на кшталт DEV, STG і PROD. Environment-level значення зручні, коли ті самі ключі мають різні значення та правила доступу для різних середовищ.

На реальному проєкті права на створення або зміну secrets можуть належати не автоматизатору. Це окрема залежність від власників репозиторію чи DevOps-команди, яку треба з’ясувати заздалегідь. Для малого набору параметрів не потрібно будувати складну config-систему: достатньо найпростішого контрольованого scope, який не розкриває секрети.

Repository-level secrets доступні workflow всього репозиторію, тоді як environment secrets можна обмежити конкретним оточенням і його protection rules. Workflow явно посилається на потрібні значення, тому конфігурація стає частиною контракту запуску, але самі секрети не з’являються у YAML.

Кожну job варто уявляти як чистий контейнер або машину на базі визначеного image, наприклад ubuntu-latest. Наступне практичне відео показує, як на такому runner послідовно виконати checkout, setup, install і tests.