Загрузка данных

Задание 1. Словарь терминов CI

Термин Определение
Непрерывная интеграция (CI) Практика разработки, при которой разработчики регулярно (несколько раз в день) объединяют свои изменения в общий репозиторий, после чего автоматически выполняются сборка и тестирование.
Сборка (Build) Процесс автоматического преобразования исходного кода в рабочий программный продукт (компиляция, упаковка, создание артефактов).
Юнит-тест Проверка отдельных компонентов (модулей) программы на корректность работы.
Линтер Инструмент для проверки стиля кода и выявления потенциальных ошибок (например, ESLint, PyLint, Flake8).
Пайплайн Последовательность автоматических этапов (шагов), которые выполняются CI-системой после каждого пуша в репозиторий (checkout, установка зависимостей, линтинг, сборка, тесты и т.д.).
CI-раннер Агент (виртуальная или физическая машина), который выполняет задачи CI-пайплайна.
Артефакт Результат сборки, сохраняемый после выполнения пайплайна (например, JAR-файл, отчёт о тестах, логи).
Красная сборка Неудачный запуск CI: сборка или тесты завершились с ошибкой.
Зелёная сборка Успешный запуск CI: все этапы (сборка, тесты, линтеры) прошли без ошибок.
Покрытие кода тестами Процент исходного кода, который проверяется автоматическими тестами (рекомендуемое значение > 80%).

---

Задание 2. Сравнительный анализ CI-систем

Критерий Jenkins GitLab CI GitHub Actions
Тип установки Self-hosted (на свой сервер) Self-hosted / SaaS (облачная) SaaS (облачная)
Сложность настройки Высокая Низкая Низкая
Язык конфигурации Groovy (или через GUI/плагины) YAML (.gitlab-ci.yml) YAML (.github/workflows/*.yml)
Бесплатная версия Да (open source) Да (ограничения для SaaS, бесплатные раннеры для open-source) Да (публичные репозитории бесплатно)
Для каких проектов подходит Enterprise, крупные проекты, legacy-системы, когда нужны специфические плагины Компании, использующие GitLab (от маленьких до крупных) Open-source проекты на GitHub, небольшие и средние компании

Вывод:

· Для open-source проекта я бы выбрал GitHub Actions, потому что он бесплатен для публичных репозиториев, прост в настройке, имеет огромный маркетплейс готовых actions и тесно интегрирован с GitHub.
· Для корпоративного проекта — Jenkins, так как он даёт полный контроль над инфраструктурой (self-hosted), имеет более 1800 плагинов и подходит для сложных legacy-систем со специфическими требованиями.

---

Задание 3. Проектирование CI-пайплайна (Python + Django)

Этап 1: Checkout — получение кода из репозитория (Git, ветка main).
Этап 2: Установка зависимостей — pip install -r requirements.txt (примерное время: 1–2 минуты).
Этап 3: Линтинг — запуск Flake8 и Black для проверки стиля кода (≈30 секунд).
Этап 4: Сборка — проверка синтаксиса Django (например, python manage.py check), сбор статики (≈30 секунд).
Этап 5: Юнит-тесты — запуск pytest для проверки отдельных компонентов (≈2–5 минут).
Этап 6: Интеграционные тесты — проверка взаимодействия модулей, возможно с тестовой БД (≈3–5 минут).
Этап 7: Отчёт о покрытии — вычисление процента покрытия кода тестами (должно быть ≥80%, иначе сборка красная).
Этап 8: Сохранение артефактов — отчёты о тестах, покрытии, логи (несколько секунд).

Общее время пайплайна: ≈7–13 минут (желательно уложиться в <10 минут, можно распараллелить линтинг и тесты).

---

Задание 4. Анализ преимуществ CI (ситуация с командой из 5 разработчиков)

1. Проблемы текущего процесса:
   · Ручное и редкое (раз в неделю) объединение кода, занимающее 2–3 часа.
   · Конфликты при слиянии из-за долгой изоляции изменений.
   · Тесты запускаются вручную и часто падают, требуя переделок.
   · Разработчики боятся пушить изменения.
   · Ошибки обнаруживаются через неделю после внесения.
2. Как CI решит каждую проблему:
   · Автоматическая сборка и тесты при каждом пуше — не надо ждать неделю.
   · Частые маленькие слияния → конфликты возникают реже и проще разрешаются.
   · Автоматический запуск тестов — человек не забывает их выполнить.
   · Быстрая обратная связь (5–15 минут) — ошибка видна сразу, страх снижается.
   · Ошибки выявляются на раннем этапе (в 10–40 раз дешевле исправления).
3. Экономия времени:
   · Сейчас: объединение раз в неделю × 2–3 часа = 8–12 часов в месяц.
   · При CI: слияние занимает минуты (автоматически), разрешение конфликтов — редко. Плюс экономия на ручном запуске тестов. Команда сэкономит минимум 10+ часов в месяц.
4. Какие метрики улучшатся:
   · Время сборки (станет <10 минут вместо часов).
   · Частота отказов (снизится с неизвестной до <5%).
   · Время восстановления (с дней до <1 часа).
   · Покрытие тестами (повысится, т.к. CI требует тестов).
   · Частота коммитов (будет несколько раз в день на человека).
5. Психологическое состояние команды:
   · Страх перед пушем исчезнет — разработчики станут увереннее.
   · Прекратится «интеграционный ад» — слияние станет рутиной.
   · Повысится дисциплина (чаще коммитить, писать тесты).
   · Команда будет получать быструю обратную связь и меньше отвлекаться на рутину.

---

Задание 5. Анализ CI-метрик

Данные:
Всего сборок: 200
Успешных: 160
Неудачных: 40
Среднее время сборки: 25 минут
Среднее время восстановления: 3 часа
Покрытие тестами: 45%
Частота коммитов: 2 раза в день на разработчика

Расчёты:

1. Процент отказов сборки = (40 / 200) × 100% = 20% → плохо (целевое <5%).
2. Время сборки = 25 минут → плохо (рекомендация <10 минут).
3. Покрытие тестами = 45% → плохо (рекомендация >80%).
4. Частота коммитов = 2 раза в день → норма (цель: несколько раз в день, 2 — приемлемо, но можно увеличить).

Рекомендации (что улучшить):

1. Снизить время сборки до <10 минут — распараллелить этапы, использовать более мощные раннеры, кэшировать зависимости.
2. Уменьшить процент отказов — стабилизировать flaky-тесты, улучшить качество кода через линтеры.
3. Повысить покрытие тестами до >80% — дописать тесты для критических модулей, ввести требование к новому коду.
4. Улучшить время восстановления — автоматизировать откат, настроить быстрые уведомления и чёткий процесс фикса красных сборок (цель <1 часа).
5. Стимулировать более частые коммиты (до 3–5 раз в день) — обучить команду, уменьшить размер изменений.