Busque em todas as páginas da documentação
Scripts nos quais você pode confiar sem supervisão seguem as mesmas regras de operabilidade dos serviços de produção: modos de falha previsíveis, padrões seguros e logs que os operadores podem pesquisar às 3 da manhã.
--dry-run para ferramentas mutáveis.if __name__ == "__main__" e uma função main() -> int. Mantém os módulos importáveis e testáveis.--help e no README.--dry-run para ações destrutivas. Imprima as mudanças pretendidas sem efeitos colaterais.encoding="utf-8" em arquivos de texto. Evite surpresas com padrões de plataforma.cd para a raiz do projeto.known_hosts gerenciados ou certificados.pyproject.toml quando o escopo aumenta.A primeira execução em produção sem prévia causa exclusões irreversíveis - o dry-run é o seguro mais barato.
Para ferramentas locais rápidas, sim; scripts de produção agendados devem usar logging com níveis.
argparse para scripts cron sem dependências; typer ao construir ferramentas de operador com múltiplos comandos.
YAML/TOML no git para não-segredos; variáveis de ambiente para segredos; CLI substitui em caso de conflito.
Runbook com comandos de exemplo, códigos de saída, tempo de execução esperado e etapas de rollback.
Sim, com sessão boto3 reutilizada, retentativas e função de menor privilégio - veja a seção Cloud SDK.
pytest main() com tmp_path; teste de integração em staging com dry-run e depois ao vivo em dados de amostra.
Quando dependências, SLAs e observabilidade excederem um arquivo e a matriz de cron se tornar insustentável.
Armazene UTC em logs e nomes de arquivos; documente o cron em horário local apenas quando o negócio exigir.
Sucesso silencioso em falha parcial - sempre agregue erros e saia com código não-zero quando algo falhar.
Versões de Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, e uv 0.6+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026