O documento aborda os princípios e práticas de entrega contínua, destacando a importância da automação e integração contínua para reduzir riscos e aumentar a eficiência no desenvolvimento de software. Enfatiza a cultura necessária nas equipes e os erros comuns a evitar durante o processo de entrega. Além disso, discute a arquitetura de software como um fator fundamental para suportar um fluxo de trabalho de entrega contínua eficaz.

1. Arquitetura de Software
para a Entrega Contínua
Otávio Calaça Xavier
otaviocx@oobj.com.br

2. Roteiro
- O que é Entrega Contínua e DevOps?
- O que é Integração Contínua?
- Erros Comuns em Entrega de
Software;
- Princípios de Entrega Contínua;
- Práticas em Arquitetura de Software;

3. O que é Entrega Contínua?
“Entrega Contínua é uma
disciplina de desenvolvimento
na qual software é construído de
tal maneira que o mesmo pode
ser colocado em produção a
qualquer momento.”
Martin Fowler, Jez Humble

4. O que é Entrega Contínua?
O principal problema:
Se alguém tem uma grande ideia,
como entregar isso aos usuários o
mais rápido possível?

5. Por que?
• Reduzir custos;
• Colocar funcionalidade em produção
mais rapidamente;
• Menos defeitos em produção;
• Ser mais rápido que os competidores;
• Dormir em paz em dia de implantação /
atualização.

6. E as pessoas?
• A equipe precisa ter a entrega
contínua como cultura;
• Todos são envolvidos no processo
• Comercial
• Desenvolvimento
• Testes
• Operações
• Usuários

7. DevOps

8. O que é Integração Contínua (CI)?
“Integração contínua é uma prática
em desenvolvimento de software em
que os membros do time integram
seu trabalho frequentemente,
usualmente cada pessoa integra pelo
menos uma vez ao dia – levando a
múltiplas integrações por dia.”
Martin Fowler, Paul M. Duvall

9. O que é Integração Contínua?
Construir o software a
cada mudança.

10. O que é uma construção (build) ?
• Muito mais que compilação;
• Consiste em:
• Compilação;
• Teste;
• Inspeção;
• Implantação e
• Algumas outras coisas.
• Processo de colocar código fonte junto e
verificar se o software funciona como uma
unidade coesa.

11. Por que?
• Reduzir riscos;
• Reduzir processos manuais repetitivos;
• Gerar software que pode ser implantado a
qualquer momento e em qualquer local;
• Permitir maior visibilidade do projeto;
• Estabelecer maior confiança na produção
de software da equipe de desenvolvimento.

12. Um dia na vida com CI

13. Como ter a tal da Integração “contínua”?
• Identificar;
• Um processo que precise ser automatizado.
• Construir;
• Fazer a automação repetível e confiável.
• Compartilhar;
• Usando sistemas de controle de versão (SVN).
• Fazer isso contínuo.
• Garantir que o processo automatizado rode a
cada mudança.

14. Integração contínua e você...
• Commit o código frequentemente;
• Não commit código quebrado!
• Corrija builds quebrados imediatamente;
• Escreva testes automatizados;
• Todos os testes e inspeções devem passar;
• Execute construções privadas;
• Evite código quebrado.

15. Fluxo da Integração Contínua
Pegue o
código fonte
mais recente
Desenvolva
sua
atividade
Faça um
build na
sua máquina
Rode os testes
automatizados
Commit seu
código
Faça um
build na
máquina de
integração

16. Erros Comuns em
Entrega de Software

17. Implantar software manualmente
• Criação de extensos manuais de
implantação;
• Falhas frequentes em implantações que
requerem apoio do time de
desenvolvimento;
• Medo da implantação/atualização tanto
pela operação quanto pelo cliente.

18. Implantar em um ambiente parecido com o de
produção apenas depois do desenvolvimento
ser concluído
• Riscos de falsos positivos com testes em
ambiente de desenvolvimento;
• A fase de homologação pode ser o
primeiro momento que a equipe de
operações tem contato com o software;
• Pouca colaboração entre equipes (DevOps)

19. Gerenciamento de Configurações
Manual dos Ambientes de Produção
• Mesmo que a implantação em ambiente de
homologação seja bem sucedida, pode falhar em
produção;
• O time de operações gasta muito tempo
preparando um ambiente para uma nova release;
• Diferentes versões de Sistemas Operacionais e
Infraestrutura de terceiros, não intencional e
desnecessária;
• Impossível voltar atrás rapidamente à uma
versão anterior do ambiente (S.O., banco de dados,
servidor de aplicação, etc.).

