В наши дни непрерывную интеграцию (CI) и непрерывную доставку/развертывание (CD) легко воспринимать как нечто само собой разумеющееся, но это были революционные концепции, радикально изменившие облик разработки программного обеспечения за последние тридцать лет. Хотя многие призывают к более строгому следованию передовым методам разработки программного обеспечения в области машинного обучения (ML) и искусственного интеллекта (AI), сегодняшним практикам ML по-прежнему не хватает простых инструментов и рабочих процессов для управления жизненным циклом развертывания ML на уровне инженеров-программистов. . В этой статье мы отправимся в путешествие по памяти, чтобы изучить преимущества набора инструментов CI/CD и недостатки их досадного отсутствия в современном жизненном цикле разработки машинного обучения.
Краткая история CI/CD
Непрерывная интеграция во многом связана с работами Grady Brooch (Метод Brooch) и Kent Beck (Extreme Programming — к сожалению, так и не попала в X Games) в начале 90-х. Если мы сможем телепортироваться в то время, надеть фланелевые и рваные джинсы Levi, выпить кристально чистую пепси и заиграть под Nevermind группы Nirvana, мы обнаружим бурно развивающуюся технологическую отрасль, идеально подходящую для взрыв из-за появления всемирной паутины и доступных персональных компьютеров. Это прекрасное время для того, чтобы стать разработчиком программного обеспечения, так как ваши навыки пользуются большим спросом, ваш работодатель полон денег (не будем забывать о веселых временах, предшествовавших пузырю доткомов), а проникновение программного обеспечения в большинстве отраслей, поэтому наткнуться на идею на миллион долларов лишь немногим сложнее, чем подстрелить рыбу в бочке. Однако довольно сложной задачей является написание программного обеспечения. Или, по крайней мере, написание программного обеспечения, которое работает.
Жизнь разработчика программного обеспечения до появления CI/CD была крайне насыщенной из-за большого разрыва между разработкой и производством. В частности, можно было легко разрабатывать код локально в среде IDE, но перевод кода в «рабочее состояние» часто требовал много времени и терпения. Программное обеспечение на сегодняшний день является самой сложной вещью, созданной человечеством, и когда несколько человек одновременно работают над самой сложной вещью, которая когда-либо была создана, неизбежно возникает множество проблем. Например:
- После того, как вы закончите свою классную новую функцию и объедините ее обратно с основным проектом, вы обнаружите, что кто-то еще внес несколько правок в части кода, которые вы изменили. Получайте удовольствие от разрешения конфликтов слияния!
- Кроме того… вы обнаружите, что многие основные библиотеки, на которые опирается продукт, изменились. Добро пожаловать в интеграционный ад!
- Кроме того… тесты, которые вы выполняли локально в своем коде, больше не работают. Пытаясь понять, почему, вы понимаете, что кто-то изменил все тесты, чтобы учесть новую функциональность. Наслаждайтесь проведением всех выходных, обновляя и повторно запуская тесты!
На самом деле… это просто чудо, что в наше время хоть какое-то программное обеспечение работает. Это даже не относится к кошмару развертывания обновлений программного обеспечения. Не было ничего необычного в том, что программное обеспечение получало обновления только один раз в год или даже реже, и содержало так много изменений кода, что неизбежно было полно ошибок. Мы также предполагаем, что работа с исходным репозиторием — это простой и безошибочный опыт, что также не всегда имело место.
Brooch & Beck разработали более разумные методы, которые заложили основу для CI. Ключевым наблюдением является то, что чем дольше вы развиваете свою ветку вдали от основной, или «главной», ветки, тем сложнее будет слить ваши изменения. Таким образом, идеально вместо этого сосредоточиться на гораздо более мелких изменениях, где каждое из них не сильно влияет на систему и их легче объединить. Разработчики должны делать это много раз в день или «постоянно». Затем сервер CI отвечает за компиляцию кода, выполнение всех тестов и, при непрерывном развертывании, создание артефактов и их развертывание в рабочей среде. Как только инженеры-программисты передают свой код в исходный репозиторий, система CI/CD автоматизирует все остальное. Прошли времена трудоемких ручных процессов, и теперь инженеры-программисты могут уделять гораздо больше времени просто написанию кода.
Потребовалось примерно два десятилетия, чтобы CI/CD действительно влилась в экосистему. CruiseControl (2001 г.) был ранним инструментом CI с открытым исходным кодом, и к 2011 г. все стало довольно популярным с выпуском Jenkins и CircleCI и более или менее сближением с общепринятыми передовыми практиками:
- Версия и мониторинг всего
- Совершайте сделки рано и часто
- Автоматизируйте сборки и тесты
- Дополнительные выпуски
- Автоматизировать развертывание
В конце концов, CI/CD дает командам разработчиков программного обеспечения разумный способ создания продукта, который сводит к минимуму количество «неинтересных» вещей, которые вам приходится делать: конфликты слияния, отладка проблем с зависимостями, исправление сломанных сборок и т. д. Это (относительно) просто. чтобы точно определить, что не так и почему такие решения (относительно) быстрые, и это также открывает огромные улучшения производительности и качества жизни для разработчиков. Настолько, что любой опытный разработчик не хотел бы даже утруждать себя принятием работы в компании, в которой еще не было этих практик (если, конечно, они не являются инженером №1 в стартапе и не будут создавать его сами). .
CI/CD и машинное обучение
Если вы занимаетесь искусством машинного обучения, вы, вероятно, понимаете, как сложно перевести что-то из разработки в производство. Экосистема машинного обучения изобилует инструментами, направленными на улучшение процесса разработки, но лишь немногие из них реально влияют на упрощение сквозного производственного процесса. В недавнем обсуждении за круглым столом на конференции dbt Coalesce Сара Катандзаро размышляла о текущем состоянии инструментов машинного обучения:
«Когда я смотрю на экосистему машинного обучения… есть инструменты и платформы для всего, начиная от распределенного обучения и заканчивая мониторингом моделей и отслеживанием экспериментов… и вы говорите с командами машинного обучения, они все еще действительно борются… единственным ответом может быть то, что инструменты — дерьмо… Они не были созданы с учетом эргономики разработчиков».
И она абсолютно права. (В контексте обсуждения dbt упоминается как аналитический инструмент, который превратил рабочий процесс аналитики в надежный рабочий процесс производственного уровня, и группа размышляет о том, станет ли машинное обучение следующей дисциплиной, которая последует этому примеру — мы так думаем!) Как обсуждалось в предыдущей статье, специалисты по обработке и анализу данных не умеют работать на производстве, и поставщики программного обеспечения уже давно потворствуют специалистам по данным, предоставляя им классные инструменты разработки, но не заставляя их фактически внедрять передовые методы производства. Высокотехнологичные компании ушли и построили свои собственные системы, но это не является устойчивой стратегией для большинства компаний, и найти и нанять инженеров-единорогов по машинному обучению для создания и обслуживания таких систем может быть сложной задачей.
Это не значит, что решение смотрит нам прямо в лицо. За последние полвека я провел десятки бесед с лидерами данных в компаниях из списка Fortune 500, которые задавались вопросом, почему их рабочие процессы машинного обучения такие сложные и почему никто по существу не создал систему, которая сделала бы машинное обучение совместимым с CI/CD (« Я бы хотел иметь возможность зафиксировать изменения в github и покончить с этим. Это работает для наших разработчиков программного обеспечения, почему это не может работать для наших инженеров по машинному обучению?). Я видел несколько попыток навязать эту парадигму другим инструментам, в основном с плохими результатами. Дело в том, что машинное обучение и искусственный интеллект более сложны, чем чисто программные системы, и вы не можете просто заставить ноутбуки работать с CI/CD-скриптами. Отсутствующий компонент — это платформа, которая легко контролирует полный жизненный цикл ML и позволяет системе CI/CD автоматизировать общие задачи ML.
Enter Continual: CI/CD для машинного обучения
В Continual наша цель с самого первого дня состояла в том, чтобы предоставить простой путь к производству с новым подходом к внедрению машинного обучения. Узнайте больше и начните работу сегодня в нашем блоге Начало работы с CI/CD и Continual.
(Примечание: эта статья изначально появилась в Постоянном блоге.)
