Мы уже давно привыкли описывать всю инфраструктуру в виде кода. Это удобно и позволяет быстро разворачивать новые типовые сервера, так что сами по себе отдельные сервера перестали быть ценностью. Если вдруг катастрофа, то всё всегда можно удалить и развернуть заново. Важен не сам сервер, важен рецепт, как этот сервер развернуть. Если призадуматься, то машина разработчика — это тоже своего рода инфраструктура, и её тоже можно (и нужно!) описать в виде кода, и воссоздавать/пересоздавать по запросу.
Это же невероятно круто, когда новый человек в компании может за 10 секунд получить готовое настроенное окружение для разработки. Все зависимости есть, тесты проходят, нужные плагины для IDE установлены и настроены. Берешь и сразу же начинаешь разбираться с кодом, а не тратишь три дня на клонирование огромных репозиториев, установку и компиляцию всех зависимостей. Знакомо ведь это чувство, когда нужно собрать какую-то конкретную лохматую версию какой-то всратой библиотеки из исходников с патчами? И эти скрипты почему-то работают на одной машине, но не работают на другой, и никто на самом деле не понимает почему.
А если вдруг твоё эфемерное окружение для разработки вышло из строя, то без проблем — просто создай новое, и через 10 секунд будешь готов продолжить работу.
Постоянно наступаю на проблему, что при переключении между ветками в Git забываю обновлять зависимости. Переключаешься на новую ветку — тесты не работают, линтеры красные. "Ах, ну да, эта ветка отстаёт от мастера на две недели, здесь с такими версиями библиотек ничего работать не будет". Запускаешь свой
pipenv --rm && pipenv sync --dev. Это минуты на три. Выпадаешь из потока и идёшь запаривать очередную кружку кофе. А ведь можно было бы просто закрыть один редактор и открыть другой, где всё уже настроено для той конкретной ветки, которая тебе нужна.И GitHub Codespaces, и Gitpod в фоне постоянно собирают (prebuild) окружения, чтобы можно было взять, и как можно быстрее начать пользоваться. На самом деле, я пока в восторге именно от эфемерности этих окружений для разработки. То, что они работают в облаке — это не так уж и важно. Просто так проще организовать всю эту систему.
https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/
