Comments 42
Итак, вы пишете код, отправляете его в главную ветку, ждете несколько минут и смотрите в продакшен. Все идет как надо? Или тут что-то не то?
Складывается впечатление что вы деплоите в продакшен приложение для заказа пиццы… Предположим что в результате бага в коде у вас при очередном деплое произошло необратимое повреждение данных в продакшен базе… А такое легко может случится т.к. автоматические тесты часто не могут проверить все возможные случаи или не имеют ровно такие же данные как на продакшен базе. Сколько времени займет автоматический откат таких изменений? Как много данных будет при этом потеряно? Вы точно хотите жить в ситуации когда в произвольный момент времени у вас может сложится прод? И при этом для каждой фичи на 1 строчку полезного кода вам приходится писать 10-100 строк тестового кода для того чтобы гарантировать стабильность прода.
Понятно, что такой подход весьма пригоден для какой-то stateless логики, для числодробилок всяких, без кучи внешних зависимостей.
Очевидно, что можно обложится кучей автотестов (включая интеграцинные), гейтов, аппрувалов и прочих предохранителей.
И, возможно, такой подход будет работать даже для сложных систем, если вы настроили сине-зеленый деплой, canary релизы, контейнеризацию и вот это вот все…
Но это все трудозатраты, и причем немалые. На проектирование всего этого добра, на автотесты (которые надо будет поддерживать наравне с функциональным кодом), на настройку и отладку пайплайнов, на перестройку рабочих процессов в команде (если это первый опыт), на рефакторинг существующего решения, дабы подстроить его под CD подход (вплоть до изменения архитектуры а-ля «давайте перепишем все на микросервисы»).
Вопрос всегда в эффективности/оправданности всех этих телодвижений.
Оправданны ли все эти трудозатраты для продукта с жизненным циклом в год-два?
Подходит ли весь этот аджайл для софта выполняющего критичные функции (захотели бы вы чтобы изменения приезжали таким образом в вашу ОС например?)
В общем, статья попахивает популизмом. Но за перевод спасибо.
По мне ответ: никак. Просто собирается вся команда в день Х и, судорожно сглатывая, нажимает на кнопку. А результат одинаковый: либо упадет, либо нет.
Разница как минимум в том что команда судорожно сглатывает только в день Х, а в случае CD ей приходится это делать каждый час при каждом пуше.
Время деплоя может быть выбрано так чтобы минимизировать ущерб в случае проблем (выходные и прочее нерабочее время), кроме того это в любом случае предсказуемый процесс, в отличии например от автоматического деплоя который может совершенно внезапно решить обновить контейнера в кубернетесе именно в момент пиковой нагрузки. CD процесс не содержит каких либо четко сформированных релизов, это значит что либо разработку нового функционала прийдется вести с фиче-флагами (что само по себе может быть нетривиальной задачей), либо же отдельные комиты которые вливаются в основную ветку будут очень большими и будут содержать сразу всю фичу целиком, что может затруднять процесс код ревью.
Из моей практики наиболее оптимальная схема когда CD работает автоматически на всех окружениях кроме прода, а прод допустим планово обновляется раз в 2 недели (и может внепланово обновляться в случае критических проблем)
в отличии например от автоматического деплоя который может совершенно внезапно решить обновить контейнера в кубернетесе именно в момент пиковой нагрузки
У нас с Вами разные представления об автоматическом деплое. У меня в голове автоматический деплой настроен правильно и обкатан и потому не может выполнять никаких «внезапных» действий.
У меня в голове автоматический деплой настроен правильно и обкатан
А могли бы Вы вкратце описать свой проект и инфраструктуру деплоя? А также сколько времени и средств ушло на настройку и обкатку правильного деплоя? И примерно сколько средств уходит на его поддержание в правильном состоянии?
недавно надо было в базе поменять модель — в mongo сильно поменялась структура одного Document-а… в итоге надо было атомарно поменять модель в одном микросервисе + DTO-шки на десятке других микросервисов на нескольких серверах и сами микросервисы проверить… сел ночью, аккуратно руками сделал, всё протестил. Интересно как фанбои CICD бы выкручивались )
Я все же думаю имелось в виду какой-то тестовый "прод".
Либо только из stable ветки.
В названии CI/CD явно указана цель методологии — continuous. Вы поправляете опечатку, пушаете в гит, и запускается CI-джоба/пайплайн. После чего она тянется, и тянется, и тянется, и оно continue, continue, continue… вы срезаете углы с целью получить результат хотя бы через пол-часа, но это приводит к взрыву сложности в сопровождении и вы отказываетесь от этого. А потом к вам приходят с ещё одним важным багом, который можно обнаружить, только если выполнить сценарий целиком, и вы добавляете ещё одну continue к своему continue, и надеетесь, что CI будет успевать отработать за ночь хотя бы раз, но к вам приходят с ещё одним сценарием....
Чтобы иметь возможность работать хоть как-то вы инвестируете в ресурсы, чтобы иметь возможность запускать два процесса в параллель. Но этого мало, и скоро у вас целая ферма серверов, которые непрерывно continue.
А если у вас не так, то
а) Вы не проверяете свой проект полностью (часть либо на аутсорсе у других компаний, либо вообще "мы про это не думаем")
б) У вас невоспроизводимая среда, либо среда зависящая от золотых артефактов.
А ещё вы, возможно, фулл-стек-божий-одуванчик, который думает, что JS+node — это и есть весь стек. А кто именно держит bgp с аплинками вы как-то и не думали.
А кто именно держит bgp с аплинками вы как-то и не думали.вот сейчас батя с подстанции придет со смены — расскажет, кто держит ваши bgp с аплинками :)
Но, если серьезно, то ИМХО у каждого должен быть свой горизонт видения, и только если мы начинаем говорить о техлидах-синьорах, тогда нужно вспоминать, что вообще-то никто не работает в вакууме и каждый стоит на плечах инфраструктуры.
А по теме CI\CD — то лично я считаю, что надо начинать с того, чтобы node watch (и прочие аналоги) выдавали Ok или Fail через секунды после нажатия на Ctrl-S (а не через 5 минут или больше, как иногда бывает), и тогда можно уже параллелить билды с деплоями.
Я про другое говорю. Одна из проблем в CI/CD — невероятное замедление feedback loop, неизбежное по мере увеличения покрытия тестами. Чем дольше этот loop, тем хуже процесс разработки. Чем дольше этот loop, тем лучше протестирован код.
Аренда сервера — 100 баксов в месяц. Хорошего сервера. Аренда программиста — over 5000. Очевидно, сервера дешевле.
Однако, не все процессы параллелятся. Более того, появление паралеллизации, совпадающее с добавлением всякого рода сценариев, часто лишь увеличивает время выполнения (за счёт wait for slowest и общей части).
А в единичном сценарии часто невозможно никаким образом ускориться, потому что слишком большой объём изменений; а любая попытка его сократить/кешировать приводит к золотым артефактам и не до конца уверенным в себе тестам.
Аренда сервера — 100 баксов в месяц.вот это вы наверно не про банкинг сейчас и не про медицину :)
В геймдеве когда поработал и то — была куча усилий по переводу билда+тестов на внешние сервера… (потому что цена риска — это как минимум зп менеджера, который это разрешил)
Более того, появление паралеллизации, совпадающее с добавлением всякого рода сценариев, часто лишь увеличивает время выполнения (за счёт wait for slowest и общей части).эээ… если у вас есть два теста, один самый медленный, а второй — побыстрее, то нет экономии времени от запуска их параллельно??? (я уж молчу, если там внутри бегает сотня тестов)
Как только у вас появляется параллелизация тестов, тут же возникает желание добавить сценарии. Поскольку билд закончен, когда закончен самый медленный из параллельных процессов, общее время вырастает.
Грубо говоря, был CI, фигачил час. Сделали второй сервер, стало можно пускать два сценария. Один сценарий фигачит 58 минут, второй 1 час 20 минут. Итого — CI фигачит час двадцать вместо часа.
Это как с дополнительными полосами на хайвее. Если уже пробка, то добавив полос, станет только хуже.
Но согласитесь, что без распараллеливания у вас был бы сценарий на 2 часа 18 минут вместо 1 часа 20 минут.
(ну или сборка была бы с меньшим покрытием тестами)
Без параллеливания никто бы не согласился на ещё +1.2 часа. В этом и драма CI. А когда есть горизонтальное масштабирование, то "почему бы и нет".
Вы можете показывать математику и объяснять что "параллельно быстрее", но у меня есть жизненный опыт. Начинаешь параллелить — становится медленее.
См про дополнительные полосы хайвеев.
А вот я бы почитал, обстоятельно, как вы с такими живёте. Мысль сделать часть тестов асинхронными у меня есть, но тут же как — если в CI всё зелёнькое, можно мержить/выкатывать. А если там на заднем плане Длинный Унылый Сценарий всё обсыпал и вопит, то к этому времени код уже на продакшене быть может.
А автоматические тесты — это для погромистов, когда свой код уже написал, а ревьювер его еще не посмотрел. К тому времени как досмотрит — добегают и «длинные сценарии».
У вас CD тогда нет.
… В целом, за всю мою карьеру, я один раз сделал идеальный CI/CD, который уже примерно 5 лет работает с минимальными изменениями, когда робот "всё сам" (включая апдейты из апстрима и публикацию в продакшен). Но там специальный случай и готовность ждать часами.
У вас CD тогда нет.
на препродакшен же.
PS: прямо в продакшен никто не разрешит все равно — банкинг, сэр!
Ну, это не CD.
И да, чаще всего есть Глубокие Причины, почему не CD. Я ж говорю, за всю свою жизнь у меня один раз получилось сделать "тесты прошло — годится на продакшен не глядя". И то, в очень специальном случае.
Есть команда, которая отвечает за этого робота. Если приходят (неожиданные) баги или странные фичи-реквесты, то они начинаются с красных тестов в CI, а заканчиваются зелёными. Как только тесты зелёные, происходит CD, без участия человеков. В силу того, что основная движущая сила изменений — это апстрим (не считая мелких багфиксов с нашей строны), CD работает по вторникам. Автоматически. (Ради этого и писалось).
(уж сколько раз ловил на том, что в коде Sum(a,b){return 5}, а в тестах assert(Sum(1,1)==5) )
К тому же команда, которая отвечает за процесс CD, все-таки не должна отвечать за чужой код и тесты.
Апстрим код всё равно тестировать надо (smoke тесты, хотя бы). Проект, про который я говорю — это обновление image'ей для cloud'а (они собираются из пакетов с нуля), чтобы они были актуальными, но при этом работали. Там огромная тестовая база с кучей неочевидных тестов (после plug/unplug интерфейс должен получить dhcp каждый раз, а не только первый и т.д.).
CD команда с тестами для "чужих" людей это нормально. Называются "приёмочные тесты".
Если у вас тесты разбиты на этапы, то обратную связь вы будете получать после каждого этапа. Зато это будет хорошая обратная связь, с известной достоверностью и предсказуемыми сроками.
И, разумеется, за вычетом линтеров, всё самое хорошее и важное будет прилетать уже в конце pipeline'а. Закон Мёрфи для CI/CD, всё такое.
C хорошим CI/CD вы гарантированно будете получать обратную связь не медленнее, чем без него. А уж если у вас самые ценные тесты — самые длинные, то это вопрос к тому, как вы тестируете, а не к процессу доставки.
В статье речь только про SaaS, я так понимаю.
В мире On-Premise правила игры немного другие.
Есть такая контора — GitLab (иронично упомянутая в статье), которая активно пытается быть лидером в CI/CD.
Релизные циклы — раз в месяц, 22го числа.
А знаете, что происходит в течение недели после их релиза?
Выход патчей )
Баннер «Update ASAP» в админке self-hosted гитлаба до конца месяца — это норма.
Ну и где теперь ваш CI/CD, а?
В целом разработчики понимают ценность непрерывной доставки. Многие из них мечтают работать в таком режиме.А потом удивляется, откуда берется мнение про «херак-херак и в продакшен».
Что-то не так с логикой, или фаза «выпустить продукт (пофиг какого качества) первыми» из сомнительной, но иногда, к сожалению, работающей практики переросла в фазу «теперь всегда так будет, ибо это хорошо»?
Согласен почти со всем.
Сейчас CI/CD нужен везде, просто потому что это довольно легко и удобно.
Сам занимаюсь разработкой прошивок.
CI собирает их, прогоняет тесты, прогоняет статический анализатор и публикует готовую прошивку для производства.
Но внедрено все это было слишком поздно из-за низкой квалификации руководства, поэтому на реальный процесс разработки оно повлияло слабо.
Мое мнение: если разработка прошивок в 2021 идет без тестов и CI, то это шуточная разработка. Скорее всего, собралось куча джунов с открытым дебаггером и делают вид что работают.
CI собирает их, прогоняет тесты, прогоняет статический анализатор и публикует готовую прошивку для производства.
И вот именно эта прошивка будет залита на следующее реальное устройство, собранное производством через 5 минут? Потому что если нет — то, по мнению автора, это нифига не СD
Да, CD нет, но думаю это решить смогут (но уже без меня). Как раз все это затевалось ради того, чтобы производство само могло подтягивать свежую версию прошивки, без перекидывания хексов в телеграме.
На мой взгляд, если после коммита прошивка автоматически не заливается в реальное устройство, на котором прогоняются хоть какие-нибудь тесты ее работоспособности (вроде проверки работоспособности uart хотя бы) то уже присутствует доля шуточности в разработки, ведь если это не делается автоматом, значит этим занят программист (или тестировщик). Вместо того, чтобы программировать.
Как можно автоматически релизить всё? Это предполагает, что маркетинга и продажников у вас в компании нет вообще и на рынок вам плевать.
Автор статьи: "Никто не имеет в виду (и не практикует) непрерывный деплоймент. Вообще никогда. О нем все забыли."
Читатели статьи:
P.S. Это кстати отлично показывает то, что необходимо приводить пруфы к таким заявлениям. Не "очевидно, что никто этим не пользуется", а "согласно опросам проведенными тем-то агенством 75% команд не знают что такое CI/CD и не используют его".
Такие нюансы показывают действительно хорошего автора)
CI/CD — обещания и реальность