Деплой: как код доходит до реальных людей

Твой проект работает. Ты показывал его друзьям на своём ноутбуке, и всё работало. Ты выкладываешь его на сервер, рассылаешь ссылку — и он ломается мгновенно. Тот же код, те же файлы, всё то же самое. Изменилось только одно: где он запущен. У этого момента есть название, и это шутка, которую рассказывают, потому что он случается со всеми: «но у меня на машине работало».

Сломалось оно потому, что твой ноутбук никогда не запускал только твой код. Он ещё поставлял сотню вещей, от которых твой код тихо зависит: на каком порту слушать, где живёт база данных, какие ключи API использовать, какая версия языка установлена, какие файлы случайно лежат в той папке. Ничего этого нет в твоём коде, поэтому ничего этого не уехало вместе с кодом. Места, где запускается код, называются окружениями. Обычно их три: твой ноутбук, где ты всё делаешь и где ломать не страшно; staging — копия настоящей установки, где команда проверяет всё до того, как это увидят пользователи; и production — настоящее, с реальными людьми и реальными деньгами. Одна и та же программа работает во всех трёх, а значения в каждой свои.

env:         laptop     staging    production
-----------  ---------  ---------  -----------
PORT         3000       8080       80
API_KEY      test       test       live
LOG_LEVEL    debug      info       warn

Прежде чем код сможет работать на сервере, его часто нужно превратить в то, что сервер сумеет запустить: это и есть сборка. Скомпилировать TypeScript в JavaScript, собрать много файлов в один, сжать картинки, получить одну папку, готовую к запуску. Разница важна, потому что это два разных шага с двумя разными видами поломок. Сборка падает на твоей машине, до всякого деплоя, и это дёшево: до пользователей ещё ничего не дошло. А падение при запуске случается на сервере, когда пользователи смотрят. Ты хочешь, чтобы как можно больше поломок были поломками сборки.

src/cart.ts       ---> dist/app.js
package.json      ---> node_modules/

ts ---> js

$ npm start
PORT=80 listening

Так что честная версия «у меня на машине работает» — это список вопросов, и он короткий. Здесь другая конфигурация — порт, база, ключи? Какой-то зависимости не хватает или у неё другая версия? Файл, которого ждёт код, вообще есть на этой машине и с тем же регистром букв? Есть ли у этой машины право пользоваться сетью, папкой, портом? И тот вопрос, который все забывают: работает ли оно до сих пор, в этот час, под такой нагрузкой? Ни один из этих вопросов не про то, насколько умён твой код. Все они про мир, в который код попал.

Каждый деплой — это ещё и небольшая ставка. Поэтому до деплоя реши, как ты вернёшься назад. У этого плана есть название: откат. Он означает возврат к предыдущей версии, про которую известно, что она работала, обычно одной командой, и занимать это должно секунды, а не часы. Смысл отката не в том, чтобы что-то починить: он в том, чтобы остановить ущерб, пока ты разбираешься, что сломалось. Заметь, что для него нужно. Нужно, чтобы предыдущая версия всё ещё существовала и всё ещё работала. Нужно, чтобы данные пережили путешествие назад, и это самое трудное: если новая версия уже записала в базу записи нового вида, старая версия должна их терпеть. И нужно узнать, что всё сломано, а значит — смотреть, что происходит сразу после деплоя, а не предполагать.