Выпуск: сборка, магазин, первое обновление

Выпуск кажется одним событием — «выкатили версию», — а на самом деле их три, и едут они врозь. Нативная часть уходит в магазин: новые модули, иконка, номер версии; путь до человека — дни, а установленные приложения остаются прежними, пока он сам не обновится. JS-бандл уходит по воздуху: минуты, замок runtimeVersion и отпечаток набора нативных источников. Третья часть едет внутри бандла и обратно вместе с ним не возвращается — это схема данных на телефоне.

В приложении на запросах третьей строки просто нет: схема живёт в базе на сервере, телефон держит копию, и откат бандла возвращает всё как было. В local-first наоборот — главная копия дневника лежит на телефоне («Главная копия — в телефоне»), и поднимает её лестница, которая умеет идти только вверх.

Посмотрим на это запуском. В подложке лежат две вещи: база телефона — строки и номер схемы, — и запуск бандла, доводящий отставшую базу до ступеньки этого выпуска:

// подложка статьи: как бандл встречается с базой
function launch(db: Db, bundle: Bundle): string {
  // отставшую базу поднимает ступенька этого выпуска; вниз лестница не ходит
  if (db.schema < bundle.schema) {
    bundle.up(db);
    db.schema = bundle.schema;
  }
  return bundle.name + " видит: " + db.rows.map((row) => bundle.read(row)).join(", ");
}

Выпуск 1.1 разводит план и факт повторов: вместо одного reps в строке появляется repsDone. Миграция написана самым естественным образом — переложить значение и убрать старое поле. Обновление ушло по воздуху, а на следующий день его откатили: обычное дело, ради этого канал и переключают. Прогноз: что покажет экран после отката, что будет лежать в базе и какая у неё окажется схема?

type Row = Record<string, string | number>;
type Db = { schema: number; rows: Row[] };
type NewSet = { id: string; exercise: string; reps: number };
interface Bundle {
  name: string;
  schema: number;
  up(db: Db): void;
  read(row: Row): string;
  write(db: Db, set: NewSet): void;
}
// в подложке: база телефона, запуск бандла с его ступенькой и сборка 1.0,
// которая уже стоит у людей из магазина
declare function createDb(rows: Row[]): Db;
declare function launch(db: Db, bundle: Bundle): string;
declare const v10: Bundle;

// обновление по воздуху: вместо одного числа повторов — план и факт
const v11: Bundle = {
  name: "1.1",
  schema: 2,
  up: (db) => {
    db.rows.forEach((row) => {
      row.repsDone = row.reps;
      delete row.reps;
    });
  },
  read: (row) => row.exercise + " " + (row.repsDone ?? "—"),
  write: (db, set) => {
    db.rows.push({ id: set.id, exercise: set.exercise, repsDone: set.reps });
  },
};

const db = createDb([{ id: "A-1", exercise: "жим", reps: 5 }]);
console.log(launch(db, v11), "| схема базы:", db.schema);
v11.write(db, { id: "A-2", exercise: "присед", reps: 3 });

// обновление откатили: телефон снова запускает бандл из магазина
console.log(launch(db, v10), "| схема базы:", db.schema);
v10.write(db, { id: "A-3", exercise: "тяга", reps: 8 });
console.log("поля строк:", db.rows.map((row) => Object.keys(row).join("+")).join(" / "));

Первая строка — то, чего и ждали. Вторая — цена: откатанный бандл читает reps, а его в строках больше нет, и дневник состоит из прочерков. Подходы при этом целы, они в базе, — но человек этого не знает: он видит пустой дневник и идёт писать в отзывах, что приложение потеряло тренировки. Третья строка объясняет, почему дальше будет только хуже: подход, записанный уже на откатанном бандле, лёг в reps, а прежние два живут в repsDone. Одна таблица, два поля, и сводить их потом придётся руками.

Схема осталась второй в обеих строках — схема базы: 2. Лестница знает, как подняться, и не знает, как спуститься: ступеньку вниз никто не пишет, потому что она обязана угадать, что делать с данными, появившимися наверху. Отсюда правило, которое стоит принять до первого выпуска: по воздуху едут только те миграции, которые переживут возврат на предыдущий бандл.

Откат делает не человек у пульта, а телефон — сам, молча и в любую минуту: канал переключили на прежнюю ветку, время публикации у неё старее, приложение запускается на том бандле, который ему велели. Поэтому «мы просто не будем откатываться» — это не план.

