Мне тут попалась статья по теме, которая начинается с такого определения:
Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.
Как по мне, то с самого начала нас пытаются если не подло обмануть, но ввести в заблуждение. Как вы думаете, почему разработчикам нужно чаще вносить-развертывать изменения программного обеспечения? Насколько я знаю, для этого есть только две очевидных причины.
По-моему, это определение очень отличается от того что понимали под подобными терминами лет, скажем, 20 назад.
Так как вы думаете, почему разработчикам нужно чаще вносить-развертывать изменения программного обеспечения? Вот две причины, которые кажутся мне очевидными:
программное обеспечение изначально выпущено в очень сыром виде, то есть в недоделанном, недотестированном, непродуманном, с большими пробелами в базовой, необходимой для пользователя функциональности
либо все перечисленное в предыдущем пункте было сделано хоть и в полном объеме, например в полном соответствии с каким-то заданием, но совершенно формально и с таким низким качеством, что в программном обеспечении присутствуют все виды ошибок, которые только можно вообразить, вплоть до опечаток, когда некоторые точные константы записаны не совсем точно, или где-то пропущена обработка очень редких, но жизненно важных ветвей логики, или логика построена так, что она допускает существование каких-то тупиковых ветвей, которые ломают или подвешивают работу всего приложения… (этот список можно продолжать бесконечно), и все эти ошибки присутствуют в программном обеспечении в огромных количествах, например за счет многократного дублирования кусков кода подобной функциональности, применения разных библиотек-пакаджей для реализации однотипной логики в разных частях приложения.
То есть в любом случае основная работа объявляется как бы сделанной с как бы небольшой оговоркой: теперь, когда мы все сделали в основном, мы приступаем к увлекательному процессу улучшения того, что мы сделали! Согласитесь, звучит максимально позитивно. Кто же откажется от улучшения да еще и непрерывного-продолжительного. Это глобальная проблема индустрии современных программных продуктов — это засилие эффективных менеджеров, которые не просто могут или стремятся вас обмануть или, на жаргоне, «развести на бабки», нет! Эти эффективные менеджеры искренне верят в то, что они несут в мир ИТ доброе-лучшее-вечное, никто же не скажет вам, что он вам впарил совершенно сырой продукт, для которого вам придется оплачивать непрерывное и фактически бесконечно продолжающееся исправление ошибок, восполнение-корректировку отсутствующей или неадекватно спроектированной функциональности. Проблема в том, что вам не расскажут о проблемах не потому, что вас хотят обмануть, нет! Вам не расскажут о проблемах, потому что их уже давно не принято замечать в приличном ИТ-сообществе. Вас будут совершенно искренне убеждать, что это самые лучшие и самые прогрессивные практики и принципы и даже целая культура, будут убеждать с такой искренней внутренней убежденностью что вы постесняетесь задать очевидные вопросы, которые также очевидно могут разрушить этот прекрасный мир непрерывного улучшения в ИТ. Можно например задаться такими, очень простыми вопросами: "А почему нельзя сразу сделать так, чтобы не надо было очень часто улучшать?", "Разве необходимость частых улучшений (исправлений?) сама по себе не является признаком плохой надежности / отсутствия надежности?"
Как было в древние времена
Но я еще помню времена когда у этих понятий Continuous Integration-Continuous Delivery не было красивой раскрученной аббревиатуры. Но был непреходящий смысл. В чем же находили практический смысл древние профессионалы ИТ?
Пусть вам нужно создать и поддерживать приложение, не важно, сетевой клиент или локальный текстовый редактор. Приложение всегда состоит из какого-то фронт-енда и набора функций, которые вызываются с этого фронт-енда, если, конечно, это не единственная функция, которая запускается при вызове из консоли. Чтобы исправить логическую ошибку или некорректность поведения некоторой пользовательской функции необходимо и достаточно иметь такую структуру (архитектуру?) этого приложения, чтобы вся реализация этой пользовательской функции была локализована в отдельной библиотеке или в скрипте, который загружается при выборе определенного действия на пользовательском интерфейсе приложения. Таким образом, если мы могли бы подложить-поменять библиотеку (файл со скриптом), мы могли бы исправить любую такую архитектурно-локализованную функцию.
Я, конечно, утрированно упростил способ обеспечить такого рода обновление программного продукта, на самом деле такую технику обновления и соответствующий способ построения приложений очень сложно реализовать на практике, но примеры есть, и штука в том, что эти примеры буквально всем очень хорошо известны. Мне кажется, дело в том, что эффективные менеджеры давно осознали, что не способны воспроизвести эти примеры в применении к своим задачам, и поэтому выбрали путь построения своей альтернативной реальности, в которой просто не надо задаваться определенными вопросами.
Но вернемся к простому примеру, заметьте, это точно соответствует понятиям Continuous Integration- Continuous Delivery, ведь мы, однажды установив наше приложение, по сути, запустили бесконечный процесс, который позволяет нам в любое время заменить компонент этого приложения (будь то скрипт или библиотека), без того чтобы сносить это приложение и устанавливать его по новой, то есть поставка компонент и их интеграция с уже работающим приложением может действительно осуществляться в любое время. То есть смысл непрерывности не в том, что мы постоянно, все чаще и чаще, исправляем какие-то ошибки в уже развернутом приложении, смысл непрерывности в том, что мы непрерывно имеем возможность исправить вновь обнаруженные ошибки, а в более продвинутых системах еще поддерживается возможность расширять существующий пользовательский интерфейс (фронт-енд) и добавлять новые пользовательские функции в приложение без переустановки всего приложения. Например, чтобы добавить функцию проверки орфографии в уже установленный текстовый редактор, нам не надо переустанавливать текстовый редактор. Нам надо скачать (выполнить Delivery) и установить соответствующее расширение проверки орфографии (произвести интеграцию) поверх уже установленного приложения, то есть, по сути, выполнить действия продолжающие изначальную первичную установку этого приложения.
Если что, я совершенно не против того, чтобы продолжать называть CI/CD pipeline-ы – CI/CD пайплайнами, это уже устоявшаяся терминология, я просто хочу напомнить, что эта терминология изначально имела немного другой смысл.