Continuous Integration как практика

Наш эксперт, Андрей Александров, рассказал про практику непрерывной интеграции (Continuous Integration) на митапе сообщества DevOps Novosibirsk. Митап проходил онлайн в июне 2020 года и собрал более 200 представителей сообщества.

В выступлении рассмотрено:

1. Проблематика совместной работы с кодом и подмены развития практики внедрением инструментов, так называемый CI Theatre. В докладе на примерах показано, что установка Jenkins, GitLab CI или других CI-инструментов сама по себе не решает проблем интеграции. Основные сложности возникают из-за долгоживущих веток, редких слиянии, больших pull request и позднего обнаружения конфликтов, что приводит к росту затрат на интеграцию и снижению скорости работы команд;
2. Истоки появления практики и первое упоминание правила Integrate Often в методологии Extreme Programming (XP). Было отмечено, что проблема совместнои работы с кодом была осознана более 20 лет назад, и именно в XP появился принцип частои интеграции как способ снижения боли от конфликтов. Подчеркивалось, что Continuous Integration изначально задумывалась как инженерная практика работы с кодом, а не как автоматизация сборки;
3. Определение и принципы практики непрерывной интеграции (Continuous Integration). Continuous Integration была определена как стремление каждого инженера интегрировать свои изменения в общую ветку как можно чаще, в идеале несколько раз в день. Подчеркивалось, что речь идет о небольших изменениях, короткоживущих ветках или работе напрямую в trunk, ответственности разработчика за работоспособность мастера и быстром устранении проблем в случае падения сборки;
4. Использование практики в индустрии и подтверждение ее эффективности. В докладе были рассмотрены ключевые источники: книга The DevOps Handbook (Руководство по DevOps) как практическое руководство по внедрению CI, книга Accelerate (Ускоряйся! Наука DevOps)и исследование Accelerate State of DevOps 2018 как эмпирическое подтверждение корреляции между частой интеграцией и улучшением инженерных метрик. Также был разобран пример Long-lived branches with Gitflow, который находится в состоянии HOLD в технологическом радаре Thoughtworks, как иллюстрация проблем долгоживущих веток и дорогой интеграции;
5. Тест Continuous Integration Certification Test от Jez Humble и Martin Fowler как способ самопроверки наличия практики. Обсуждались критерии теста: ежедневное попадание кода в мастер, автоматическии запуск тестов на каждыи коммит и быстрое восстановление работоспособности мастера в случае падения сборки. Отмечалось, что тест не является догмой, но хорошо отражает суть практики и помогает отличить реальную Continuous Integration от формального использования CI инструментов;
6. Ответы на вопросы, связанные с внедрением и развитием практики. В ходе обсуждения были разобраны сложности декомпозиции больших задач, работа с длительными review, роль автоматизированных тестов и мониторинга, а также влияние практики на планирование и архитектуру. Подчеркивалось, что Continuous Integration требует изменении привычек, отказа от ручных согласовании и постепенного пересмотра существующих процессов, но в долгосрочнои перспективе снижает интеграционную боль и упрощает совместную работу команд.

Подробнее в статье и записи выступления:

Если вам интересно развитие инженерных практик и переход к Continuous Integration в вашей компании или команде, обращайтесь к нам за помощью.

Мы помогаем компаниям и руководителям оценивать, измерять и развивать инженерную культуру, процессы и практики, помогаем адаптировать модели и фреймворки под контекст, принципы и культуру компании, развиваем внутренние платформы и экспертные команды.

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы быть следить за состоянием в индустрии.