specsfy-specialist-delivery-engineering

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Engenharia de entrega

交付工程

Quando usar

适用场景

Acionar quando o projeto tem pipeline (
```
*.yml
```
de CI/CD), estratégia de release, promoção entre ambientes ou plano de rollout/rollback.
Acionar também para escolher entre rolling, blue-green, canary ou feature flag diante de uma mudança específica.
Não acionar para a implantação de baixo nível dentro de um cluster Swarm (use
```
$specsfy-specialist-docker-swarm
```
) nem para decidir qual sinal prova que o rollout está saudável (use
```
$specsfy-specialist-observability
```
) — aqui o foco é o desenho do pipeline e da estratégia de promoção.
Combinar com
```
$specsfy-specialist-application-security
```
quando o pipeline manipula credenciais de produção ou publica artefato assinado.

当项目拥有CI/CD pipeline（
```
*.yml
```
文件）、release策略、环境间制品晋升或rollout/rollback计划时启用。
也可在针对特定变更选择rolling、blue-green、canary或feature flag策略时启用。
请勿在Swarm集群内进行底层部署时启用（请使用
```
$specsfy-specialist-docker-swarm
```
），也勿用于判定rollout健康状态的指标选择（请使用
```
$specsfy-specialist-observability
```
）——本技能的核心是pipeline设计与制品晋升策略。
当pipeline处理生产环境凭证或发布签名制品时，请结合
```
$specsfy-specialist-application-security
```
使用。

Fluxo

流程

Mapear commit, artefato, ambientes, aprovações necessárias e owner de cada promoção antes de desenhar o pipeline.
Tornar build e testes reproduzíveis a partir de lockfiles versionados — nunca resolver dependência "mais recente" no momento do build.
Produzir o artefato imutável uma única vez e promovê-lo, sem recompilação, entre ambientes (o binário testado em staging é bit-a-bit o mesmo publicado em produção).
Separar credenciais, permissões e trust boundaries por job — o job que builda não tem a credencial que publica em produção.
Coordenar migrations de schema com compatibilidade entre a versão antiga e a nova da aplicação durante toda a janela de rollout (expand/contract).
Definir a estratégia de rollout, os sinais objetivos de sucesso, o critério de pausa e o mecanismo de rollback antes do primeiro deploy real.
Registrar proveniência (de onde veio o artefato), versão, evidência de teste e resultado do rollout de forma auditável.

在设计pipeline前，梳理commit、artifacts、环境、所需审批及各阶段制品晋升的负责人。
基于版本化的lockfiles实现build与测试的可重复性——绝不在build时拉取「最新」依赖。
仅生成一次不可变artifacts，无需重新编译即可在环境间晋升（ staging环境测试通过的二进制文件与生产环境发布的完全一致）。
按job划分凭证、权限及信任边界——负责build的job不具备生产环境发布权限。
在整个rollout周期内协调schema migrations，确保新旧版本应用的兼容性（采用expand/contract模式）。
在首次实际deploy前，明确rollout策略、成功指标、暂停条件及rollback机制。
以可审计的方式记录artifacts来源、版本、测试证据及rollout结果。

Padrões

最佳实践

Usar menor privilégio, credenciais temporárias (OIDC/STS em vez de secret estático de longa duração) e actions/dependências de pipeline fixadas por hash ou versão exata, não por tag móvel (
```
@latest
```
,
```
@main
```
).
Não reconstruir o artefato para cada ambiente; construir uma vez, assinar ou gerar digest, e promover a mesma referência imutável.
Impedir concorrência incompatível (dois deploys do mesmo serviço ao mesmo tempo) e impedir deploy de um commit que não passou pelo pipeline de teste completo.
Manter ambientes reproduzíveis por infraestrutura como código; configuração de ambiente fica fora do artefato (env vars, secret manager), nunca embutida no build.
Exigir smoke checks funcionais e observabilidade ativa antes de considerar um rollout concluído — "o deploy terminou sem erro" não é o mesmo que "o serviço está saudável".
Tratar rollback de código (reverter para o binário anterior) e rollback de dados (reverter uma migration já aplicada) como problemas distintos com planos distintos — nem toda migration é reversível sem perda de dado.
Preservar trilha auditável de quem promoveu o quê, quando e com qual aprovação, sem jamais registrar segredo em log ou artefato de auditoria.

