Environment
Логічна ціль deployment у GitHub Actions, яка може мати власні protection rules, variables і secrets та обмежувати доступ до них.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Pages artifact
Artifact зі статичними файлами сайту, який передається deployment job для публікації через GitHub Pages.
2. Практика та написання пайплану CI/CD →Спроєктувати місце запуску тестів
Намалюйте DEV/STG topology і позначте, чи доступні середовища з публічного інтернету.
Виберіть hosted або self-hosted runner і зафіксуйте причину.
Розділіть конфігурацію на repository variables, environment variables і secrets.
Назвіть один ресурсний або access blocker до інтеграції suite в deployment path.
Від build до deployment
Типовий delivery flow складається з отримання dependencies, компіляції або збирання застосунку, створення Docker image, завантаження versioned artifact до Artifactory чи іншого registry та deployment конкретної версії на середовище. Збережені версії дають змогу не просувати несправний build і повернутися до попереднього артефакту. Різні jobs можуть виконуватися на різних runners: один збирає застосунок, інший запускає system tests, третій виконує scheduled processing. Спеціалізація корисна, коли потрібні різні доступи або ресурси, але додає черги й інфраструктурні обмеження.
Публікація report у GitHub Pages
Окрема publish job завантажує artifacts, створені smoke/regression jobs, готує Pages artifact і виконує deployment. Artifact є мостом між runners: файл, створений однією job, не з’являється автоматично на машині іншої job. У repository settings джерелом Pages обирається GitHub Actions, а environment `github-pages` отримує правила deployment, сумісні з task branches. Наприкінці workflow ще має test failures, тому урок завершується чесною межею: механізм pipeline і Pages показано, але конкретні нестабільні тести потребують подальшого розбору.
Моноліт, модульний моноліт і мікросервіси
У моноліті business logic, email, SMS, persistence та integrations розгортаються як один application. Це не є автоматично погано: добре структурований моноліт простіший у розробці і не платить network latency за кожен внутрішній виклик. Модульний моноліт розділяє functionality всередині одного deployment і може зберігати окремі data boundaries. Мікросервісна архітектура виносить ці частини у незалежні services, але додає HTTP, serialization, handshakes, deployment і distributed failure modes.
Коли інтегрувати автотести в CI
Теза «тести без CI нікому не потрібні» занадто категорична. На ранньому етапі локальний запуск поруч із розробником може дати швидший і корисніший feedback, особливо коли deployment pipeline, runners або доступи ще нестабільні. Спочатку команда має довіряти тестам і вміти швидко зрозуміти причину падіння за report, trace, screenshot чи video. Довгі або нестабільні suites не можна бездумно ставити на критичний шлях hotfix deployment: зайняті runners і нестача ресурсів створять чергу для всієї команди. CI-інтеграцію варто нарощувати після того, як визначено мету набору, тривалість, стабільність і місце його запуску.
Генерація і публікація Allure report
Pipeline успішно збирає smoke results, генерує Allure static site і публікує його через GitHub Pages. Початкове посилання повертає 404 через неправильний path; після переходу до фактичного deployment path report відкривається й показує tests та додані steps. Це корисне нагадування: зелена publish job доводить, що deployment завершився, але не доводить, що користувацький URL правильний. Посилання на report треба відкрити окремою перевіркою.
Створення workflow та умови запуску
Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.
Динамічні значення та пошук за частиною атрибута
За стандартом `id` має бути унікальним, але деякі frontend-фреймворки генерують до стабільної частини випадковий суфікс. Повне значення такого `id` може змінитися після нового deployment або навіть між сесіями. CSS дозволяє шукати за точним значенням або за стабільним фрагментом: ```css [id="sort-block-123"] [id*="sort-block"] [class*="text-area"] ``` Оператор `*=` означає «атрибут містить цей текст». Частковий збіг має бути достатньо специфічним, інакше локатор знайде кілька елементів.
Системна перевірка, інфраструктура й плато продуктивності
Системні тести дають сигнал не лише про бізнес-логіку. Вони можуть виявити, що health check бекенду зелений, але UI не працює через gateway, неправильну конфігурацію або несумісні версії фронтенду й бекенду. Це окремий клас ризику, який unit- та інтеграційні тести не закривають. AI-інструмент може прискорити написання регресійних тестів і фідбек розробникам, але цей ефект не обов’язково зростає нескінченно. У великому продукті підтримка наявного коду та впровадження нових змін із часом знову стають складнішими. Одна з причин — недетермінованість LLM: той самий запит у новому чаті може дати інший код. Команда мусить перевіряти результат, стабілізувати робочі інструкції та не плутати швидку генерацію з гарантованою коректністю.
Швидка перевірка реального масштабу досвіду
Якщо кандидат описує CI pipeline, parallelization, sharding, self-hosted runners і підготовку database state перед deployment, окреме базове опитування синтаксису може не додати сигналу. Натомість interviewer просить пояснити, як саме було реалізовано рішення, які trade-offs виникли й що кандидат робив особисто.
Один product engineer може закрити широкий vertical slice
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.