Comments 14
Насколько я знаю, для этого есть только две очевидных причины.
Совершенно непонятно, почему вы сначала исключили из рассмотрения основную причину - быстрое и по возможности безболезненное внесение в продукт нового функционала, а потом почему-то заявили ее как нечто, бывшее "много лег назад".
А откуда взялись изначальные определения? Это домыслы или есть фактура?
Я всегда понимал так, CI - мы часто сливаем изменения в общую ветку (интегрируем). Во времена, когда пол года могла идти разработка, а потом месяц интеграция в кодовую базу, это было революционной идеей.
CD - выпуск обновления занимает день работы инженера, а он ещё и косячит. Возможно выпускать релиз по нажатию одной кнопки тоже выглядит как чудо.
А что до выпуска недоделанного продукта, то тут решают не пайплайны, а сама возможность быстро доставить обновление. Это видно под играм. Пока игры были на дисках к багам относились серьёзно, потому что перевыпускать - дорого. Сейчас же игра выходит с багами и это стало нормой. И никакой CI/CD тут не виноват.
CD - выпуск обновления занимает день работы инженера, а он ещё и косячит.
вопрос в том что вы имеете ввиду под обновлением: новый дистрибутив, который надо установить, предварительно деинсталировав предыдущий?
Если мы говорим про серверные приложения, то ещё и миграция данных, которая может выполняться в несколько шагов и сборка и разворачивание новой версии перед удалением предыдущей.
Я когда-то собирал руками и обновлял на сервере службу Windows, которая занималась отложенной обработкой данных. Мне не понравилось.
На сервере обычно нет понятия деинсталировать. Если это на реальном железе, то просто обновляются нужные файлы и всё (могут обновиться все файлы бэка, как крайний вариант), а если это облако, то выкатывается новый образ нужного контейнера (насколько я понимаю).
На сервере обычно нет понятия деинсталировать.
просто насколько я понимаю деинсталяция это обратный процесс деплоймента и интеграции (установки). Если вы говорите что нет деинсталяции, я не уверен что этот случай можно рассматривать с точки зрения терминологии CI/CD, хотя все зависит от целей того кто вводит термины и определения.
То есть вопрос в том, что вы понимаете под деплойментом и интеграцией, потому что если выяснится что у вас просто нет этих процессов, то выяснится что вы автоматизируете что-то совсем другое и под CI/CD понимаете что-то совсем другое, соответственно.
выкатывается новый образ нужного контейнера (насколько я понимаю)
насколько я вижу вы как раз не вполне определились, что вы могли бы называть деплойментом и интеграцией, но при этом делаете какие-то обобщающие заключения.
Кстати контейнеры это достаточно новое поветрие, лет 10 назад никто про них не заикался, особо. Как же все работало тогда?
Я же написал в случае железа, как всё было тогда (облака тогда тоже не было).
Да, я говорю только про системы (обычно очень большие), которые используются внутри фирмы-разработчика или делаются субподрялчиком с доступом к ресурсами фирмы. Случаи быстрого (само)обновления десктопных/мобильных приложений - это ни разу не CI/CD.
В корпоративных же системах обновление обычно не имеет этапа деинсталяции. Остановить сервисы и программы, обновить файлы, запустить сервисы и программы. Всё.
Под CI/CD я понимаю стандартное определие из вики/инета.
В эрланге hot upgrade появился в конце 80-х и до сих пор успешно используется для раскатки новой функциональности без остановки приложения.
Мне кажется, Вы как-то узко рассматриваете программный продукт - как нечто уже завершённое и отлитое в граните. CI/CD пришли вместе с Agile, а Agile - это когда заказчик говорит "я не очень ясно представляю, что хочу, но я готов пробовать и платить за попытки".
И вот идёт поток мелких изменений "вот эту пимпочку сделаем красной", "вот тут поменяем текст".
Наверное, если в конце длинного пути оглянуться, то многие предыдущие итерации покажутся глупыми, кривыми или ненужными. Но именно они и привели к конечному результату.
Пайплайны служат для того, чтобы переложить на автоматику то, что делается руками и исключить человеческий фактор. Я могу 20 раз сделать похожие веши руками, а на 21-й ошибиться.
И вот идёт поток мелких изменений "вот эту пимпочку сделаем красной", "вот тут поменяем текст".
вопрос будет в общем то тот же что и чуть выше, но с учетом вашего контекста: вы считаете что для подобного рода изменений вполне нормально компилировать-собирать-упаковывать новый дистрибутив продукта, который надо установить, предварительно деинсталировав предыдущий? Вопрос то именно в этом, как вы собираетесь доводить (деливерить и интегрировать в его окружении) до заказчика такие мелкие изменения, неужели релиз на изменение каждой пимпочки выпускать?
Больше маленьких релизов, меньше больших проблем. CI\CD именно про то что мы часто и быстро доставляем новые фичи или фиксы на прод или в тестирование и избегаем множества проблем с конфликтами при больших сборках. Странно что автор не понял и не раскрыл эту истину!
Казалось бы, причем здесь Agile?)
Что такое CI/CD, и почему непрерывная? Темная сторона силы настоящего и воспоминания о прошлом