遵循最小权限原则，使用临时凭证（如OIDC/STS，而非长期静态secret），pipeline的actions/依赖需通过哈希或精确版本锁定，而非动态标签（如
```
@latest
```
、
```
@main
```
）。
不为每个环境重新构建artifacts；仅构建一次，进行签名或生成digest，然后晋升同一不可变引用。
避免冲突并发（同一服务同时进行两次deploy），禁止部署未通过完整测试pipeline的commit。
通过基础设施即代码保持环境可重复性；环境配置需独立于artifacts（如通过环境变量、secret manager），绝不能嵌入build产物中。
在判定rollout完成前，需执行功能冒烟测试及主动观测——「deploy无错误完成」并不等同于「服务处于健康状态」。
将代码rollback（回退至之前的二进制文件）与数据rollback（回退已执行的migration）视为独立问题，制定不同的应对方案——并非所有migration都能无数据损失地回退。
保留可审计的记录，包括谁在何时晋升了什么内容、获得了哪些审批，绝不在日志或审计制品中记录敏感信息。

Antipadrões

反模式

Pipeline que builda a imagem de novo em cada ambiente (
```
build
```
no job de staging e outro
```
build
```
no job de produção): o artefato testado em staging não é garantidamente o mesmo que vai para produção, mesmo com o mesmo Dockerfile — dependências resolvidas "latest" ou cache diferente produzem binários diferentes.
Feature flag sem owner nem expiração: acumula flags mortas que ninguém lembra o propósito, aumentando a superfície de combinações não testadas.
Migration de schema aplicada no mesmo deploy que remove a coluna antiga: quebra a versão anterior da aplicação se o rollback de código precisar rodar contra o schema já alterado — use expand (adicionar) num deploy e contract (remover) só depois que nenhuma versão antiga depende da coluna.
Secret de produção acessível a um job que roda em pull request de fork externo: o contexto de PR externo não deve ter acesso a nenhum secret de ambiente protegido.

在每个环境中重新构建镜像的pipeline（如staging job执行
```
build
```
，生产环境job也执行
```
build
```
）：即使使用相同的Dockerfile，staging环境测试的artifacts也无法保证与生产环境一致——拉取「latest」依赖或不同缓存都会导致二进制文件差异。
无负责人及过期时间的feature flag：会积累无人知晓用途的废弃flag，增加未测试组合的风险面。
在同一deploy中执行schema migration并删除旧列：若代码rollback需要基于已修改的schema运行，会导致旧版本应用崩溃——应在一次deploy中执行expand（添加）操作，待所有旧版本应用不再依赖该列后，再执行contract（删除）操作。
外部fork的PR执行的job可访问生产环境secret：外部PR上下文不应具备任何受保护环境的secret访问权限。

Validação

验证

Lint/validação estática do pipeline, execução completa em branch segura e um teste deliberado de falha (o pipeline realmente para e não promove artefato quando um step crítico falha).
Verificação de digest do artefato, SBOM e assinatura/proveniência (attestation) quando essas práticas forem adotadas pelo projeto.
Ensaio completo de rollout e de rollback em ambiente representativo antes da primeira execução em produção — não confiar apenas na leitura da configuração do provedor.
Confirmação de gates de aprovação, branch protection e permissões configuradas no provedor (não apenas no arquivo de workflow, que pode ser sobrescrito por quem tem permissão de push).
Não declarar um pipeline "seguro" ou um rollout "concluído" sem essas evidências; ausência de erro no log não é prova de saúde do serviço.

对pipeline进行静态检查/验证，在安全分支上完整执行，并进行故意故障测试（当关键步骤失败时，pipeline需真正暂停且不晋升artifacts）。
若项目采用了相关实践，需验证artifacts的digest、SBOM及签名/来源证明（attestation）。
在首次生产环境执行前，在具有代表性的环境中完整演练rollout与rollback——切勿仅依赖对供应商配置的审阅。
确认供应商端配置的审批闸门、分支保护及权限（不能仅依赖workflow文件，因为拥有推送权限的人可覆盖该文件）。
若无上述证据，不得宣称pipeline「安全」或rollout「完成」；日志无错误并不代表服务健康。

specsfy-specialist-delivery-engineering

Original

Translation

Engenharia de entrega

交付工程

Quando usar

适用场景

Fluxo

流程

Padrões

最佳实践

Antipadrões

反模式

Validação

验证

Skills relacionadas

相关技能