Коротка відповідь
juniorCI/CD — це процес автоматизації розгортання коду, що включає CI (Continuous Integration) і CD (Continuous Delivery/Deployment). Він дозволяє швидко, без помилок та з мінімальним ручним втручанням доставляти нові функції до продакшн‑середовища.
Повне пояснення
Що це і навіщо
CI/CD — сукупність практик, що об’єднують автоматичне збірку, тестування та розгортання застосунків. Це зменшує час від коміту до релізу, підвищує якість коду і знижує ризик людських помилок.
Ключові принципи
- Continuous Integration: кожен коміт інтегрується в спільну гілку, запускаються unit‑тести та статичний аналіз.
- Continuous Delivery: після успішної CI збірка готова до розгортання, але реліз в продакшн може бути ручним.
- Continuous Deployment: розгортання в продакшн відбувається автоматично після проходження всіх тестів.
Як це працює
- Пуш коду в репозиторій (Git).
- CI‑система (наприклад, GitHub Actions, GitLab CI, Jenkins) запускає пайплайн: lint, build, unit‑тести.
- Якщо всі етапи успішні, створюється artefact (Docker‑image, .jar, .zip).
- CD‑система розгортає artefact на staging/production (Kubernetes, AWS ECS, Heroku).
Практика й реалізація
- GitHub Actions:
on: push,jobs: build-test-deploy. - GitLab CI:
.gitlab-ci.ymlзstages: build, test, deploy. - Jenkins: Pipeline script з
stage('Build'),stage('Test').
Тестування
- Unit: Jest, Mocha для JavaScript; JUnit для Java.
- Integration: Prisma migrations + test DB, TypeORM with SQLite in memory.
Оптимізація запитів
- Використовувати кешування (Redis), pagination, індекси.
- Підключати
EXPLAINдля складних SQL‑запитів.
Безпека
- Secrets: зберігати в CI‑системі, не в репозиторії.
- RBAC: обмежити доступ до пайплайнів.
Особливості в контексті DevOps
- Infrastructure as Code: Terraform, CloudFormation.
- Observability: Prometheus + Grafana для моніторингу пайплайнів.
Часті помилки
- Необхідність ручного підтвердження в CD.
- Відсутність тестів → збій розгортання.
- Неправильне налаштування secrets → витік даних.
- Переважання CI без CD → повільний реліз.
- Невикористання rollback‑плану.
- Перенавантаження сервера через часті деплої.
- Відсутність canary‑релізу → повний збій.
- Неправильна конфігурація Docker‑image → неуспішний старт.
Cheatsheet
git push origin main→ тригер CI.docker build -t app:latest .kubectl apply -f deployment.yaml