O Que É um Deployment Job? Enviando Código a Partir de um Pipeline
Um deployment job é o job de pipeline que pega um artifact construído e o libera para um environment de destino, como staging ou produção.
Jobs de build e test preparam seu código; um deployment job de fato o envia. É a parte do pipeline que faz push de uma imagem de container, copia arquivos para um servidor, atualiza um serviço na nuvem ou aplica mudanças de infraestrutura. Como muda o sistema em execução, um deployment job carrega mais risco e geralmente tem guardas extras ao seu redor.
O que um deployment job faz
Ele pega o artifact produzido antes no pipeline e o aplica a um environment: fazendo push de uma imagem para um registry e fazendo o rollout, rodando migrations de banco de dados ou invocando uma ferramenta de deploy. O destino geralmente é nomeado (staging, produção) para que o pipeline possa rastrear o que está onde.
Como deploy jobs diferem de build jobs
- Eles têm como alvo um environment nomeado, não apenas um workspace.
- Eles muitas vezes exigem aprovações ou regras de environment protegido.
- Eles são frequentemente restritos a branches ou tags específicas.
- Eles podem rodar um de cada vez para evitar deploys concorrentes.
Um exemplo rápido
Um deploy job pode rodar kubectl set image deployment/app app=registry/app:${SHA} para fazer o rollout de um novo container, ou chamar uma CLI de plataforma para liberar o último build. O ${SHA} amarra o deploy ao commit exato que foi construído e testado.
Guardas nos deploys
Como um deploy muda a produção, as equipes adicionam aprovações, proteção de environment e limites de concorrência. Um caminho de rollback é essencial: se o deploy job enviar um build ruim, um job de rollback deve ser capaz de colocar a versão anterior de volta rapidamente.
Deploy jobs e confiabilidade
Um deploy que falha na metade é pior do que um que nunca começou. Deploy jobs confiáveis são idempotentes e verificáveis, com uma verificação pós-deploy confirmando que a nova versão está saudável. Runners estáveis reduzem interrupções no meio do deploy; runners gerenciados (Latchkey) fazem retry de falhas transitórias de infraestrutura, para que um deploy tenha menos chance de falhar por razões alheias ao seu código.
Principais conclusões
- Um deployment job libera um artifact construído para um environment nomeado.
- Ele carrega mais risco que os build jobs, então recebe aprovações e proteção.
- Combine-o com um caminho de rollback e uma verificação de saúde pós-deploy.