Лечится это не хитростью, а порядком: миграция разрезается надвое, и по воздуху едет только первая половина. Расширяющая ступенька добавляет: новое поле появляется рядом со старым, код выпуска пишет оба и читает любое. Сужающая убирает старое — и уезжает сборкой в магазин, когда откатываться уже некуда. Это то же правило expand/contract, которым выкатывают миграции серверной базы (в части VI ему отведена своя статья), но причина здесь другая: там откат делаете вы и по своему решению, здесь — телефон и без вас.

Та же правка, написанная расширяющей ступенькой. Обновление ушло, его откатили, на откатанном бандле записали ещё подход, потом обновление вернули, а сужение уехало следующим магазинным выпуском 1.2. Прогноз: что видит каждый бандл на своём шаге и какие поля останутся в строках в конце?

type Row = Record<string, string | number>;
type Db = { schema: number; rows: Row[] };
type NewSet = { id: string; exercise: string; reps: number };
interface Bundle {
  name: string;
  schema: number;
  up(db: Db): void;
  read(row: Row): string;
  write(db: Db, set: NewSet): void;
}
declare function createDb(rows: Row[]): Db;
declare function launch(db: Db, bundle: Bundle): string;
declare const v10: Bundle;

// то же обновление, расширяющей миграцией: новое поле появляется, старое остаётся
const v11: Bundle = {
  name: "1.1",
  schema: 2,
  up: (db) => {
    db.rows.forEach((row) => {
      row.repsDone = row.reps;
    });
  },
  read: (row) => row.exercise + " " + (row.repsDone ?? row.reps ?? "—"),
  write: (db, set) => {
    db.rows.push({ id: set.id, exercise: set.exercise, repsDone: set.reps, reps: set.reps });
  },
};

// сужение — отдельный выпуск, через магазин: сперва долить, потом убрать
const v12: Bundle = {
  name: "1.2",
  schema: 3,
  up: (db) => {
    db.rows.forEach((row) => {
      row.repsDone = row.repsDone ?? row.reps;
      delete row.reps;
    });
  },
  read: (row) => row.exercise + " " + (row.repsDone ?? "—"),
  write: (db, set) => {
    db.rows.push({ id: set.id, exercise: set.exercise, repsDone: set.reps });
  },
};

const db = createDb([{ id: "A-1", exercise: "жим", reps: 5 }]);
console.log(launch(db, v11));
v11.write(db, { id: "A-2", exercise: "присед", reps: 3 });
console.log(launch(db, v10), "| схема базы:", db.schema);
v10.write(db, { id: "A-3", exercise: "тяга", reps: 8 });
console.log(launch(db, v11));
console.log(launch(db, v12), "| схема базы:", db.schema);
console.log("поля строк:", db.rows.map((row) => Object.keys(row).join("+")).join(" / "));

Откат больше ничего не ломает: 1.0 читает reps, и он на месте — расширяющая ступенька его не трогала, а запись из 1.1 кладёт оба поля. Подход, записанный на откатанном бандле, обновление читает через repsDone ?? reps: это вторая половина приёма — пока живы оба поля, читать надо оба.

Сужение в 1.2 — единственное место, где старое поле исчезает, и ступенька там не просто удаляет. Сперва она доливает repsDone тем строкам, у которых его нет, и только потом убирает reps. Иначе потеряются ровно те строки, которые записаны откатанным бандлом, — это первая задача статьи.

type Row = Record<string, string | number>;
type Db = { schema: number; rows: Row[] };
type NewSet = { id: string; exercise: string; reps: number };
interface Bundle {
  name: string;
  schema: number;
  up(db: Db): void;
  read(row: Row): string;
  write(db: Db, set: NewSet): void;
}
declare function createDb(rows: Row[]): Db;
declare function launch(db: Db, bundle: Bundle): string;

// проверка для текста: телефон, у которого 1.1 не было вовсе, ставит 1.2 из магазина
const v12: Bundle = {
  name: "1.2",
  schema: 3,
  up: (db) => {
    db.rows.forEach((row) => {
      row.repsDone = row.repsDone ?? row.reps;
      delete row.reps;
    });
  },
  read: (row) => row.exercise + " " + (row.repsDone ?? "—"),
  write: (db, set) => {
    db.rows.push({ id: set.id, exercise: set.exercise, repsDone: set.reps });
  },
};

const db = createDb([{ id: "A-1", exercise: "жим", reps: 5 }]);
console.log(launch(db, v12), "| схема базы:", db.schema);
console.log("поля строк:", db.rows.map((row) => Object.keys(row).join("+")).join(" / "));

