docs: add repository split map
This commit is contained in:
a.tolmachev
@@ -0,0 +1,200 @@
|
||||
# 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`, adapters, schema and mapping crates;
|
||||
- capability model;
|
||||
- Community auth model:
|
||||
- static AI-agent key;
|
||||
- only `security_level = standard`;
|
||||
- `deploy/community/*`;
|
||||
- public CI/CD for Community;
|
||||
- Community docs, smoke docs и demo flow.
|
||||
|
||||
В нем не должно остаться:
|
||||
|
||||
- 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;
|
||||
- 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;
|
||||
- private container/release packaging;
|
||||
- enterprise operator docs.
|
||||
|
||||
### 3.3. `crank-cloud`
|
||||
|
||||
Private repository.
|
||||
|
||||
В нем должны жить:
|
||||
|
||||
- cloud control plane;
|
||||
- metering;
|
||||
- billing;
|
||||
- hosted tenant management;
|
||||
- hosted operational tooling;
|
||||
- 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
|
||||
|
||||
Уходит в `crank-enterprise`:
|
||||
|
||||
- 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 для всех трех репозиториев.
|
||||
|
||||
Пока эти четыре пункта не выполнены, physical split не начинается.
|
||||
|
||||
## 7. Практический вывод
|
||||
|
||||
Следующий управленческий шаг после завершения текущего boundary-трека:
|
||||
|
||||
- создать `crank-community`
|
||||
- создать `crank-enterprise`
|
||||
- создать `crank-cloud`
|
||||
|
||||
После этого уже можно планировать фактическое разнесение кода и delivery files.
|
||||
Reference in New Issue
Block a user