Кирилл Толкачёв — Релиз менеджмент с помощью Gradle

• Кирилл Толкачев из Альфа-Лаборатории рассказывает о своем опыте работы с Gradle.  

• Видео посвящено проблемам и решениям в области Gradle, а не релиз-менеджменту.  

• Обсуждение будет касаться написания и поддержки Gradle-скриптов.  

• Разработчики часто пишут скрипты Gradle по остаточному принципу.  

• Плохие Gradle-скрипты могут привести к частым исправлениям и проблемам.  

• Важно, чтобы скрипты были написаны качественно с самого начала проекта.  

• Разработчики должны уделять внимание Gradle-скриптам с самого начала проекта.  

• Важно не откладывать написание Gradle-скриптов на потом.  

• Стратегия успеха включает в себя планирование и укрепление позиций.  

• Проект начинается с установки Gradle и создания файла проекта.  

• Gradle-файлы описывают сборку проекта и содержат код на разных языках.  

• Gradle-рапер позволяет запускать Gradle без локальной установки.  

• Gradle генерирует файлы без версий, что создает проблемы с релиз-менеджментом.  

• Хранение версий в файлах требует синхронизации и коммитов, что неудобно.  

• Отсутствие тегов усложняет поиск нужных версий в репозитории.  

• Разработчики часто используют тактику "зерг краш", копируя решения проблем в Gradle-файлы.  

• Это неэффективно и приводит к частым исправлениям.  

• Важно понимать, когда и как использовать решения из интернета.  

• Использование Gradle для добавления тегов через Gradle.  

• Проблемы с изменением версии без коммита.  

• Возможность написания задач для добавления тегов и версий.  

• Задачи в Gradle делятся на секции: та дефинишн и дуласт.  

• Дуласт исполняется после та дефинишн.  

• Примеры написания задач и их секций.  

• Необходимость вычисления текущей версии из предыдущего тега.  

• Использование библиотеки Gradle для чтения текущего коммита.  

• Проблемы с чтением последнего коммита и добавлением тега.  

• Необходимость зависимости задач для корректной работы.  

• Проблемы с увеличением версии тега и логикой зависимостей.  

• Увеличение количества строк кода в Gradle.  

• Проблемы с поддержкой изменений, не закомиченных вовремя.  

• Необходимость добавления дополнительной логики для отрезания мастера.  

• Проблемы с масштабируемостью и поддержкой кода.  

• Проблемы с копированием и поддержкой кода другими разработчиками.  

• Необходимость разделения кода на маленькие скрипты.  

• Проблемы с порядком исполнения скриптов и кэшированием.  

• Проблемы с зависимостями и статичными скриптами.  

• Необходимость декларативного подхода для управления кодом.  

• Преимущества декларативного подхода для сложных проектов и масштабируемости.  

• Декларативность безопасна и легко поддерживается, но требует написания плагинов.  

• Проблема в том, что каждый плагин нужно настраивать, что усложняет процесс.  

• Решение: абстрагироваться от бездумного применения плагинов и научиться их компоновать.  

• Компоновка плагинов возможна только через создание своего плагина.  

• Пример: плагин, который применяет другие плагины в правильном порядке.  

• Это позволяет настроить таски и поведение плагинов.  

• Netflix создала набор плагинов под названием Nebula.  

• Nebula позволяет управлять версиями и следить за состоянием репозитория.  

• Пример: плагин для создания снапшотов и управления версиями.  

• Плагин проверяет, что изменения были запущены в репозиторий.  

• Это уменьшает количество ошибок и упрощает процесс.  

• Пример: создание и синхронизация тегов для релизов.  

• Travis CI позволяет собирать проекты на GitHub.  

• Пример: скрипт для сборки проекта при изменении кода.  

• Плагин помогает собирать снапшоты и релизы в окружении Travis.  

• Старый императивный подход к решению задач имеет свои плюсы, но требует контроля.  

• Инструмент для проверки Gradle скриптов помогает выявлять и исправлять ошибки.  

• Пример: плагин для проверки зависимостей и исправления ошибок.  

• Обсуждение одноразовых процедур и необходимости улучшения всех проектов.  

• Использование файла .gradle.d для глобальных настроек.  

• Пример применения плагина для всех проектов.  

• Файл .gradle.d позволяет хакать скрипты до их исполнения.  

• Пример использования плагина для проверки и исправления синтаксиса.  

• Плагин также удаляет ненужные зависимости.  

• Проблемы с использованием последних версий зависимостей.  

• Введение в Bower и Maven Bots.  

• Пример использования плагина для фиксации версий зависимостей.  

• Bots позволяют использовать последние версии зависимостей.  

• Пример использования плагина для фиксации версий.  

• Возможность откатывания изменений для отдельных зависимостей.  

• Плагин для фиксации версий зависимостей.  

• Возможность использования старых версий для определенных зависимостей.  

• Пример использования плагина для быстрого релиза.  

• Опасность настройки каждого плагина отдельно.  

• Использование универсального плагина для композиции других плагинов.  

• Возможность кастомизации плагинов для разработчиков.  

• Композиция плагинов как хорошая практика.  

• Переход от императивного к декларативному подходу.  

• Использование плагинов для кастомизации Gradle на разных машинах.  

• Удаление всех репозиториев в проекте и добавление доверенного.  

• Это обеспечивает безопасность, но может привести к падению сборки.  

• Разные подходы к безопасности и гибкости в зависимости от ситуации.  

• Инструменты не позволяют делать кастомизации и хаки.  

• Это защищает разработчиков, которые не готовы к изменениям.  

• Неправильные изменения могут привести к поломке билдов и продуктов.  

• Важно перестать быть зергом и сосредоточиться на коде.  

• Билд-скрипты пишутся по остаточному принципу.  

• Культура создания плагинов помогает разработчикам.  

• В Gradle нет встроенных решений для Git Flow.  

• Плагины на портале плагинов позволяют делать эксклуд веток и релизы.  

• Для реализации Git Flow нужно создавать собственные плагины.