В проекте это выглядит так — и главное в листинге не SQL, а комментарии: они объясняют, почему одна ступенька уезжает по воздуху, а вторая ждёт магазина.

// shared/db/migrations.ts — лестница едет внутри бандла, и потому каждая
// ступенька обязана уцелеть при возврате на предыдущий выпуск
import type { SQLiteDatabase } from "expo-sqlite";

export const steps: ((db: SQLiteDatabase) => Promise<void>)[] = [
  // 1 → 2: расширение. Старое поле остаётся: откатанный бандл читает именно его
  async (db) => {
    await db.runAsync("ALTER TABLE sets ADD COLUMN reps_done INTEGER");
    await db.runAsync("UPDATE sets SET reps_done = reps");
  },
  // 2 → 3: сужение. Уезжает не по воздуху, а сборкой в магазин — и сперва
  // доливает тем строкам, что записаны на прежнем бандле
  async (db) => {
    await db.runAsync("UPDATE sets SET reps_done = reps WHERE reps_done IS NULL");
    await db.runAsync("ALTER TABLE sets DROP COLUMN reps");
  },
];

// у журнала своя лестница: он хранит правки полями, и шаг таблицы ему не
// подходит — это выяснилось ещё в «Диске под памятью»

Соблазн сузить сразу понятен: две миграции вместо одной, два выпуска вместо одного, и старое поле мозолит глаза месяцами. Цена расширения — лишняя колонка. Цена сужения по воздуху — дневники, которые человек считает потерянными.

Расширение спасает от отката. Остаётся вторая половина той же беды — телефоны, до которых обновление не доехало, и их всегда больше, чем кажется: кто-то не открывал приложение месяц, у кого-то выключено автообновление в магазине, а кому-то обновление не отдал сам сервер — замок честно ответил 204, потому что сборка старая («runtimeVersion: замок, который бережёт установленные приложения»). Все они продолжают записывать подходы и отправлять их — операциями старой формы.

Отвергать такие операции нельзя. По контракту из «Сервер — партнёр, а не хозяин: журнал, курсор, приём пачки» отвергнутую операцию телефон убирает из очереди и пересобирает строку без неё — честная запись человека пропадает. Отказ на всю пачку не лучше: очередь застревает навсегда, а застрявшая очередь в local-first — это не «данные не сохранились», а «дневник человека остался на одном телефоне». Поэтому операция несёт номер схемы, а поднимает её принимающая сторона — теми же ступеньками, что и телефон. Контракт остаётся прежним, sync.push, и в части VI лестница переезжает в настоящую процедуру вместе с ним.

Месяц после выпуска: одна операция приходит с обновлённого телефона, другая — с того, что остался в магазинной версии. Прогноз: что окажется в строках сервера и что из этого увидит лента в 1.1 — без лестницы и с ней?

type Fields = Record<string, string | number>;
type Op = { opId: string; rowId: string; fields: Fields; schema: number };

// ступеньки сервера — те же, что на телефоне: каждая знает только своё поле
const steps: ((fields: Fields) => Fields)[] = [
  (fields) => {
    if (!("reps" in fields)) return fields;
    const { reps, ...rest } = fields;
    return { ...rest, repsDone: reps };
  },
];
const LATEST = steps.length + 1;

// операция несёт номер схемы, и сервер поднимает её до своей
function lift(op: Op): Op {
  let fields = op.fields;
  for (let from = op.schema; from < LATEST; from += 1) fields = steps[from - 1](fields);
  return { ...op, fields, schema: LATEST };
}

const rows = new Map<string, Fields>();
function take(op: Op, ladder: boolean): void {
  const ready = ladder ? lift(op) : op;
  rows.set(ready.rowId, { ...rows.get(ready.rowId), ...ready.fields });
}

// месяц после выпуска: обновлённый телефон и тот, что остался в магазинной версии
const batch: Op[] = [
  { opId: "A:7", rowId: "A-1", fields: { exercise: "жим", repsDone: 5 }, schema: 2 },
  { opId: "B:3", rowId: "B-1", fields: { exercise: "присед", reps: 3 }, schema: 1 },
];
const feed = (): string =>
  [...rows.values()].map((row) => row.exercise + " " + (row.repsDone ?? "—")).join(", ");

batch.forEach((op) => take(op, false));
console.log("без лестницы:", JSON.stringify([...rows.values()]));
console.log("лента в 1.1:", feed());
rows.clear();
batch.forEach((op) => take(op, true));
console.log("с лестницей:", JSON.stringify([...rows.values()]));
console.log("лента в 1.1:", feed());