20. Entrega Contínua baseia-se em
dois pilares: Automação e
Frequência

21. Toda modificação deve iniciar o processo de
feedback
• Um software em funcionamento pode
ser decomposto em 4 componentes:
• Código Executável;
• Configuração;
• Ambiente de Hospedagem;
• Dados (estrutura).
• Se qualquer uma das partes mudar,
isso significa uma mudança no
comportamento da aplicação.

22. O feedback deve ser recebido o quanto antes
• Em um processo completamente automatizado, o
maior problema será o hardware necessário para
atender o problema;
• Se for manual, dependemos de pessoas.
• Pessoas demoram, podem introduzir erros e são
difíceis de serem auditadas. Além disso,
construção, teste e implantação manuais, são
atividades cansativas e desmotivantes.

23. O time de entrega deve receber o feedback e
agir
• Time de entrega inclui: desenvolvedores,
testadores, equipe de operação,
especialistas de infraestrutura e gestores;
• Trabalhar juntos com reuniões rápidas e
frequentes para melhorar o processo de
entrega;
• Comunicação deve ser clara, eficiente e
eficaz (atingir as pessoas certas no
momento certo).

24. Princípios da Entrega
Contínua

25. Crie um processo repetível e confiável
de lançamento do software
https://www.flickr.com/photos/feliperoos/4304276481/

26. Automatize
praticamente tudo
https://www.flickr.com/photos/tjblackwell/7819341478/

27. Mantenha
tudo em
controle de
versão

28. SSee ddooii,, ffaaççaa ccoomm mmaaiiss
ffrreeqquuêênncciiaa,, ee aaddiiaannttee aa ddoorr

29. IInnccoorrppoorree qquuaalliiddaaddee
àà ccoonnssttrruuççããoo
http://www.flickriver.com/photos/42421638@N07/sets/72157628665077677/

30. ““FFeeiittoo”” ssiiggnniiffiiccaa llaannççaaddoo
ppaarraa oo cclliieennttee..

31. TTooddooss ssããoo rreessppoonnssáávveeiiss ppeelloo
pprroocceessssoo ddee eennttrreeggaa

32. Melhoria
Contínua

33. Benefícios
• Capacitação de times;
• Redução de Erros;
• Redução do Estresse;
• Flexibilidade de Implantação;
• A prática leva a perfeição;

34. Mudanças

35. Introdução de Mudanças

36. Mudanças pelo tempo

37. Mudanças pelo tempo

38. Controle de Versão
• Colocar tudo em controle de versão;
• Não guarde nada apenas em seu
ambiente;
• Faça merges frequentes (o mais
breve possível);
• Use mensagens significantes em
seus commits;

39. Arquitetura
“Existem dois elementos comuns [nas definições]:
um é a decomposição em alto nivel de um sistema
em suas partes; o outro são decisões difíceis de
alterar.
…existem diversas arquiteturas em um sistema, e a
visão do que é significativo em termos de
arquitetura pode mudar durante o ciclo de vida de
um sistema.”
Martin Fowler - Padrões de Arquitetura
de Aplicações Corporativas.

40. O impacto da arquitetura

41. Arquitetura
• Crie uma arquitetura modular que
possua partes que possam ser
implantadas sozinhas.
• A cultura de desenvolvimento deve
seguir a arquitetura proposta.
• Revise e Inspecione alterações que
podem quebrar a arquitetura.

42. Arquitetura – feature toggles

43. Arquitetura – branch by abstraction

44. Arquitetura – branch by abstraction

45. Arquitetura – branch by abstraction

46. Arquitetura – branch by abstraction

47. Arquitetura – branch by abstraction

48. Referências
Continuous Delivery: Reliable Software Releases through Build,
Test, and Deployment Automation by Jez Humble , David Farley
Continuous Integration: Improving Software Quality and Reducing
Risk by Paul M. Duvall , Steve Matyas, Andrew Glover
BranchByAbstraction by Martin Fowler
http://martinfowler.com/bliki/BranchByAbstraction.html
FeatureTogle by Martin Fowler
http://martinfowler.com/bliki/FeatureToggle.html
Implementando Entrega Contínua by Marco Valtas
http://www.slideshare.net/mavcunha/implementando-entrega-contnua

49. Obrigado!
• Dúvidas?
Otávio Calaça Xavier
otaviocx@oobj.com.br