Хоть уже не совсем среда, но тем не менее тема ci/cd сама себя не обсудит.
Поделюсь становлением ci/cd в альфе и некоторыми мыслями.
Интересно, используете ли вы ci/cd у себя в компании и кто развивает?
🤔
32.9% Да, силами devops команды🤔
61.8% Да, силами разрабы🤔
2.6% Нет, но в планах🤔
2.6% Нет, не дорослиВ своей практике встречал компании где не было CI/CD . За релизы отвечал "релиз менеджер" , в обязанности которого была сборка проектов двух платформ и публикация в Play/Store. Как правило, каждый релиз оборачивался адом.
Если , а это постоянно, сборка не собиралась на его компе он в панике начинал дергать разрабов, лидов, продактов с обвинениями сломанности кода или изменения процесса сборки без внесений в документацию (написанную специально для него)
Хотя по факту суть решения было в чистки gradle кеша либо обновлении студии.
Если в релизах находились runtime краши, то каждый раз этот ад повторялся. Про регулярность релизов и говорить не приходилось.
Из-за всяких подобных проблем или "договоренности" с продактами релизы с завидной частотой переносились. То есть фича , написанная в начале сентября , могла дойти до конечного пользователя только в октябре. Метрика TTM (Time-to-market) игнорировалась этим менеджером (
Кроме того релиз менеджер не прогонял таски по статическому анализу кода, кодстайл, тесты и их покрытия. От сюда были проблемы:
- не всегда соблюдение кодстайла
- детские баги в коде, которые бы подчеркнул статический анализатор
- низкое покрытие тестами
Это привело к тому что на одной из встреч разрабов были принято решение попробовать поднять Jenkins, по триггеру на ПР прогонять таски перед мержем в бренч. Вызвались несколько разработчиков, которые хотели развивать эту компетенцию. Осталось выбить ресурсы на сервер
Это оказалось сложнее. Доказать бизнесу необходимость вложить довольно приличную сумму денег на улучшение эфемерной метрики без прувов - было невозможно. Приняли решение заказать макмини ( для сборок и iOS прил там же ) и поднять на них сборку для прувов.
Через несколько месяцев у нас был поднят CI процесс. И даже добавили ручной триггер для менеджера для сборки релиз кандидатов. Этим мы вылечили проблемы со сборками, кодстайлом и тестами. Теперь менеджер не сам собирал сборки, а дергал триггеры. Но работы оставалось много
Работы много, но я как настоящий хохол, перешел в Альфу 🅰️ . Здесь уже было все серьезнее . Кластер серверов, ноды, построенный процесс релизных поездов и регрессионное тестирование.
В #Альфабанк и эта компетенция не страдала стагнацией. Дальнейшее развитие заключала в себе изолированные запусти пайплайнов в docker контейнерах с предустановленным Android SDK, внедрением gradle-cache, оптимизацией скорости сборок , через github.com/gradle/gradle-… сценарии
Плюс был добавлен скрипт который при деплое для тестирования в AppDistribution добавлял ченджлог из коммитов . В каждом ПРе и коммите разрабы ставят таску из jira . Таким образом в регрессе можно было легко найти автора фичи для быстрого фикса бага
Само существование ci/cd помогает поддерживать метрику ttm, решает проблему качества кода при интеграции новых фичей ( чекстайлы, линты, тесты в пайплайне) и избавляет от ручных сборок для тестирования.
Интересно узнать, какие у вас еще есть стейджи в пайпалайне? Делитесь
Виталий Раевский