O documento descreve a jornada da Infoglobo em adotar a entrega contínua, começando com testes manuais demorados e deploys manuais em produção levando até um mês, para um processo automatizado com testes funcionais e de performance automatizados e deploys em produção em até 2 horas.
5. 5
Sobre a Infoglobo
● Focada no Impresso em processo de
migração para o digital;
● Empresa sem Cultura Ágil (apenas em TI)
● Alguns produtos:
http://twixar.me/Yv5
7. 7
Cenário Anterior
● Execução de Testes Unitários dependia de
“boa vontade”
● Validação (manuais e automatizadas) das
funcionalidades levando mais de 2 dias
● Correria para corrigir testes automatizados
falhando (ou nem corrigir)
● Deploys feitos em PRD de forma manual pela
equipe de INFRA
http://twixar.me/Yv5
8. 8
Cenário Anterior
● Demora de até 1 mês para colocar uma
mudança em PRD
● Necessidade de uma Auditoria antes de uma
versão estar disponível para PRD
● Erros em log eram ignorados
http://twixar.me/Yv5
11. 11
Benefícios
● Autonomia aos times
● Reduzir erros
● Reduzir estresse
● Flexibilidade de Implantação
● Prática leva a perfeição
● Todo check-in é uma versão em potencial
http://twixar.me/Yv5
12. 12
Princípios
● Criar um processo de confiabilidade e
repetitividade de entrega de versão
● Automatize quase tudo
● Mantenha tudo sob controle de versão
● Se é difícil, faça com mais frequência e
amenize o sofrimento
● A qualidade DEVE estar presente desde o
início
http://twixar.me/Yv5
13. 13
Princípios
● Pronto quer dizer versão entregue
● Todos são responsáveis pelo processo de
entrega
● Melhoria Contínua
http://twixar.me/Yv5
14. 14
Exemplos
● Google: 8 minutos entre DEV e PRD
● Facebook: 2 vezes por dia
● Linkedin: 30 minutos entre DEV e PRD
● Etsy: 30 deploys por dia feitos por 200+
pessoas;
15. 15
Pipeline de Implantação
● Manifestação automatizada do processo de
levar o software do controle de versão até os
usuários.
http://twixar.me/Yv5
17. 17
Práticas
● Compile seus binários somente uma vez
● Faça a implementação da mesma maneira
em cada ambiente
● Use Smoke Tests
● Implante em uma cópia de Produção
● Cada mudança deve ser propagada pelo
pipeline instantaneamente
● Se qualquer parte do pipeline falhar, pare o
processo
http://twixar.me/Yv5
19. 19
Estágio de Commit
● Entrada para o Pipeline de Implantação
● Feedback para os devs
● Entrada: Código - Saída: Binários e Relatórios
● CUIDADO: poucos testes e qualidade de
código ruim
24. 24
Análise de Log
● Logs da Aplicação
● Sumarização do TOP 15 erros que mais
ocorreram
● Verificação de erros 404 e 50X
● Envio de e-mail para todos os responsáveis
● Tomada de decisão se o processo vai até o
final (Deploy em PRD)
● Muito importante para os produtos mais
antigos
● Preocupação de INFRA
30. 30
Alguns Resultados
● Deploy em PRD NÃO é mais um evento
temido
● Facilidade na identificação da causa de erros
em PRD
● Replicabilidade do Processo
● Feedback
● Validação diluída no processo, não
precisamos mais de vários dias para os testes
● Abertura de Solicitação de Deploy
automatizada
31. 31
Alguns Resultados
● Análise de Log parte do processo de todos os
produtos
● Deploys automatizados em PRD feitos por
Atendimento Especializado (utilizando
Jenkins)
● Não é mais necessária auditoria antes dos
Deploys em PRD
● Deploy em PRD pode ser feito a qualquer
momento
● Sem erros gerados por intervenção manual
35. 35
Desafios
● Acabar com os mitos:
○ Testes “atrasam” o processo
○ Custo da Qualidade é alto demais
○ “Só está quebrando um teste, não precisa
investigar”
● Testes Unitários
● DevOps
● Agilidade na Organização
http://twixar.me/Yv5
37. 37
Próxima Fase
● Desenvolvedores fazendo Deploys em PRD
● Projetos desenvolvidos por Fornecedores no
Pipeline
● Levar o conhecimento de Entrega Contínua
para todos os times
● Implementar Pipeline para Mobile
○ já começamos com Android
http://twixar.me/Yv5
38. 38
Referências
● http://manifestoagil.com.br/
● The Facebook Release Process
● Continuous Delivery at Google
● The Evolution of Continuous Delivery at Scale
@ Linkedin
● Deploying the Netflix API
http://twixar.me/Yv5
41. 41
Selenium Webdriver
R$ 410,00 à vista ou 2x R$ 205,00
PROMOÇÃO. R$ 310,00 à vista ou 2x R$ 155,00
para inscrições até 20/07/2015
http://rtstreinamentos.com.br/contato/
http://twixar.me/Yv5
1 - qualquer pessoa pode colocar qualquer versão em qualquer ambiente; os testers não precisam ficar esperando que alguém disponibilize uma versão para teste
2 - não só erros de software, mas também de ambiente, arquivos de configuração, scripts de compilação, banco de dados, erro manual ao fazer deploy por infra
3 - entregar em PRD não devem ser um evento
4 - executar a aplicação em um ambiente novo deve ser simples, vinte servidores com configurações manuais diferentes
5- implantações feitas do mesmo jeito em qualquer ambiente e estratégia de testes
6 - não existe mais o evento “gerar pacote para PRD”
1 - entregar software deve ser tão simples quanto clicar em um botão (fornecer e gerenciar o ambiente, instalar a versão correta, configurar a aplicação)
2 - processo de compilação automatizado até onde precise de uma decisão manual
3 -
4 - ao invés de esperar meses para fazer um deploy, faça pequenos deploys (exemplo do problema no Extra)
5 - encontrando erros mais cedo, mais barata é a correção
6 - funcionalidade pronta quando está entregando valor aos usuários
7 - problemas com silos
8 -