Transcript
00:00:00Ваш readme вам врет. Там сказано, что настройка займет пять минут, но Node не тот, Python не тот,
00:00:07Postgres отсутствует, Docker грузится вечность, и мы занимаемся отладкой еще до начала работы.
00:00:13Ваша среда разработки не должна жить в readme, она должна быть в Git. Именно для этого существует Devbox.
00:00:20Один файл devbox.json, одна команда devbox shell — та же среда для каждого разработчика без глобальных установок.
00:00:28И никаких знаний Nix. Позвольте показать.
00:00:30Поначалу Devbox кажется слишком простым. Вы создаете devbox.json и перечисляете инструменты, нужные вашему проекту.
00:00:42Node, Go, Python, Postgres — что угодно, что нужно вашему стеку. Вы коммитите этот файл, и любой другой разработчик может просто
00:00:50запустить devbox shell и получить ту же среду, что и у вас: те же версии, инструменты, скрипты, без глобальных
00:00:58установок, без «пожалуйста, установите сначала эти восемь штук» или старого Homebrew с давних времен. Ваша настройка
00:01:03перестает жить в чьей-то памяти и начинает жить в вашем репозитории. Сейчас это кажется мелочью, но если вы
00:01:09хоть раз теряли полдня на сломанную локальную настройку, вы уже знаете, что это совсем не мелочь. Если вам нравятся
00:01:16инструменты для ускорения разработки, обязательно подпишитесь, у нас постоянно выходят новые видео.
00:01:20Итак, мы начинаем с чистого листа, я создам новую папку.
00:01:25Назовем её devbox-demo, перейдем в папку, и все, что нужно сделать, если у вас есть Devbox, — это запустить
00:01:31devbox init. Devbox создает файл devbox.json, сейчас он практически пуст, это просто
00:01:39шаблон, который дает нам Devbox. Теперь добавим инструменты, нужные этому проекту. Чтобы добавить инструменты, мы можем
00:01:45выполнить devbox add, и я установлю такие вещи, как Go, Node.js и немного Python. А теперь важный момент:
00:01:52я не устанавливаю их глобально, я не меняю свой системный Node, я не трогаю свой системный
00:02:00Python. Эти инструменты принадлежат этому проекту. Теперь, когда я запускаю devbox shell, я нахожусь в чистой проектной
00:02:09среде. Теперь, когда вы в этой среде, вы можете просто проверить версии: go version, node
00:02:14version, python version. Да, я могу проверить всё, чтобы убедиться, что оно работает. В этом-то и вся прелесть:
00:02:19проект запросил конкретные инструменты, Devbox мне их предоставил. Теперь добавим скрипт. Внутри devbox.json
00:02:27мы можем определить тест, и я просто выведу эхом, что тесты запущены, и получу версии Node
00:02:34и Go при выполнении devbox run test. И теперь та же команда работает для любого, кто использует этот репозиторий.
00:02:42Те же скрипты, те же инструменты, та же среда. А теперь смотрите, что будет, когда я выйду: можно просто ввести exit,
00:02:48вы выйдете из этой среды, и я вернусь к своему обычному окружению на машине. Это было до
00:02:53неприличия просто, правда? Что же на самом деле делает Devbox? Devbox использует Nix под капотом. Nix хорош тем, что
00:03:00он создан для воспроизводимости. Вместо того чтобы сказать «установите то, что актуально сегодня»,
00:03:06он может закрепить именно те инструменты, которые нужны вашему проекту. Это хорошая часть. Трудная часть в том,
00:03:12что Nix может казаться целым новым миром. Там много отличных концепций, но не совсем
00:03:18дружелюбных, когда вы просто хотите получить правильную версию Node. Devbox предлагает нечто иное:
00:03:23он говорит: «Что, если мы сохраним воспроизводимость, но сделаем рабочий процесс привычным?» Поэтому вместо того, чтобы
00:03:29писать Nix-выражения, вы можете использовать команды вроде devbox add, devbox search, shell, run, services. Все
00:03:37эти команды гораздо проще, и ваш проект получает два важных файла: JSON-файл и
00:03:44lock-файл. Думайте о devbox.json как о том, что нужно среде, а о devbox.lock — как о способе закрепить
00:03:52точно то, что вы получили. Закоммитьте оба, и теперь ваша среда — это не просто абзац в файле readme,
00:03:58это часть самого проекта. Devbox работает на macOS, Linux и WSL, может интегрироваться с VS Code, может
00:04:06определять скрипты, управлять службами вроде баз данных, а когда нужно, может экспортировать в такие вещи, как
00:04:12Docker, dev-контейнеры и CI-воркфлоу. Ценность этого не просто в крутом инструменте, а в невероятной простоте. Суть
00:04:19в экономии времени. Первая проблема — это readme, верно? Readme может сказать что угодно, он
00:04:26может сказать: «Установите Node 18», но приложение изменилось, ему на самом деле нужен Node 20. Вторая проблема,
00:04:32с которой это реально помогает, — это онбординг. Ваш первый день на работе, все должно быть просто.
00:04:37Мы знаем, что это не так. Не должно быть нужды спрашивать: «Какая версия Node мне нужна?», не нужно
00:04:43дергать кого-то: «Эй, какая у нас версия Python? Нужен ли мне Postgres локально? И почему
00:04:48это работает только у маленького Тимми?» Им нужно просто клонировать репозиторий, войти в оболочку
00:04:52и запустить проект. Если что-то сломалось, по крайней мере все начинают из одной и той же среды. Проблема
00:04:58в глобальном загрязнении системы. Тестирование инструментов не должно убивать ваш ноутбук. Вы хотите Go 1.22 для этого репозитория — вы добавляете его, вы
00:05:06хотите Node 20 здесь, но что-то еще где-то — без проблем. Инструменты живут с проектом, ваша
00:05:13система остается чище. С Devbox определение вашей среды можно использовать как для локальной разработки,
00:05:18так и для автоматизации. Решает ли это все проблемы CI? Нет, не решит, но убирает огромный класс глупых
00:05:26проблем, а глупые проблемы — это те, что ранят нас сильнее всего. Они просты, но мы сталкиваемся с ними все время.
00:05:32Наконец, Docker. Тяжелый локальный воркфлоу с Docker, если быть точнее. Docker все еще великолепен, если
00:05:40вам нужны контейнеры — используйте их. Но многие команды используют Docker локально просто потому, что у них нет лучшего
00:05:46способа управлять инструментами. А здесь воркфлоу до неприличия прост: devbox add, shell, run — вы
00:05:52не должны учить слишком много. Среда становится реальной частью проекта, реальным файлом
00:05:57в репозитории. Когда все используют одни и те же версии и скрипты, отладка становится проще. Это здорово,
00:06:03супер просто. Что будет вас раздражать: ну, первая загрузка Nix заняла время, но это нормально — это первый раз.
00:06:09JSON прост, но он может стать уродливым, если мы добавим в него слишком много всего.
00:06:15Для базовых скриптов это нормально. Для сложной логики настройки не пихайте гигантские shell-команды в JSON,
00:06:22просто вынесите логику в sh-файл, а затем вызывайте его из Devbox. И наконец, Devbox — это не полноценная облачная IDE.
00:06:30Если вам нужно браузерное кодирование, мгновенный предпросмотр по URL, вам все еще могут потребоваться Codespaces.
00:06:36Devbox лучше всего подходит для локальной и CI-воспроизводимости. Devbox не решит каждую проблему разработки,
00:06:42но он может решить те, что раздражают нас больше всего, а это просто запуск проекта.
00:06:46Так что это может быть хорошим вариантом, особенно если в вашем проекте больше одного языка или больше
00:06:51одного CLI-инструмента. Если вам нравятся подобные инструменты разработки, подписывайтесь на канал Better Stack, мы
00:06:56увидимся в следующем видео.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video