Busque em todas as páginas da documentação
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.
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:
//! 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:
cargo workspaces.2026.07.09) ou trem de release (R24) para clareza na comunicação.unsafe.rust-toolchain.toml em 1.97.0 com edition 2024.cargo auditable ou SBOM anexado à imagem do contêiner.Cargo.lock para binários de API e worker em um único release.latest flutuante - Alvo de rollback desconhecido. Correção: Apenas tags SHA imutáveis.| 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 |
Data ou ID do trem para deployables; semver para crates publicados.
Mesmo template, mais curto; marcar HOTFIX e linkar ticket de incidente.
DBA + proprietário do serviço; CAB para tabelas entre frotas.
Grafo de dependência de baixo para cima; teste de integração após todos os crates serem atualizados.
Marcar release git; anexar SBOM; anunciar canal separadamente da API do servidor.
CVE de segurança com evidência cargo audit; aprovação do EM + segurança.
Macro em #releases: impacto no usuário, hora de início UTC, status do rollback.
docs/release.md com comandos de copiar e colar para cada ambiente.
Trem dedicado; sem mistura de funcionalidades; MSRV e correção de clippy antes do corte.
CFR DORA e lead time por serviço; tendência na revisão trimestral.
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+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026