Integração Contínua com Python Proposta de Stack Nilo Ney Coutinho Menezes [email protected] 

Sobre • Mestre em informática pela Universidade Federal do Amazonas • Python Software Foundation Fellow (Q3-2020) • Kauna da Python Brasil 2022 - Manaus • Na Bélgica desde 2006 • Nascido em Manaus/AM • Autor do livro Introdução à Programação com Python • Um dos organizadores do PyNorte • Ativo no telegram como @lskbr 

Livro • https://python.nilo.pro.br • Python para iniciantes, mas também para quem já programa e começa a conhecer a linguagem • Código de desconto (30%) no site da Novatec: NILO30 

Cenário • Equipe distribuída com +10 desenvolvedores • Fusos horários diferentes +/- 8h de diferença • Sem peer-review • Mix de desenvolvedores experientes e novatos • Alguns são programadores Javascript ou de outras linguagens 

Os problemas • PEP-8 • Tipos • Formatação • Testes • Documentação • Múltiplas versões de Python 

PEP-8 • Seguir a PEP-8 é importante desde o primeiro dia do projeto • Política de zero warnings (avisos) • Clean Room (não deve dar erros ou avisos e se der tem que tratar) • Ferramenta: flake8 • Negociado com a equipe: aumento da largura de 79 para 120 caracteres 

Tipos • Python suporta anotações • Boa parte de nossas funções trabalham com tipos simples • O resto com classes que nós mesmos criamos • Ajuda com documentação • Ferramenta: mypy • Acha erros de digitação, variáveis não declaradas, não usadas, etc • Exemplo: def maiúsculas_no_inicio(palavra: str) -> str: return palavra.strip().upper() 

Formatação • Python depende da indentação do texto • Nem todos os desenvolvedores seguem o mesmo padrão • Conflitos de formatação entre desenvolvedores • Convenções de linhas em branco • Adoção de um formatador automático • Formatações diferentes poluem os diffs • Ferramenta: yapf 

Testes • Programas desenvolvidos durante muitos meses • Por pessoas diferentes e envolvimento diferente com cada solução • Testes como forma dar segurança aos desenvolvedores na hora de mudar o código ou adicionar novas funcionalidades • Novo teste para cada bug resolvido • Cobertura mínima de 80% • Ferramenta: pytest + pytest-cov 

Documentação • Extração automática da documentação a partir do código fonte • Possiblidade de adicionar texto formatado • Geração de html automática • Ferramenta: Sphinx • Política de documentação: necessário para instalar e rodar a aplicação. • Se parte da documentação estiver na wiki, incluir links na Wiki e vice-versa • Versionada com o código fonte 

Múltiplas Versões • Python muda com o tempo • Exemplo: mudanças nas anotações de tipo em Python 3.9 e 3.10 • Ferramenta: tox • Serve também para rodar todas as outras ferramentas 

Automatizando o build • Roda os testes a cada commit • Em caso de erros, o time tem que corrigir o quanto antes • Diz a lenda que quem quebra o build paga uma pizza • Ferramenta: Travis CI, Codecov (https://codecov.io/) 

O Stack Flake8 MyPy Yapf Pytest Sphinx Tox Travis CI / Codecov VirtualEnv/PipEnv 

Exemplo • Projeto exemplo no GitHub: • https://github.com/lskbr/calculadora_ci 

Exemplo com tox 

Gerando a documentação 

Sphinx 

Conclusão • Automatize o máximo possível • Exija testes e cobertura mínima • Padronize tudo que puder ser automaticamente analisado • Negocie com a equipe • Aproveite 

Obrigado! Tweeter/Telegram @lskbr Blog: https://blog.nilo.pro.br Livro: https://python.nilo.pro.br Exemplo: https://github.com/lskbr/calculadora_ci Imagens: https://unsplash.com/ Apresentação: https://speakerdeck.com/lskbr