Автоматизировать или сделать вручную?
Какую работу нужно автоматизировать, а какую лучше выполнять вручную?
Есть две крайности: одни разработчики автоматизируют всё на свете, даже одноразовые задачи, другие не автоматизируют ничего, месяцами по привычке повторяя кучу рутинных действий.
Мы с вами знаем что истина где-то посередине, главный вопрос в критериях выбора.
Как принять решение, что эту задачу стоит автоматизировать, а вот эту не стоит?
Расскажу о своём подходе.
Уровень 0. Делаем вручную
Если вы выполняете задачу впервые, не автоматизируйте её, это того не стоит.
Если это даёт экономию по времени в разы, например вместо трёх дней вы выполните её за день (включая создание автоматизации), то можно как-то автоматизировать.
Но если например там обработка 2000 строк в Excel таблице, по которым быстрее будет за полчаса пройтись вручную, чем писать и отлаживать пару часов хитроумный скрипт, то не надо писать код. Сделайте руками.
Уровень 1. Пишем инструкцию
После третьей, пятой установки Ubuntu на сервер VPS я уже не гуглил инструкции и не вспоминал что ещё нужно выполнить чтобы сервер был настроен как мне нужно.
Но не потому что выучил наизусть: я не собираюсь держать такие вещи в голове.
Я просто сел и написал инструкцию в текстовом файлике и закинул в папку с инструкциями на рабочем диске.
Теперь эта операция выполняется за 15 минут вместо часа, что сильно упрощает мою задачу, а также даёт возможность полностью её делегировать не утруждаясь подробными объяснениями.
Кто-то на этом месте воскликнет, почему бы не использовать Ansible, Terraform и прочий Кубернетис - что, слабо?!
Позвольте, я выполняю эту задачу где-то раз в пару месяцев, и изучение всяких там Ansible ради такой редкой задачи только добавит мне работы, а не упростит.
Да, я буду развёртывать сервер парой команд, но потрачу минимум несколько рабочих дней на изучение, составление и отладку системы конфигов.
В восьмичасовом рабочем дне 480 минут, за год я установлю сервер по инструкции 6 раз и потрачу 6 * 15 = 90 минут в год.
(480 * 2) / 90 = 10.6(6)
Получается что вложение 2х дней на изучение и внедрение Ansible окупится только через 10 лет!
Есть, конечно, минус - текстовой инструкцией не похвастаешься перед коллегами и не закинешь её в резюме.
Уровень 2. Пишем скрипт Bash / Makefile
Что если нужно делать команды чаще? Например, несколько раз в неделю, месяц или каждый день?
Если команды нужны чаще и плохо запоминаются, требуют заучивания какой-то последовательности действий или опций командной строки, стоит выписать их в Bash скрипт.
Примеры таких скриптов:
- Скрипт деплоя приложения на сервер в простой системе деплоя: вытягиваем изменения, обновляем пакеты композера, выполняем миграции, сбрасываем кеш и так далее.
- Makefile в проекте с типичными командами для разработки: пересобрать контейнеры, запустить тесты, запустить или выключить контейнеры, выкатить в стейджинг, в прод, пересобрать фронт и так далее.
Подобные простые скрипты автоматизации хорошо избавляют от рутины, освобождают голову от деталей, копируются из проекта в проект часто без всяких изменений, легко поддерживаются если нужно внести изменения или что-то добавить.
Уровень 3. Пишем консольную команду или утилиту
Если задача частая и связана с конкретным проектом, то можно написать консольную команду.
Консольная команда в проекте
Например, нам часто требуется делать проверку остатков по счётам пользователя, имея только его Email. Почему бы не сделать команду в консоли которая быстро выведет табличку со списком счетов и балансами по ним?
Можно сделать и полноценный интерфейс в веб-приложении, вот только консольную команду сделать будет в разы проще и быстрее.
Разработчики сильно недооценивают этот способ автоматизации, но стоит им увидеть как легко выполняется работа благодаря таким командам, они и сами захотят их писать.
Утилита
Или, например, вы часто делаете какое-то действие которое не относится к конкретному проекту, но при этом необходимо и занимает время.
Допустим, это создание нового проекта и настройка его с вашими любимыми умолчаниями, включая создание репозитория, скриптов для Докера и тому подобное.
Пишете консольную утилиту, и в дальнейшем создаёте проекты одной командой или просто в разы быстрее с помощью интерактивной командной строки (консольного пользовательского интерфейса).
Уровень 4. Приложение
Если же вам нужно автоматизировать не одну, а несколько тесно связанных задач, да ещё это экономит вам кучу времени и серьёзно упрощает работу, то стоит создать специальное приложение.
Если приложение годится только для рабочего проекта и будет использоваться в вашей компании другими разработчиками, вы просто молодец.
Но если приложение настолько полезно что применимо и на других проектах и в других компаниях, вы счастливчик, ведь теперь вы можете распространять приложение или даже заработать на нём.
P.S.
Автоматизацию в виде сервисов, таких как onFRIDAY и CI/CD таких как GitLab Runner, BitBucket Pipelines, GitHub Actions и так далее я сознательно вынес за скобки.
Необходимость автоматизации CI/CD больше зависит не от вашего личного времени, а от зрелости, динамики проекта и количества разработчиков в команде проекта.
Не нужно настраивать мега-деплой со всеми свистелками для MVP или для одноразового сайта созданного на новогоднюю акцию.
Вот если проект приживётся и жить с ручным деплоем станет тяжеловато, то конечно можно автоматизировать, выбрав подходящий уровень автоматизации или настроив CI/CD.