Что такое DevOps и автоматический деплой для бизнеса
Что такое DevOps и автоматический деплой (CI/CD), что они дают бизнесу, когда окупаются и когда избыточны: простое руководство для принятия решения.
Команда rabbitclipПубликация: 5 мин чтения
Коротко
DevOps это способ работы, при котором люди, создающие программу, и люди, поддерживающие её в рабочем режиме, действуют в одном процессе и ради одной цели. Автоматический деплой, обычно называемый CI/CD, это его самая заметная часть: когда изменение сохранено, код проверяется, собирается и публикуется на сайте одними и теми же шагами каждый раз. Для бизнеса смысл прост. Выпуск больше не зависит от памяти одного человека или от файлов, скопированных вручную; он становится повторяемой работой, которую при необходимости можно отменить.
Эти понятия часто подают так, будто это тема, которую технические команды обсуждают только между собой. Но вопросы, которые задаёт руководитель, гораздо проще: почему небольшая правка на сайте занимает два дня, кто наведёт порядок, если выпуск что-то сломает, и знает ли только один человек, как сайт выходит в свет. DevOps привязывает ответы на все эти вопросы к привычке и к устойчивому порядку работы, а не к отдельным людям.
В этой статье мы стараемся объяснять идею как можно проще. Мы расскажем о том, что эта практика даёт бизнесу, в каких случаях она не нужна и какие ошибки люди совершают при её настройке.
Что на самом деле меняет DevOps?
При старом устройстве работа делится надвое. Одна сторона пишет функцию, другая размещает её на сервере и поддерживает в рабочем состоянии. Передача между ними порождает ожидание, недопонимание и фразу «у меня работало». DevOps сокращает этот разрыв: тот, кто пишет код, знает, каким путём он попадает к пользователям, а тот, кто управляет сервером, знает, что нужно самому коду.
Должность ни у кого не меняется. Меняется то, что вся работа идёт по одной общей линии. То, что пишется, проверяется, публикуется и отслеживается, становится частью единого порядка. Для небольшой команды это совсем не значит нанимать нового специалиста; это значит делать прежнюю работу с меньшим числом неприятных неожиданностей.
Как работает автоматический деплой, шаг за шагом?
Автоматический деплой связывает со скриптом весь путь от компьютера разработчика до работающего сайта. Поскольку один и тот же путь проходится каждый раз в одном и том же порядке, место для ошибки принадлежит самому порядку, а не тому человеку, который в этот день случайно нажимает кнопку.
Типичный конвейер состоит из шагов, перечисленных ниже. Если любой из шагов не удался, конвейер останавливается, а работающий сайт остаётся в точности таким, каким он был до этого.
- Разработчик отправляет изменение в репозиторий кода
- Система собирает код и запускает автоматические тесты
- Если тесты пройдены, готовится новая версия (упаковывается)
- Версия сначала попадает в тестовую среду, затем на работающий сайт
- После выпуска страница проверяется; если она сломана, возвращается предыдущая версия
Что это даёт бизнесу на практике?
Самая заметная польза это скорость, но настоящая ценность в предсказуемости. Когда выпуск сводится к одной кнопке или одной отправке кода, мелкие правки не копятся днями: обновление цены, страница рекламной кампании или обычная опечатка могут выйти в тот же день. Чем чаще вы выпускаете изменения, тем меньше каждое из них, а чем меньше изменение, тем меньше связанный с ним риск.
Вторая польза это возможность вернуться назад. Каждая версия записана, поэтому если после выпуска что-то пойдёт не так, можно быстро вернуться к последней рабочей версии. Третья польза это общее знание: поскольку процесс выпуска описан в виде конвейера, им не владеет один человек, и работа не останавливается, когда этот человек в отпуске или уходит из компании.
Каким компаниям это нужно, а каким нет?
Нужно не каждому сайту. Для одностраничного сайта-визитки, который обновляют всего несколько раз в год, настройка конвейера деплоя может стоить в установке и поддержке больше, чем она в итоге экономит. Такому сайту обычно вполне хватает регулярных резервных копий, безопасного способа публикации и журнала, в котором записаны изменения.
Конвейер окупается в следующих случаях: сайт часто меняется, несколько человек работают с одним и тем же кодом, есть сценарии вроде интернет-магазина или онлайн-записи, где сбой напрямую означает потерянный доход, либо нужно управлять несколькими средами (тестовой и рабочей). Критерий не размер сайта, а то, как часто он меняется и чего стоит его поломка.
Какие ошибки встречаются часто?
Самая распространённая ошибка это автоматизировать без тестов. Конвейер, который публикует, ничего не проверяя, доставляет ошибки на работающий сайт быстрее, чем если бы всё делалось вручную. Смысл автоматизации прежде всего в том, чтобы не дать выйти дефектной версии, и только потом в том, чтобы ускорить сами выпуски.
Вторая ошибка это принимать инструмент за цель. Установить популярный инструмент ещё не значит заниматься DevOps; без процесса, без ответственного и без плана отката это лишь ещё один слой сложности. Вот другие ошибки, которые встречаются часто.
- Записывать пароли и ключи прямо в код; их нужно хранить в отдельном защищённом месте
- Ни разу не репетировать откат, так что первая попытка приходится на момент кризиса
- Строить тестовую среду совсем не так, как рабочую, так что тесты проходят, а рабочий сайт ломается
- Не назначать владельца конвейера, так что никто не смотрит, когда он падает
С чего начать?
Начать с малого это самый надёжный путь. Первый шаг: записать на бумаге, как сайт публикуется сегодня; часто само описание сразу показывает пробелы. Затем код берётся под систему контроля версий, после чего строится простой конвейер, который только собирает сайт и выполняет базовые проверки.
Когда это устоялось и стало привычным, добавляются автоматические тесты, тестовая среда и проверка после выпуска. Критерий для каждого шага один и тот же: стал ли выпуск проходить спокойнее и быстрее ли происходит восстановление после возникшей проблемы. Если ответ да, переходим к следующему шагу; если нет, останавливаемся и сначала всё исправляем.
DevOps и автоматический деплой привязывают выпуски к порядку, а не к людям, а польза измеряется тем, как часто меняется сайт и сколько стоила бы поломка. Сайту, который меняется редко, вполне достаточно надёжных резервных копий и аккуратного способа публикации, а сайт, который часто меняется и приносит доход, окупит конвейер с тестами и возможностью отката. Если вы хотите вместе с нами пересмотреть, как ваш сайт выходит в свет сегодня, rabbitclip с радостью проведёт с вами спокойную ознакомительную беседу.
Частые вопросы
Что означает CI/CD?
CI означает непрерывную интеграцию, а CD непрерывную доставку или развёртывание. Каждое изменение кода автоматически проверяется и, после одобрения, каждый раз одними и теми же шагами подготавливается или публикуется.
Нужен ли DevOps сайту небольшой компании?
Чаще всего полный конвейер не нужен. Достаточно резервных копий, безопасного способа публикации и журнала изменений. Автоматизация обретает смысл тогда, когда обновления становятся чаще или когда поломка начинает обходиться дороже.
Делает ли автоматический деплой сайт безопаснее?
При правильной настройке да: ошибок при копировании файлов становится меньше, каждая версия записана, а неудачный выпуск можно отменить. Но защиту паролей и написание тестов всё равно нужно обеспечивать отдельно, потому что одна лишь автоматизация безопасности не даёт.
Нужно ли нанимать отдельного человека для DevOps?
Небольшому бизнесу это не нужно. Порядок выпуска может настроить ваш нынешний разработчик или то агентство, с которым вы уже работаете. Важно только, чтобы процесс был записан и чтобы у него был владелец.