Без лестницы сервер не соврал ни в одном поле: он сохранил то, что прислали. Соврала лента — она читает repsDone, а у приседа его нет, и подход выглядит пустым. Дальше хуже: правка того же подхода с обновлённого телефона добавит repsDone рядом, и в одной строке окажутся оба числа из разных эпох приложения, а слияние по полям будет честно сравнивать каждое само с собой («Кто прав, если оба правы»).

С лестницей старая операция становится новой до того, как коснётся строки, и разница между телефонами исчезает там, где ей и место, — на входе. Поднимает её принимающий, а не отправитель, и это не вопрос вкуса: бандл, выпущенный до 1.1, про новую схему не знает вовсе и узнать не может. Ступенька в листинге уже сужающая: пока на руках есть бандлы 1.0, сервер не убирает reps, а добавляет repsDone рядом, — когда убирать, решает «Кто выкатывается первым».

Тот же подъём нужен ещё в одном месте — при загрузке файла. Выгрузка из «Дневник принадлежит вам: выгрузка и загрузка обратно» кладёт рядом с операциями номер схемы: { app, schema, device, ops }. Годовалый архив — это та же пачка операций старой формы, только пришедшая не по сети, а из файла, и обращаться с ней надо так же. Это вторая задача статьи.

Номер схемы ставится на операцию в момент записи, а не в момент отправки: операция может пролежать в очереди неделю и уехать уже после обновления. Отметка «какой формы эти поля» принадлежит полям, а не пачке — ровно как отметка времени принадлежит операции, а не сеансу связи.

Осталось решить, в каком порядке всё это выпускается, и правило тут одно: первым выкатывается тот, кто принимает. Сервер учится понимать обе формы и уезжает в прод раньше, чем первый телефон получит обновление.

Что бывает иначе, видно запуском — и это единственный пример статьи, где работает собранная за главы 6 и 7 машинерия целиком: хранилище, журнал операций и сервер-партнёр — та самая миниатюра в этой же памяти, из описи подмен («Подход»: что в подложке было ненастоящим). Сервер выпущен прежним: его проверка требует от подхода exercise, weightKg и reps. Телефон получил обновление 1.1 и пишет repsDone. Прогноз: что ответит сервер, что станет с подходом на экране и что изменится, если тот же выпуск будет писать оба поля?

type Fields = Record<string, string | number | boolean>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Store {
  sets(): Row[];
}
interface Journal {
  newId(): string;
  change(rowId: string, fields: Fields): void;
}
interface Server {
  rows: Map<string, Row>;
}
interface Client {
  store: Store;
  journal: Journal;
  queue(): Op[];
  sync(): Verdict[];
}
declare function createServer(): Server;
declare function createClient(device: string, server: Server): Client;

// сервер выпущен прежним: про поле repsDone он ещё не знает
const server = createServer();

// телефон, получивший обновление 1.1: новое поле вместо старого
const fresh = createClient("A", server);
const first = fresh.journal.newId();
fresh.journal.change(first, { exercise: "жим", weightKg: 80, repsDone: 5 });
const rejected = fresh.sync();
console.log("новый бандл:", rejected.map((v) => v.status + ": " + v.reason).join(", "));
console.log("на экране подходов:", fresh.store.sets().length, "| ждут отправки:", fresh.queue().length);

// тот же выпуск, но пишущий оба поля, пока сервер не знает нового
const both = createClient("B", server);
const second = both.journal.newId();
both.journal.change(second, { exercise: "жим", weightKg: 80, reps: 5, repsDone: 5 });
console.log("оба поля: отказов", both.sync().length, "| на экране подходов:", both.store.sets().length);
console.log("строк у сервера:", server.rows.size);

Сервер отверг операцию по имени поля, и клиент сделал ровно то, чему его учили: выбросил отвергнутую операцию и пересобрал строку («Цикл синхронизации: отправить, забрать, не задвоить»). Пересобирать было не из чего — это была первая операция строки, — и подход исчез с экрана. Вторая строка вывода тут страшнее первой: ждут отправки: 0. Очередь пуста, индикатор говорит «сохранено», ошибки человеку никто не показал; с точки зрения клиента выпуск прошёл штатно.

Второй телефон пишет оба поля — и тот же самый сервер принимает его без единого отказа. Это то же расширение, что и в базе, только на проводе: пока живы обе стороны, операция несёт и старое поле, и новое.

