a.tolmachev
235 lines
7.8 KiB
Markdown
235 lines
7.8 KiB
Markdown
# Repository split map
|
||
|
||
## 1. Назначение документа
|
||
|
||
Этот документ фиксирует целевую карту физического разделения текущего репозитория на:
|
||
|
||
- `crank-community`
|
||
- `crank-enterprise`
|
||
- `crank-cloud`
|
||
|
||
Документ нужен, чтобы:
|
||
|
||
- не гадать, что именно куда переносится;
|
||
- заранее отделить public Community artifacts от private commercial delivery;
|
||
- подготовить создание новых репозиториев как управляемый шаг, а не как спонтанный рефакторинг.
|
||
|
||
## 2. Текущее состояние
|
||
|
||
Сейчас код и документация еще живут в одном репозитории.
|
||
|
||
Это допустимо только как переходное состояние, пока:
|
||
|
||
- не зафиксированы capability boundaries;
|
||
- не подготовлены extension seams;
|
||
- не собраны отдельные Community delivery artifacts;
|
||
- не определен physical split plan.
|
||
|
||
После завершения этого этапа текущий репозиторий не должен оставаться source of truth сразу для
|
||
всех трех редакций.
|
||
|
||
## 3. Целевой результат
|
||
|
||
### 3.1. `crank-community`
|
||
|
||
Public repository.
|
||
|
||
В нем должны остаться:
|
||
|
||
- Community runtime;
|
||
- Community UI;
|
||
- `admin-api`, `mcp-server`, `ui`;
|
||
- `crank-core`, `crank-registry`, `crank-runtime`, schema and mapping crates;
|
||
- только `REST`-ориентированный Community protocol surface;
|
||
- capability model;
|
||
- Community auth model:
|
||
- static AI-agent key;
|
||
- only `security_level = standard`;
|
||
- `deploy/community/*`;
|
||
- optional `Valkey` service definition для Community deployment;
|
||
- public CI/CD for Community;
|
||
- Community docs, smoke docs и demo flow.
|
||
|
||
Техническая оговорка:
|
||
|
||
- `crank-runtime` в Community должен уметь собираться без premium adapter crates;
|
||
- `UnsupportedProtocol` и capability model должны оставаться достаточным fallback для disabled protocol families.
|
||
|
||
В нем не должно остаться:
|
||
|
||
- private token issuer implementations;
|
||
- enterprise auth/governance services;
|
||
- cloud control-plane logic;
|
||
- private packaging files;
|
||
- private operational tooling.
|
||
|
||
### 3.2. `crank-enterprise`
|
||
|
||
Private repository.
|
||
|
||
В нем должны жить:
|
||
|
||
- self-hosted commercial extensions;
|
||
- `GraphQL` и `gRPC unary`, если они окончательно выводятся из Community;
|
||
- short-lived token service;
|
||
- one-time token service;
|
||
- enterprise access/governance:
|
||
- `SSO`
|
||
- `2FA`
|
||
- extended `RBAC`
|
||
- `audit log`
|
||
- premium protocol/runtime additions, если они не входят в Community;
|
||
- enterprise deployment manifests;
|
||
- optional cluster-aware cache integration для self-hosted production;
|
||
- private container/release packaging;
|
||
- enterprise operator docs.
|
||
|
||
### 3.3. `crank-cloud`
|
||
|
||
Private repository.
|
||
|
||
В нем должны жить:
|
||
|
||
- cloud control plane;
|
||
- metering;
|
||
- billing;
|
||
- hosted tenant management;
|
||
- hosted operational tooling;
|
||
- managed shared cache layer defaults and cache operations;
|
||
- cloud-only delivery manifests;
|
||
- cloud release pipeline;
|
||
- hosted support/admin tooling.
|
||
|
||
## 4. Карта по типам содержимого
|
||
|
||
### 4.1. Application code
|
||
|
||
Остается в `crank-community`:
|
||
|
||
- весь текущий Community runtime и UI
|
||
- все public extension seams
|
||
- все capability checks
|
||
- `REST`-only product surface
|
||
|
||
Как промежуточный этап до физического переноса:
|
||
|
||
- `crank-runtime` в общем коде должен иметь feature-gated seams для `GraphQL/gRPC/SOAP/WebSocket`;
|
||
- это позволяет потом перенести premium adapters в private repos без полного форка runtime base.
|
||
|
||
Уходит в `crank-enterprise`:
|
||
|
||
- `crank-adapter-graphql`
|
||
- `crank-adapter-grpc`
|
||
- private auth/token/governance services
|
||
- enterprise-only runtime additions
|
||
|
||
Уходит в `crank-cloud`:
|
||
|
||
- hosted orchestration and control-plane code
|
||
- billing/metering integrations
|
||
|
||
### 4.2. Deployment manifests
|
||
|
||
Остается в `crank-community`:
|
||
|
||
- `deploy/community/*`
|
||
|
||
Уходит в `crank-enterprise`:
|
||
|
||
- private self-hosted manifests
|
||
- private `Helm` charts
|
||
- enterprise image references
|
||
|
||
Уходит в `crank-cloud`:
|
||
|
||
- hosted deployment manifests
|
||
- cloud operational manifests
|
||
|
||
### 4.3. CI/CD
|
||
|
||
Остается в `crank-community`:
|
||
|
||
- public Community `CI`
|
||
- public Community `Deploy`
|
||
|
||
Уходит в `crank-enterprise`:
|
||
|
||
- private release workflows
|
||
- private image publishing
|
||
|
||
Уходит в `crank-cloud`:
|
||
|
||
- hosted release workflows
|
||
- control-plane rollout workflows
|
||
|
||
### 4.4. Documentation
|
||
|
||
Остается в `crank-community`:
|
||
|
||
- public architecture
|
||
- public API/MCP contracts
|
||
- Community deployment docs
|
||
- Community smoke docs
|
||
|
||
Уходит в `crank-enterprise`:
|
||
|
||
- enterprise operator docs
|
||
- enterprise packaging docs
|
||
- enterprise support runbooks
|
||
|
||
Уходит в `crank-cloud`:
|
||
|
||
- hosted operations docs
|
||
- tenant control-plane docs
|
||
- cloud support runbooks
|
||
|
||
## 5. Правила переноса
|
||
|
||
При переносе нужно соблюдать:
|
||
|
||
1. Сначала переносится Community в `crank-community` как рабочая самостоятельная база.
|
||
2. Потом переносится private self-hosted контур в `crank-enterprise`.
|
||
3. Потом переносится hosted/control-plane контур в `crank-cloud`.
|
||
4. Public contracts должны остаться в Community и не зависеть от private кодовой базы.
|
||
5. Private repos не должны требовать обратного копирования логики в Community.
|
||
|
||
## 6. Что должно произойти перед физическим split
|
||
|
||
Перед началом physical split нужно выполнить отдельно:
|
||
|
||
1. Создать репозитории:
|
||
- `crank-community`
|
||
- `crank-enterprise`
|
||
- `crank-cloud`
|
||
2. Определить owners и access policy для private repositories.
|
||
3. Зафиксировать отдельные package/release names.
|
||
4. Подготовить начальные README и baseline workflows для всех трех репозиториев.
|
||
|
||
Текущий статус:
|
||
|
||
- `crank-community` уже создан;
|
||
- `crank-enterprise` уже создан;
|
||
- `crank-cloud` уже создан;
|
||
- bootstrap templates уже перенесены в целевые repositories;
|
||
- baseline-import в `crank-community` уже был откачен из истории и не считается финальным public source state;
|
||
- management gate закрыт, следующий шаг — начать physical split.
|
||
|
||
Пока эти четыре пункта не выполнены, physical split не начинается.
|
||
|
||
Техническая заготовка для этого шага уже живет в:
|
||
|
||
- `templates/repositories/crank-community/*`
|
||
- `templates/repositories/crank-enterprise/*`
|
||
- `templates/repositories/crank-cloud/*`
|
||
|
||
## 7. Практический вывод
|
||
|
||
Следующий управленческий шаг после завершения текущего boundary-трека:
|
||
|
||
- начать physical split с `crank-community`
|
||
- сделать whitelist-based import для `crank-community` и только его считать финальным public source of truth
|
||
- создать `crank-enterprise`
|
||
- создать `crank-cloud`
|
||
|
||
После этого уже можно планировать фактическое разнесение кода и delivery files.
|