Gerenciamento de Releases
O gerenciamento de releases coordena quando e como os serviços Rust são enviados: regras de versionamento, trens de release, aprovações de mudança e comunicação. Uma boa higiene de release torna o rollback crível e os stakeholders previsíveis.
Receita
Cartão de receita de referência rápida - pronto para copiar e colar.
# Release: orders-api 2026.07.09
## Artefatos
- Imagem: `orders-api:sha-9f2a1bc` (Rust 1.97.0, edition 2024)
- Crate (interno): `acme-billing v2.4.0`
## Migrações
- sqlx `20260709_add_tax_code` (expandir, compatível com versões anteriores)
## Rollback
- `kubectl rollout undo` para `sha-7c1b2aa`
- Escalar workers para 0 se o payload do job for incompatível
## Stakeholders
- #releases, macro de suporte atualizadaQuando usar isso:
- Múltiplos squads enviam a mesma plataforma semanalmente
- API voltada para o cliente com compromissos de SLA
- Crates compartilhados consumidos por muitos binários internos
- Conformidade exige registros de mudança
Exemplo de Trabalho
//! release_metadata.rs - automatiza notas de release a partir do ambiente de build.
use serde::Serialize;
#[derive(Debug, Serialize)]
pub struct ReleaseMetadata {
pub service: String,
pub git_sha: String,
pub rust_version: String,
pub release_date: String,
}
pub fn from_env() -> ReleaseMetadata {
ReleaseMetadata {
service: std::env::var("SERVICE_NAME").unwrap_or_else(|_| "orders-api".into()),
git_sha: std::env::var("GIT_SHA").unwrap_or_else(|_| "unknown".into()),
rust_version: env!("RUSTC_VERSION").to_string(),
release_date: std::env::var("RELEASE_DATE").unwrap_or_else(|_| "undated".into()),
}
}
pub fn format_notes(meta: &ReleaseMetadata, changes: &[&str]) -> String {
let mut out = format!(
"# Release {} {}\n\n- SHA: {}\n- Rust: {}\n\n## Mudanças\n",
meta.service, meta.release_date, meta.git_sha, meta.rust_version
);
for c in changes {
out.push_str(&format!("- {c}\n"));
}
out
}# Compila binário de release com metadados incorporados
export GIT_SHA=$(git rev-parse --short HEAD)
export RELEASE_DATE=$(date -u +%Y-%m-%d)
cargo build --releaseO que isso demonstra:
- Notas de release puxam SHA e toolchain do ambiente CI, não cópia manual
- Crates internos usam semver; serviços usam datas ou IDs de trem
- Migração e passos de rollback vivem no mesmo documento de release
Mergulho Profundo
Regras de Versionamento
- Bibliotecas em crates.io - Semver estritamente; quebras de compatibilidade aumentam a versão principal.
- Crates internos do workspace - Semver dentro do monorepo; coordene com
cargo workspaces. - Serviços implantáveis - Versão de calendário (
2026.07.09) ou trem de release (R24) para clareza na comunicação.
Trem de Release
- Cortar branch na terça-feira; testar em staging por 48h; janela de produção na quinta-feira.
- CAB (conselho consultivo de mudanças) revisa migrações de esquema e mudanças
unsafe. - Congelar antes de feriados de pico de comércio; patches de segurança são isentos com aprovação do EM.
Artefatos de Build Rust
- Fixar
rust-toolchain.tomlem 1.97.0 com edition 2024. cargo auditableou SBOM anexado à imagem do contêiner.- Mesmo hash de
Cargo.lockpara binários de API e worker em um único release.
Armadilhas
- Tag
latestflutuante - Alvo de rollback desconhecido. Correção: Apenas tags SHA imutáveis. - Release sem nota de migração - Oncall adivinha a segurança do rollback. Correção: Fase de expansão-contração no template de release.
- Lockfiles diferentes API vs worker - Discrepância sutil de dependência. Correção: Workspace compartilhado ou verificação de hash de lockfile no CI.
- Aumento silencioso de MSRV - Times downstream quebram. Correção: MSRV no changelog do crate e notas de release.
- Deploy em produção na sexta-feira - Oncall de fim de semana sem contexto. Correção: Política de janela de trem.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Deploy contínuo por PR | Testes fortes + salvaguardas de canário | Fase pesada de contrato de esquema |
| GitOps (Argo CD) | Estado desejado declarativo | Time carece de fluência em k8s |
| Botão de release manual | Controle de mudança regulamentado | Microsserviços de alta frequência |
| Branch de serviço LTS | Contratos de suporte longos | Produto SaaS em rápida evolução |
FAQs
Como versionar binários internos?
Data ou ID do trem para deployables; semver para crates publicados.
Notas de release para hotfix?
Mesmo template, mais curto; marcar HOTFIX e linkar ticket de incidente.
Quem aprova releases de esquema?
DBA + proprietário do serviço; CAB para tabelas entre frotas.
Ordem de release do workspace Cargo?
Grafo de dependência de baixo para cima; teste de integração após todos os crates serem atualizados.
Ferramentas CLI via cargo-dist?
Marcar release git; anexar SBOM; anunciar canal separadamente da API do servidor.
Exceções de congelamento?
CVE de segurança com evidência cargo audit; aprovação do EM + segurança.
Comunicar ao suporte?
Macro em #releases: impacto no usuário, hora de início UTC, status do rollback.
Checklist de release no repositório?
docs/release.md com comandos de copiar e colar para cada ambiente.
Release de migração Edition 2024?
Trem dedicado; sem mistura de funcionalidades; MSRV e correção de clippy antes do corte.
Medir saúde do release?
CFR DORA e lead time por serviço; tendência na revisão trimestral.
Relacionados
- Estratégias de Rollback - política de reversão
- Ambientes & Promoção de Configuração - fluxo de promoção
- Feature Flags & Entrega Progressiva - desacoplar exposição
- Métricas DORA - medição de entrega
- Melhores Práticas de Entrega - lista de resumo
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.