Your SlideShare is downloading. ×
0
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Continuous Delivery e DevOps
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Continuous Delivery e DevOps

3,327

Published on

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 …

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.

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,327
On Slideshare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
0
Comments
1
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 TICliente 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  Legendarel: Número da Releaseversao: 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 Makeacceptance 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 RepositoryDeveloper Quality Source code Continuous assurance repository integration control Source code + testsDeveloper 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çaDesenvolvedor •  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: @wrsantosEmail: wrsconsulting@gmail.com

×