Отсюда весь порядок выпуска, и заодно ответ на вопрос, почему выпусков четыре, а не один. Первым — сервер, понимающий обе формы. Вторым — сборка в магазин: натив, расширяющая ступенька, запись обоих полей. Третьим — обновление по воздуху, которому теперь есть куда приехать. Четвёртым, много позже, — сужение, и не по календарю, а по данным: пока на сервер приходят операции старой формы, старая форма жива.

Отказ по операции — не поломка протокола, а его работа: сервер обязан отвергать мусор, иначе в дневник приедет что угодно. Беда в другом — отвергнутой оказалась честная запись человека, и виноват в этом не протокол, а порядок выпуска.

Теперь сами команды. Что печатает каждая из них, как устроены профили сборки, треки магазинов и каналы обновлений, разобрано в главах 10 и 11; здесь важен только порядок — тот, в котором их запускают для выпуска «Подхода».

# 1. долетит ли правка обновлением — или ей нужна новая сборка
npx expo-updates fingerprint:generate --platform android > fingerprint.json
EAS_PROJECT_ID=<id проекта> npx expo-updates runtimeversion:resolve --platform android

# 2. сборка в магазин: натив, расширяющая ступенька, запись обоих полей
eas build --platform android --profile production
eas build --platform ios --profile production

# 3. отправка: два магазина одной командой, RuStore — своим скриптом
eas submit --platform android --latest
eas submit --platform ios --latest
node scripts/rustore-publish.mjs

# 4. первое обновление по воздуху — сперва на десятую часть установок
eas update --branch release-1.1 --message "план и факт повторов"
eas channel:rollout production --action=create --branch release-1.1 --percent 10 --runtime-version 1.0.0

# доля растёт одной командой, ничего не публикуя заново
eas channel:rollout production --action=edit --percent 50

Шаг 1 стоит проговорить отдельно. Если отпечаток изменился, обновления по воздуху не будет вовсе: телефон получит 204 и останется на вшитом бандле. Это правильно — правка, которой нужен новый натив, не должна доезжать до старой сборки, — и плохо здесь только одно: узнать об этом после публикации, когда людям уже сказано, что починили.

А перед всем этим идёт проверка, и она дешевле любого отката. Собрана она из того, что уже написано в этой главе и в главах 10–11, — пройти её можно за один вечер.

Первым обновлением по воздуху полезно выпустить пустяк — исправленную опечатку. Тогда канал, ветка и замок проверяются на том, чего не жалко откатить, а не на миграции схемы.

Первые сутки после выпуска смотрят на три вещи, и две из них общие для любого приложения: доля сессий без падений в разрезе update_id и отзывы («После релиза: аналитика, крэши, отзывы»). Пока раскатка идёт на десятую часть, обе цифры сравнивают с теми же цифрами прежнего обновления — иначе «12 падений» не значит ничего.

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

Поэтому в сводку выпуска попадают два числа, которых в обычной аналитике нет: сколько операций отвергнуто и с какой причиной — той самой, которую вердикт называет словами, годными и для человека, и для группировки («Цикл синхронизации: отправить, забрать, не задвоить»), — и сколько устройств держат непустую очередь дольше суток. Первое ловит выпуск, разъехавшийся с сервером; второе — всё остальное, вплоть до протухшего токена и паузы при 401 («Свернули и вернулись: процесс вместо вкладки»).

На этом «Подход» закончен. За двенадцать глав он из первого экрана на View и Text стал приложением, которое пишется в зале без сети, держит главную копию на телефоне, синхронизируется журналом операций, переживает откат обновления и выкладывается в три магазина. Пятнадцать миниатюр, собранных по дороге — от своего слияния стилей до worklet в настоящем втором потоке, — так и лежат в подложке и работают до последней строки этой статьи.

Чего у «Подхода» нет — второй половины. Миниатюра из главы 7 честно отвечает на sync.push и sync.pull, но живёт в той же памяти, что и экраны, а горизонт курсора, срок надгробий и снимок для нового телефона ей не по силам. Этим занимается часть VI: там будет настоящий сервер на Node, и контракты у него будут те же самые — те же имена, тот же смысл, та же пачка. Экраны «Подхода» при этом не изменятся ни строкой. А пока в части V остаётся последняя глава — уже не про «Подход», а про чужие пакеты на телефоне: полка React Native и Expo.

Выпуск — не конец работы, а начало другой: первый отзыв, первый отчёт о падении и первое письмо «а можно выгрузку в…» приходят на первой неделе. Хорошая новость в том, что дневник у людей уже свой: он лежит на их телефонах и выгружается в файл — что бы дальше ни случилось с приложением и с вами.