Nesta apresentação que fiz no TDC 2011 em São Paulo, e no evento É Dia de Java em São Carlos. Nesta apresentação, veremos do que se trata Continuous Delivery (Entregas Continuas), suas praticas e principais desafios implementar com sucesso este conceito, que visa preencher o gap existente entre times de desenvolvimento e infraestrutura. E tambem veremos do movimento DevOps, e seu papel para implementar de maneira efetiva Implantacao Continua.

1. Con$nuous
Delivery
Wagner
Roberto
dos
Santos
(Twi3er:
@wrsantos)
Agile
Coache
/
Enterprise
Architect

2. Hello!
Agile
experience
with
Investment
Banks
and
Retail
Banks
Off-­‐shore
development
Teams
up
to
60
people
Architecture,
IS
Management,
ExperMse,
and
methodology
(Agile)
Supported
Agile
adopMon
in
main
Banks
in
France:
Credit
Agricole,
LCL,
Société
Générale,
BNP
Parisbas/ForMs

3. Apresentação
§ Arquiteto
de
SoXware
/
Agile
Coach
/
SoXware
CraXsman
§ Consultor
senior
da
OCTO
Technology
(h3p://www.octo.com/br)
§ Instrutor
da
Globalcode
da
formação
Academia
Agile
e
Arquiteto
§ Editor
do
Portal
InfoQ
Brasil
(h3p://infoq.com/br).
§ ParMcipação
nos
projetos
de
tradução
e
teste
do
NetBeans.
§ Palestrante
de
eventos
como
Just
Java,
Sun
Tech
Days,
Campus
Party.
§ Premiações
em
compeMções
de
tecnologia
.
§ Autor
de
vários
arMgos
para
as
revistas
Mundo
Java
e
Java
Magazine
§ CerMficações:
SCJA,
SCJP,
SCSNI,
SCJWSD,
SCBCD,
SCEA,
CSM
e
ACP.
§ Mantém
o
blog
h3p://neeeijao.blogspot.com
§ Twi3er:
@wrsantos

4. Agenda
Desafios em um processo de Desenvolvimento
SCM
Criando uma Software Factory
Deployment Pipeline
Infra-estrutura Agile
© OCTO 2011 4

5. Desafio:
Qualidade
§ Erros
em
IT
tem
um
forte
impacto
nas
operações
«
Customers’
accounts
of
BNP
Paribas
have
been
debited
or
credited
by
error
»
(February
2009)
«
A
bug
on
French
telecom
operator
»
(February
2010)
«
Big
IT
bug
at
the
SNCF
today
(French
Railroad
company)
»
(May
2010)
§ Medir
a
Qualidade
§ Ter
métricas
de
qualidade
disponíveis
© OCTO 2011 5

6. Desafio:
produMvidade
e
integração
§ Produtividade
§ Focar
em
aMvidades
que
realmente
adicionam
valor
§ Reduzir
tarefas
manuais
e
recorrentes
§ Dificuldades de Integração
§ Eliminar
as
aMvidades
de
merge
e
integração
§ Minimizar
os
riscos
e
esforços
necessários
para
instalar
a
aplicação
em
ambiente
de
produção
© OCTO 2011 6

7. Agile
101
Arquitetura & Design
Testes & Codificação Integração Operações
Demonstração & QA TI
Cliente It1 .. It2 .. It3 .. ItN
Iterações O Último KM
7
© Université du Système d’Information

8. ConMnuous
Delivery
§ Princípios
§ Criar um processo confiável, repetitível para entrega do Software
§ Automatizar tudo que é possível
§ Manter tudo no Sistema de Controle de Versão
§ Se causa dor, faça isto mais frequentemente, and traga a dor para perto
§ Construa com qualidade inserida
§ Todos são responsáveis pelo processo de Delivery
§ Melhoria Contínua
© OCTO 2011 8

9. Agenda
Desafios em um processo de Desenvolvimento
SCM
Criando uma Software Factory
Deployment Pipeline
Infra-estrutura Agile
© OCTO 2011 9

10. Value
Stream
Mapping
PLANEJAMENTO
e DESIGN CONSTRUÇÃO HOMOLOGAÇÃO DEPLOYMENT SUSTENTAÇÃO
• Identificar as • Recuperar o • Criar uma tag • Criar uma tag • Arrumar os bugs
aplicações e còdigo para o para a nova para a nova críticos e
módulos desenvolvimento versão para teste versão pronta urgentes no
necessårios para • Desenvolver, • Criar um novo para deploy. branch de
o projeto check-out, branch a partir • Criar um branch a manutenção
• Definir qual merge, testar e desta tag para partir desta tag • Efetuar o merge
versão das commit correções para manutenção destas correções
funcionalidades o • Arrumar os bugs e e tratamento de nos branches de
projeto ser efetuar as bug test
desenvolvido alterações no desenvolvimento
• Define qual branch
versao das • Efetuar o merge
aplicações e das correções
módulos que o com o trunk de
desenvolvedores desenvolvimento
irao utilizar para evitar
regressões
© OCTO 2011 10

11. SCM
§ Problemas
de
Merge?
11
© Université du Système d’Information

12. Conceitos
§ Trunk
§ ÚlMma
versão
do
desenvolvimento
§ O
Mme
de
desenvolvimento
faz
commits
diários
no
trunk.
§ É
a
baseline
para
o
Mme
de
desenvolvimento
§ Para
toda
correção
no
branch
deve
ser
feito
o
merge
no
trunk.
§ Branch
§ Branch
de
Homologação
• Fazer
as
correções
de
bug
e
modificações
de
um
aplicaMvo
que
está
em
fase
de
teste
/
homologação
§ Branch
de
Release
• Para
cada
release
novo
do
aplicaMvo,
é
criado
um
Branch
de
Release.
§ Tags
§ São
uMlizadas
para
idenMficar
pontos
significantes
de
alteração
na
linha
do
tempo,
incluindo
releases
e
finalizações
de
bugs
© OCTO 2011 12

13. Estrutura
de
SCV
§ Projeto Simples
§ Exemplo
de
um
projeto
simples.
© OCTO 2011 13

14. Estrutura
de
SCV
§ Múltiplos Projetos
§ Exemplo
de
um
ambiente
com
múlMplos
projetos.
© OCTO 2011 14

15. Recomendação
de
Uso
de
Tags
e
Branches
§ Release Branches
§ Cada
release
do
projeto
em
um
branch
separado.
§ Releases (Tags)
§ O
Release
Branch
pode
conter
um
(e
possivelmente
mais)
releases,
para
os
pontos
nas
quais
o
projeto
é
lançado,
podemos
uMlizar
as
tags
de
release
para
idenMficar
estes
pontos.
§ Bug Fixes
§ Bugs
descobertos
na
Release
são
tratadas
na
Release
Branch.
Em
casos
onde
o
bug
é
arrumado
em
um
commit,
o
número
da
revisão
do
Subversion
já
é
suficiente.
§ Tags
pode
ser
criadas
para
marcar
o
início
e
fim
do
acerto
no
bug.
§ Development Experiments
§ Quando
o
Mme
for
pesquisar
uma
tecnologia
nova,
ou
fazer
uma
mudança
muito
significaMva
na
aplicação,
que
pode
comprometer
o
design
da
aplicação..
© OCTO 2011 15

16. Recomendação
de
Uso
de
Tags
e
Branches
Nome
Es$lo
Exemplos
Test
Release
TEST-­‐versao
TEST-­‐1.1
Test
branch
TB-­‐versao
TB-­‐1.1
Releases
RELEASE-­‐rel
RELEASE-­‐1.0
RELEASE-­‐1.0.1a
Release
branch
RB-­‐rel
RB-­‐1.0
Development
Experiments
TRY-­‐descrição
TRY-­‐MR-­‐nhibernate
Legenda
rel: Número da Release
versao: Número da Versão
© OCTO 2011 16

17. Estrutura
Interna
de
um
AplicaMvo
§ Todo projeto deve seguir um padrão de estrutura de diretórios na
criação de um Projeto
§ Para a pasta raiz dos projetos (trunk/), é sugerido criar os seguintes
arquivos:
§ README
• Deve
servir
para
ajudar
novos
arquitetos,
ou
qualquer
outra
pessoa
interessada
em
conhecer
o
básico
sobre
o
projeto.
• Escrever
um
parágrafo
descrevendo
o
projeto,
os
problemas
que
ele
visa
resolver,
a
tecnologia
uMlizada,
entre
outras
informações
perMnentes
ao
projeto.
§ BUILDING
• Descreve
as
tarefas
necessárias
para
fazer
o
build
do
código.
§ GLOSSARY
• Colocar
os
termos,
jargões
específicos
do
projeto.
Para
facilitar
a
vida
dos
desenvolvedores,
quando
em
algum
momento
se
depararem
com
um
termo
muito
específico.
© OCTO 2011 17

18. Estrutura
Interna
de
um
AplicaMvo
§ Para a pasta raiz dos projetos (trunk/), é sugerido criar os seguintes
diretórios:
§ bin/
(vendor/Assembly)
• Se
o
projeto
uMliza
bibliotecas
de
terceiros
ou
outros
artefatos
que
é
preciso
para
o
bom
funcionamento
do
sistema,
este
é
a
pasta
é
o
lugar.
§ doc/
• Documentos,
manuais
e
emails
referentes
ao
projeto.
§ db/
• Se
o
projeto
uMliza
Banco
de
Dados,
armazenar
todos
os
artefatos
relacionados
ao
schema
aqui.
Exemplo
scripts,
procedures,
tabelas,
etc...
§ src/
• Nesta
pasta,
fica
a
estrutura
do
projeto
(código
fonte,
testes,
etc..)
§ uMl/
(or
tools/)
• Armazenar
aqui
todos
os
uMlitários,
ferramentas
e
scripts
do
projeto.
§ publish/
• Executáveis
e
binários
do
sistema,
pacotes
para
deploy
do
projeto
© OCTO 2011 18

19. Agenda
Desafios em um processo de desenvolvimento
SCM
Criando uma Fábrica de Construção
Deployment Pipeline
Infra-estrutura Agile
© OCTO 2011 19

20. Visão
Geral
Integração
Contínua
Fábrica de Teste
Construção Automáticos
Métricas de
Qualidade
© OCTO 2011 20

21. Integração Contínua
« Uma abordagem que visa a integração do código em tempo
real, ao invés de a cada 2 ou 3 semanas »
© OCTO 2011 21

22. Uma
Fábrica
de
Construção
dinâmica
Desenvolvedores compilam
em testam seu código
Desenvolvedor codifica na estação de trabalho Desenvolvedores
em seu IDE em sua submetem o código
estação de trabalho alterado para o repositório
A fábrica de construção
Desenvolvedor faz retorna todo o código
check out do código do repositório
A fábrica de construção compila,
testa e analisa o código
A Fábrica de construção empacota e
e cria os aplicativos, entregáveis e
documentos e os armazena para referência
© OCTO 2011 22

23. Fábrica
de
Construção:
as
Ferramentas
Retrieve
dependences
Source
Build
Compile
code
Con$nuous
Local
repository
Repository
of
integra$on
Execute
tests
binaries
Build
server
Verify
code
quality
No$fica$ons
Package
Deploy
Test
plaCorm
Document
Build
Documenta$on
&
metrics
23
© OCTO 2011 23

24. Não
é
somente
uma
questão
de
ferramentas
© OCTO 2011 24

25. Crie
uma
cultura
de
«
BUILD
»
§ Crie
rituais
para
a
Fábrica
de
Construção
§ «
Quem
quebrar
o
build,
paga
uma
rodada
de
cerveja
J
»
§ Todos
os
membros
da
equipe
são
responsáveis
pelo
Build
§ «
O
build
quebrou…minha
prioridade
top
é
acertá-­‐lo
»
§ Alinhar
o
Mme
quanto
a
qualidade
do
código
© OCTO 2011 25

26. O
Código
compila,
mas
ele
funciona?
© OCTO 2011 26

27. Test
Driven
Development
Write a
test that
fails
Code
and
Readapt
make
the code
test
pass
© OCTO 2011 27

28. Testes
Unitários
AutomaMzados
Testes unitários: ciclo do TDD se repete até o fim
do desenvolvimento de uma funcionalidade
Write
a test
that
Write fails
Make
acceptance
acceptance
tests in Code
Readapt
and tests pass
error code
make
test
pass
Um novo ciclo se repete para cada funcionalidade nova
© OCTO 2011 28

29. Resumindo:
Faça
antes
em
seu
projeto
!
Fazer
integração,
controle
de
qualidade
e
testes
na
final
do
projeto,
nos
dá
pouco
tempo
para
corrigir
problemas
inesperados
Con$nuous
integra$on
permite
:
§ Reduzir
aMvidades
intermináveis
de
integração
§ Integrar
o
código
fonte
muito
antes
do
deployment
§ Planejar
e
testar
o
processo
de
deployment
§ Ter
acesso
a
um
aplicaMvo
demo
funcionando
antes
da
fase
de
homologação
© OCTO 2011 29

30. Ambiente
de
CI
Source code
+ tests Automated Bug and Task Documentation
tests Management Repository
Developer
Quality
Source code Continuous
assurance
repository integration
control
Source code
+ tests
Developer
Artifact Automated
Dependences repository acceptance A new version
tests for homologation
© OCTO 2011 30

31. Métricas
e
reporMng
© OCTO 2011 31

32. Uma
Fábrica
de
Construção
Adaptada
§ Atualmente
existem
cada
vez
mais
sinergia
e
suporte
a
novas
tecnologias
entre
ferramentas
de
build
e
reporMng
Ruby,
Flex,
JavaScript,
PLSQL
...
…
e
até
iPhone,
iPad,
Android,
etc
§ Feramentas
Especializadas
em
ConMnuous
integraMon
§ Team
FoundaMon
Server,
Hudson,
TeamCity,
Bamboo,
CruiseControl,
Pulse,
…
§ Uma
abordagem
diferente
de
acordo
com
o
contexto
§ Metodologia
de
Projeto
§ Tecnologias
UMlizadas
§ Organização
(ex
:
SoXware
Houses)
§ ConMnuous
integraMon
é
muito
importante!
© OCTO 2011 32

33. Fique
operacional
no
primeiro
dia
§ Instalação
NNF
/
domine
a
instalação
§ Instalação
via
Script
§ Arvore
de
diretórios
e
configuração
deve
ser
o
mesmo
em
todas
as
estações
de
desenvolvimento
do
Mme
§ SoluMons
to
package
IDE
1. Escolha
uma
distruição
Eclipse
• SpringIDE
from
SpringSource
• Maven
studio
for
Eclipse
chez
Sonatype
• …
2. Plug-­‐ins
para
Eclipse
with
Nexus
© OCTO 2011 33

34. Minimizar
a
instabilidade
do
«
Build
»
§ Manter
o
repositório
de
código
«
clean
»
§ Prevenir
que
desenvolvedores
bloqueiem
uns
aos
outros
§ Favorer
o
uso
diário
do
repositório
de
fontes
para
outros
artefatos
que
não
sejam
somente
código
fonte
Repositório
de
código
fonte
© OCTO 2011 34

35. Uma
primeira
solução:
Unbreakable
build
Retrieve
dependences
Protected
Compile
source
code
Con$nuous
repository
Integra$on
Server
Execute
tests
Build
Developers
© OCTO 2011 35

36. Evolução
Incremental
dos
Schemas
do
banco
de
dados
§ Principios
§ Toda
evolução
nos
schemas
do
banco
são
versionados
no
repositório
de
fontes
§ AutomaMzar
da
criação
até
update
do
schema
do
banco
§ Altere
os
schemas
de
maneira
incremental
§ Ferramentas
§ Team
system
Database
© OCTO 2011 36

37. Profiled
build
10 min
Build
rapide
:
tests
unitaires
night
Build
documenta$on
4h
Source
code
Build
integra$on
tests
repository
Con$nuous
Local
Build
integra$on
night
server
Build
quality
metrics
On
request
Full
On
request
... Package
...
© OCTO 2011 37

38. Distributed
build
ƒ
Build
documenta$on
240
Agent
Build
integra$on
tests
10
Source
code
Build
rapide
:
tests
unitaires
repository
Con$nuous
Local
integra$on
ƒ
build
(master)
Build
quality
metrics
N
Complete
build
N
Agent
Package
© OCTO 2011 38

39. Na
Cloud
§ Tome
vantagem
de
uma
solução
de
cloud
flexível
§ Procure
por
soluções
completas
§ Externalize
somente
o
build
§ Virtual
machine
pronta
para
uso
§ Plugin
Hudson
em
EC2
© OCTO 2011 39

40. Big
visible
chart
&
Extreme
feeback
device
«
Alinhe
o
Tme
com
ferramentas
visuais
comparTlhadas
»
§ Radiadores
(Sonar,
Hudson,
…)
§ AmbientOrb
§ Nabastaz

41. Agenda
Desafios em um processo de Desenvolvimento
SCM
Criando uma Software Factory
Deployment Pipeline
Infra-Estrutura Agile
© OCTO 2011 41

42. Deployment
Pipeline
Ambiente de Integração e Configuração Fase de Aceitação
• Ambiente de
Configuração
• Deploy dos binários
• Teste de Fumaça
• Testes de Aceitação
Desenvolvedores analisam Testes de Aceite do Usuário
Métricas e Testes que falharam • Ambiente de Configuração
• Deploy dos binários
Métricas Testers • Teste de Fumaça
Falhas Solicitam execução
de testes sob demanda
Commit Testes de Performance
• Ambiente de Configuração
• Deploy dos binários
• Teste de Fumaça
Desenvolvedor • Execução de Testes de Performance
SVN
Fábrica de Construção
Fase de Commit Produção
• Compile • Ambiente de Configuração
• Commit do testes • Deploy dos binários
• Assemble • Teste de Fumaça
Operador Autoriza Deploy
• Análise do Código através de um clique
Binários
Repositório de Artefatos
• Relatórios
• Metadados
• Binários

43. Agenda
Desafios em um processo de Desenvolvimento
SCM
Criando uma Software Factory
Deployment Pipeline
Infra-Estrutura Agile
© OCTO 2011 43

44. Problemas
da
área
de
infra
44
© Université du Système d’Information

45. DevOps
45
© Université du Système d’Information

46. DevOps:
Problemas
de
Infra
§ Aplicações
Legadas,
plataformas
heterôgeneas
§ Perder
maior
parte
do
tempo,
apagando
incêndios
§ Processo
pesado,
conservador
§ Geralmente,
o
custo
com
operações
chega
a
80%
do
budget
de
TI.
46
© Université du Système d’Information

47. Disaster
Recovery
47
© Université du Système d’Information

48. Aplicação disponível todo o tempo
§ Continuous deployment
§ Expanda o escopo da integração contínua
§ Adapte seu « Definition Of Done »
§ Inclua os requisitos de operação no inicio do projeto
§ Industrialize os deployments
§ Trabalhe com os times de operação
§ Grandes players daweb (Amazon) vão até o deployment
contínuo da aplicação em ambientes de produção
© OCTO 2011 48

49. Referências
49
© Université du Système d’Information

50. Perguntas?
Obrigado
Wagner Roberto dos Santos
Twitter: @wrsantos
Email: wrsconsulting@gmail.com