Как известно, разработчики регулярно деплоят софт.
Помню, как раньше деплой был событием. Все к нему по особому готовились. Предупреждали пользователей. Писали большую доку про новую версию.
Так же помню, как все такие деплои оборачивались регулярными провалами. База фризилась. Юзеры не могли залогиниться. Kernel panic. Непонятно откуда растущий LA. Седеющий админ. Курящий одну за другой сигареты тимлид.
Спустя какое-то время инженеры поняли, что деплоить нужно регулярно, лучше даже после каждого пуша. Помимо этого, деплоить нужно так, чтобы большую часть деплоев юзеры не замечали. У них просто чинится какой то баг и они счастливы. Либо появляется новая фича, которую они, как водится, не замечают, а потом узнают про нее в блоге проекта.
Такая штука называется “Непрерывная поставка ПО”. И мне кажется, что сейчас большая часть веб-ориентированного / микросервисного / облачного софта поставляется именно так. Это стало настолько обычным, что мы буквально за 5–6 лет активного использования непрерывной поставки (ну, ок, почти непрерывной) свыклись с тем, что это единственно правильный способ деплоев.
Недавно мне нужно было обновить одного бота, который стабильно, каждый день, вот уже два года шлет в Слак статистику по сервису. В какой-то момент он начал спотыкаться об один дата сорс и рядом с валидной информацией были HTTP 404. Я подумал, что могу просто закомментировать один вызов и ничего не сломается.
Отыскал репозиторий, открыл код. Начал вспоминать что там есть. Даже прогнал тесты и они прошли. Все очень позитивно. Закомментировал ненужный мне вызов и собрался деплоить.
И тут случилось интересное. Я где-то на подкорке, где-то глубоко внутри, начал чувствовать странный запах. Вот бывает, смотришь на код и он плохо пахнет (это значит, что его трудно читать, а следовательно, и поддерживать). А тут готовишься деплоить и понимаешь, что деплой протухший. Понимаете? Колбаса есть, а жрать ее страшно. Чувствуете? Вроде масло сливочное стояло в морозильнике, а через пол года вытащил и на хлеб намазывать не хочется.
Устоявшееся понятие Code Smell можно было и применить к этому случаю, назвав его Deploy Smell. Но я бы назвал Deploy Smell тот деплой, который свежий, но воняет. То есть просто криво сделан, но софт деплоят регулярно. В нашем же случае сам акт поставки достаточно адекватен, просто он прогнил от долгого не использования.
Предлагаю вводить понятие “протухший деплой” или Addled Deploy. Это ситуация, когда нужно перестраховаться перед тем деплоем, который долго не производился. Ситуация, когда все-таки делаешь тухлый деплой и не страхуешься будет называться “тухлить”.
Например, можно не тухлить днем пятницы, а сделать это в понедельник утром, когда все девопсы напились кофе и никуда не собираются уходить. А это значит, что они смогут помочь откатить деплой, если все развалится.
Addled deploy situation. Так можно озаглавить ворклог, в котором разработчики опишут все то, что им пришлось пережить после тухлого деплоя в продакшен.
UPDATE от Vadim Glebov:
Знакомая ситуация. У меня в проекте пока не CD, поставки в бой раз в 2 недели, поставка полуавтоматическая (админ запускает скрипты из пакета поставки вручную и смотрит на выхлоп). Но чтобы деплой не протухал интеграционка крутит поставку на демо 3 раза в день в автоматическом режиме. При таком подходе реальный деплой в продакшен проходит без проблем. Потому что я успеваю обнаруживать проблемы с поставкой рано и сразу их устранять. Короче чтоб деплой не протухал крути его, хотя бы в тестовом режиме.
Ранее статья была опубликована тут.