ElKornacio

#!/bin/bash
(
export ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic
export ANTHROPIC_AUTH_TOKEN=PUT_YOUR_TOKEN_HERE
export ANTHROPIC_DEFAULT_HAIKU_MODEL=glm-4.5-air
export ANTHROPIC_DEFAULT_SONNET_MODEL=glm-4.6
export ANTHROPIC_DEFAULT_OPUS_MODEL=glm-4.6
claude
)

ElKornacio

Сравнение двух вариантов реализации миграции с бэкендом

Мы рассмотрели два варианта реализации миграции:

1. Раскатка бэкенда, потом миграция, потом переключение на новую версию (сб-м-нб): новый бэкенд с поддержкой старой базы данных; работа с новой базой начинается после миграции.
2. Cначала миграция, затем раскатка новой версии бэкенда (р-м-нб): новый бэкенд без поддержки старой базы, но с роутингом трафика (на него идёт только трафик по организациям, где миграция уже прошла).

Сб-м-нб означает "Старая база - Миграция - Новая база"

Р-м-нб означает "Роутинг - Миграция - Новая база"

ElKornacio

Как в целом выглядит версионирование изменений

1. CloudServer при выполнении кода ориентируется на версию БД, а именно - на названия миграций. Мне кажется, так чище и читабельнее, связь между миграцией и тем, почему мы используем другой код становится понятнее:

if (database.has('UsersMovedToTheNewTable')) {
	await source.exec(`SELECT * FROM new_table`);
} else {
	await source.exec(`SELECT * FROM old_table`);
}