INTEGRAÇÃO
CONTÍNUA
Marlon Bernardes
Da
à ENTREGA
<marlonjb.cb@gmail.com>

INTEGRAÇÃO
CONTÍNUA

“Prática de desenvolvimento de software
aonde os membros de um time
integram seu trabalho freqüentemente
(geralmente multíplas vezes por dia).”

SCM
commit
commit
Como funciona?

SCM
Build
commit
commit
Compila
Otimiza
Gera artefatos
Como funciona?

SCM
Build
commit
commit
Compila
Otimiza
Gera artefatos
Test
Unitários
Integração
Como funciona?

SCM
Build
commit
commit
Compila
Otimiza
Gera artefatos
Test
Unitários
Integração
Deploy
+ testes de
aceitação
Como funciona?

SCM
Build
commit
commit
Compila
Otimiza
Gera artefatos
Test
Unitários
Integração
Deploy
+ testes de
aceitação
feedback
Como funciona?

➔ Commits diários;
➔ Sem multíplas branchs - commits direto no “trunk”;
➔ Build automatizado;
➔ Todo commit gera um novo build;
➔ Ambiente de testes deve ser similar ao de produção;
➔ Deploy automatizado (sem exigir intervenção manual);
Estratégias Utilizadas

➔ Testa continuamente o projeto;
➔ Garante que a aplicação é compatível com o banco de dados;
➔ Mantém sempre a versão de testes atualizada;
➔ Os erros são identificados rapidamente;
➔ Testes automatizados == maior qualidade == menos tempo
necessário para colocar uma nova versão em produção;
➔ Auditoria de código é feita continuamente através do Sonar;
Quais os benefícios?

E quando o build quebra?

E quando o build quebra?
Consertar deve ser
prioridade!

E quando o build quebra?
Consertar deve ser
prioridade!

Feedback

Sonar

Selenium Grid

E na hora do deploy...

Bah! Esqueci de rodar os
scripts.

➔ Controle de versão para o banco de dados;
➔ Mudanças na base são executadas incrementalmente;
➔ Scripts ficam juntos com o código fonte da aplicação e são
executados automaticamente durante o deploy;

Automatize tarefas
entediantes e repetitivas!

Falando nisso...

Gerar versão em produção não precisa ser o
evento do mês!

Gerar versão em produção não precisa ser o
evento do mês
trimestre!

Gerar versão em produção não precisa ser o
evento do mês
trimestre
ano!

ENTREGA
CONTÍNUA

Conjunto de práticas e princípios
que visam criar, testar e liberar
software mais rapidamente em
produção.

Nosso código não tem valor
de negócio enquanto não for
entregue.

Qual o tempo necessário
para liberar em produção
uma mudança que afeta
uma linha de código?

Manual de deploy da

BLUE-GREEN
DEPLOYMENT

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
Apenas um nodo (ou
conjunto) fica ativo por vez.

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
Em caso de erro na versão
atual, é possível fazer rollback
instantâneamente

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
Em caso de erro na versão
atual, é possível fazer rollback
instantâneamente

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
Os dois servidores atuam
como Jenkins Slaves

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
v. 1.2
A versão é sempre atualizada
no nodo “desabilitado”
Build pelo
Jenkins
upload

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
v. 1.2
VERSÃO 1.2
upload
Build pelo
Jenkins
A versão é sempre atualizada
no nodo “desabilitado”

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
v. 1.2
VERSÃO 1.2
Quando o deploy acaba...
Build pelo
Jenkins

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
VERSÃO 1.0
BANCO
v. 1.2
VERSÃO 1.2
… o tráfego é redirecionado
para o nodo que acabou de
ser atualizado.

LOAD BALANCER
+ MEMCACHED
VERSÃO 1.1
BANCO
VERSÃO 1.2
E o processo se repete.

Quais os benefícios?
➔ Alguns testes podem ser feitos diretamente em produção;
➔ Rollback é imediato em caso de problema;
➔ É possível atualizar a versão durante o dia, mantendo 100% de
uptime;
➔ Load balance por request distribui a carga muito melhor do que por
afinidade de sessão;

Ainda sobre entrega contínua...
➔ Não se trata apenas de uma ferramenta ou conjunto de
ferramentas
➔ O desafio é a quebra de barreira entre desenvolvedores, área de
testes, infraestrutura...

MONITORAMENTO
CONTÍNUO