AnnaMiller
New member
Привет, форумчане. Хочу поделиться опытом, который заставил меня по-другому взглянуть на наш процесс релиза. Работаю я в маленькой продуктовой команде: четыре разработчика, один тестировщик, иногда подключается продакт. Выделенного DevOps-инженера у нас нет и никогда не было, поэтому все релизы долгое время делались руками.
Долгое время мне казалось, что это нормально. Собрать ветку, прогнать тесты локально, залить артефакт на сервер, поправить конфиги, перезапустить сервисы, проверить логи, написать в общий чат, что версия выкачена. Ну, час, ну, два. Пока однажды я не решил честно замерить, куда уходит это время.
Я завёл привычку фиксировать каждое действие при релизе с точностью до десяти минут. Через шесть релизов набралась статистика: в среднем девяносто минут на подготовку, сорок минут на само выкатывание и ещё около часа в разные дни на разбор последствий. Итого примерно три с половиной часа в неделю на человека, а в релизную ночь подключались двое или трое. В пересчёте на деньги это оказывалось дороже, чем мы думали: несколько человеко-часов каждую неделю, которые не приносят продукту ничего.
Но самое неприятное не эти часы, а скрытые издержки. Пока я деплою, я не пишу код. Возвращаясь к задаче через час, я трачу ещё минут двадцать, чтобы снова в неё погрузиться. Мы старались релизить вечером, чтобы никто не пострадал, и это убивало вечера. А ещё был страх: если релиз делает только один человек, то его отпуск или болезнь превращаются в стихийное бедствие.
Перелом случился после случая, когда мы полтора часа искали причину падения. Оказалось, на одном сервере забыли обновить переменную окружения. Обидно не то, что ошиблись, а то, что ошибка была повторением уже виденной раньше. Именно тогда мы решили: каждый повторяющийся шаг должен стать скриптом, чек-листом или частью автоматического конвейера.
Мы не строили сложную инфраструктуру. Начали с малого: перенесли сборку и тесты в непрерывную интеграцию, написали пошаговый чек-лист релиза, где каждый пункт можно отметить галочкой, а ручные команды заменили парой скриптов. Через пару месяцев ручных релизов почти не осталось: нажатие кнопки, ожидание конвейера, проверка ключевых сценариев. Стоимость часа ручного релиза стала видна не только в календаре, но и в том, сколько полезного мы успеваем сделать за освободившееся время.
Что я советую читателям. Во-первых, просто начните считать: без цифр разговор о деплое превращается в спор о вкусах. Во-вторых, ищите шаги, которые вы делаете больше двух раз в месяц, и автоматизируйте их по одному, а не всё сразу. В-третьих, сделайте так, чтобы релиз мог выполнить любой член команды, а не один незаменимый герой. И в-четвёртых, не гонитесь за идеальной инфраструктурой: маленький скрипт сегодня лучше архитектурной мечты через год.
А теперь вопрос к вам, друзья: сколько времени уходит на релиз в вашей команде и какой один шаг вы автоматизировали первым, о чём до сих пор не жалеете? Уверен, у каждого есть приём, который сэкономил ему не один вечер. Поделитесь — будет интересно собрать общую копилку.
Долгое время мне казалось, что это нормально. Собрать ветку, прогнать тесты локально, залить артефакт на сервер, поправить конфиги, перезапустить сервисы, проверить логи, написать в общий чат, что версия выкачена. Ну, час, ну, два. Пока однажды я не решил честно замерить, куда уходит это время.
Я завёл привычку фиксировать каждое действие при релизе с точностью до десяти минут. Через шесть релизов набралась статистика: в среднем девяносто минут на подготовку, сорок минут на само выкатывание и ещё около часа в разные дни на разбор последствий. Итого примерно три с половиной часа в неделю на человека, а в релизную ночь подключались двое или трое. В пересчёте на деньги это оказывалось дороже, чем мы думали: несколько человеко-часов каждую неделю, которые не приносят продукту ничего.
Но самое неприятное не эти часы, а скрытые издержки. Пока я деплою, я не пишу код. Возвращаясь к задаче через час, я трачу ещё минут двадцать, чтобы снова в неё погрузиться. Мы старались релизить вечером, чтобы никто не пострадал, и это убивало вечера. А ещё был страх: если релиз делает только один человек, то его отпуск или болезнь превращаются в стихийное бедствие.
Перелом случился после случая, когда мы полтора часа искали причину падения. Оказалось, на одном сервере забыли обновить переменную окружения. Обидно не то, что ошиблись, а то, что ошибка была повторением уже виденной раньше. Именно тогда мы решили: каждый повторяющийся шаг должен стать скриптом, чек-листом или частью автоматического конвейера.
Мы не строили сложную инфраструктуру. Начали с малого: перенесли сборку и тесты в непрерывную интеграцию, написали пошаговый чек-лист релиза, где каждый пункт можно отметить галочкой, а ручные команды заменили парой скриптов. Через пару месяцев ручных релизов почти не осталось: нажатие кнопки, ожидание конвейера, проверка ключевых сценариев. Стоимость часа ручного релиза стала видна не только в календаре, но и в том, сколько полезного мы успеваем сделать за освободившееся время.
Что я советую читателям. Во-первых, просто начните считать: без цифр разговор о деплое превращается в спор о вкусах. Во-вторых, ищите шаги, которые вы делаете больше двух раз в месяц, и автоматизируйте их по одному, а не всё сразу. В-третьих, сделайте так, чтобы релиз мог выполнить любой член команды, а не один незаменимый герой. И в-четвёртых, не гонитесь за идеальной инфраструктурой: маленький скрипт сегодня лучше архитектурной мечты через год.
А теперь вопрос к вам, друзья: сколько времени уходит на релиз в вашей команде и какой один шаг вы автоматизировали первым, о чём до сих пор не жалеете? Уверен, у каждого есть приём, который сэкономил ему не один вечер. Поделитесь — будет интересно собрать общую копилку.