Git-style version control for SQL Server stored procedures. Every CREATE, ALTER, or DROP PROCEDURE executed directly on the database becomes a tracked version, with full diff, author attribution, and an optional review workflow, without changing how the team already works.
Documentação em português mais abaixo.
Stored procedures are routinely changed straight on the database, outside any repository. When that happens:
- No history. The previous version is overwritten. There is no "roll back to yesterday".
- No reliable authorship. The server log shows a service login, not the person who ran the change.
- No review. Anything goes straight to production, no second pair of eyes.
So when something breaks after a deploy, answering "what changed in this procedure last week, and who did it?" becomes archaeology.
Proc Tracker turns every schema change into a reviewable, attributable commit.
Capture is transparent. A database-level DDL trigger records changes into a lightweight local queue, and a background worker turns each entry into an immutable version with a computed diff. Nothing is asked of the developer; they keep using SSMS as usual.
flowchart LR
A[Developer<br/>ALTER PROCEDURE] --> B[DDL trigger<br/>ON DATABASE]
B --> C[(proc_change_queue<br/>local table)]
C -->|polling| D[NestJS worker]
D --> E[SHA-256 hash<br/>+ line diff]
E --> F[(PostgreSQL<br/>version · diff · origin)]
F --> G[Next.js UI<br/>explorer · timeline · dashboard]
The queue decouples capture from processing. If the API is down, nothing is lost; it drains the backlog when it comes back.
Changes applied through the system (a merged pull request) are recorded actively by the API, which already knows everything about the change it just executed, so versioning never depends on passive capture for its own actions.
- Automatic capture of
CREATE/ALTER/DROP PROCEDUREacross multiple SQL Server instances. - Immutable versioning with SHA-256 body hashing and line-level diffs, plus side-by-side A↔B comparison of any two versions.
- Baseline import. On first connection every existing procedure is registered as v1, so history doesn't start empty.
- Author attribution. Resolves the database service login into a real person and team by matching connection IP / hostname against the user directory.
- Pull requests for the database. Propose a change, assign a reviewer, discuss in comments, approve, and merge. A single PR can target multiple instances, applied best-effort with per-target status.
- Per-database roles:
viewer→developer→maintainer→leader, scoped to each database. A leader manages the people in their own team. - Real-time updates over WebSocket. The socket carries only an invalidation signal; data is still fetched through the permission-checked HTTP endpoints, so authorization is never duplicated.
- Overview dashboard: change volume and trend, recent activity feed, most-changed procedures, per-instance breakdown.
- Encrypted instance management. Connection credentials stored with AES-256-GCM, and bounded retry with an offline status instead of endless reconnection.
- Scheduled backups of the tracking database.
| Layer | Tech |
|---|---|
| API | NestJS 11, TypeScript, TypeORM |
| Database | PostgreSQL (tracking store), SQL Server (monitored) |
| Web | Next.js 15 (App Router), React, TailwindCSS, TanStack Query |
| Realtime | Socket.IO with an internal event bus |
| Infra | pnpm workspaces (monorepo), Docker Compose |
apps/
api/ NestJS: capture worker, versioning, PRs, auth, dashboard
web/ Next.js: explorer, timeline, PR review, dashboard, admin
config/ instances.yaml (monitored SQL Server targets)
sql/ reference scripts for the queue table and DDL trigger
Requirements: Docker and Docker Compose (plus Node 20 / pnpm for development outside containers).
cp .env.example .env # set JWT_SECRET and ENCRYPTION_KEY
cp config/instances.yaml.example config/instances.yaml
docker compose up -d- Web UI:
http://localhost:3445 - API and Swagger:
http://localhost:3444/docs
The API auto-creates the queue table and DDL trigger on each monitored database when it connects. For manual setup, the equivalent scripts live in sql/.
Controle de versão no estilo Git para stored procedures do SQL Server. Todo CREATE, ALTER ou DROP PROCEDURE feito direto no banco vira uma versão rastreável, com diff completo, autoria e um fluxo opcional de revisão, sem mudar a forma como o time já trabalha.
Procedures são alteradas direto no banco, fora de qualquer repositório. Quando isso acontece:
- Sem histórico. A versão anterior é sobrescrita. Não existe "voltar para ontem".
- Sem autoria confiável. O log do servidor mostra um login de serviço, não a pessoa que executou.
- Sem revisão. Qualquer alteração vai direto para produção, sem uma segunda opinião.
Aí, quando algo quebra depois de um deploy, responder "o que mudou nessa procedure na última semana, e quem fez?" vira arqueologia.
O Proc Tracker transforma cada mudança em um commit revisável e atribuível.
A captura é transparente. Um trigger DDL no nível do banco registra as mudanças numa fila local leve, e um worker em segundo plano transforma cada entrada numa versão imutável com diff calculado. Nada é exigido do desenvolvedor; ele continua usando o SSMS normalmente.
flowchart LR
A[Desenvolvedor<br/>ALTER PROCEDURE] --> B[Trigger DDL<br/>ON DATABASE]
B --> C[(proc_change_queue<br/>tabela local)]
C -->|polling| D[Worker NestJS]
D --> E[Hash SHA-256<br/>+ diff por linha]
E --> F[(PostgreSQL<br/>versão · diff · origem)]
F --> G[UI Next.js<br/>explorer · timeline · dashboard]
A fila desacopla captura de processamento. Se a API cair, nada se perde; ela consome o acúmulo quando volta.
Mudanças aplicadas pelo sistema (um pull request mesclado) são registradas ativamente pela API, que já conhece tudo sobre a mudança que acabou de executar, então o versionamento nunca depende de captura passiva para as próprias ações.
- Captura automática de
CREATE/ALTER/DROP PROCEDUREem várias instâncias de SQL Server. - Versionamento imutável com hash SHA-256 do corpo e diff por linha, além de comparação A↔B lado a lado de duas versões quaisquer.
- Importação de baseline. Na primeira conexão, cada procedure existente é registrada como v1, então o histórico não começa vazio.
- Atribuição de autoria. Resolve o login de serviço do banco em pessoa e time reais, cruzando IP / hostname da conexão com o cadastro de usuários.
- Pull requests para banco de dados. Propor uma mudança, atribuir revisor, discutir em comentários, aprovar e mesclar. Um PR pode apontar para várias instâncias, aplicado best-effort com status por destino.
- Papéis por banco:
viewer→developer→maintainer→leader, com escopo por banco. Um leader gerencia as pessoas do próprio time. - Atualizações em tempo real via WebSocket. O socket carrega apenas o sinal de invalidação; o dado ainda é buscado pelos endpoints HTTP com checagem de permissão, então a autorização nunca é duplicada.
- Dashboard de visão geral: volume e tendência de mudanças, feed de atividade recente, procedures mais alteradas, distribuição por instância.
- Gestão de instâncias com criptografia. Credenciais de conexão guardadas com AES-256-GCM, e retry limitado com status offline em vez de reconexão infinita.
- Backups agendados do banco de rastreamento.
| Camada | Tecnologia |
|---|---|
| API | NestJS 11, TypeScript, TypeORM |
| Banco | PostgreSQL (rastreamento), SQL Server (monitorado) |
| Web | Next.js 15 (App Router), React, TailwindCSS, TanStack Query |
| Tempo real | Socket.IO com barramento de eventos interno |
| Infra | pnpm workspaces (monorepo), Docker Compose |
apps/
api/ NestJS: worker de captura, versionamento, PRs, auth, dashboard
web/ Next.js: explorer, timeline, revisão de PR, dashboard, admin
config/ instances.yaml (instâncias SQL Server monitoradas)
sql/ scripts de referência da tabela de fila e do trigger DDL
Requisitos: Docker e Docker Compose (mais Node 20 / pnpm para desenvolvimento fora dos containers).
cp .env.example .env # defina JWT_SECRET e ENCRYPTION_KEY
cp config/instances.yaml.example config/instances.yaml
docker compose up -d- Interface web:
http://localhost:3445 - API e Swagger:
http://localhost:3444/docs
A API cria automaticamente a tabela de fila e o trigger DDL em cada banco monitorado ao conectar. Para configuração manual, os scripts equivalentes estão em sql/.