ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122

5,810 views

Published on

Slides do Minicurso ministrado pela ToolsCloud na Globalcode. Para se inscrever nas proximas turmas, acesse:

http://www.globalcode.com.br/gratuitos/minicursos/minicurso-introducao-a-alm-open-source

Para experimentar as ferramentas apresentadas no minicurso, você pode utilizar o ambiente de demonstração da ToolsCloud:

https://demo.toolscloud.net
User: toolscloud
Password: toolscloud

ToolsCloud -- As ferramentas que os desenvolvedores adoram, na nuvem!
Solução complete de ALM, open source e sem stress. Começe a usar no seu projeto hoje!
http://www.toolscloud.com

Published in: Technology
4 Comments
17 Likes
Statistics
Notes
  • @brjavaman Obrigada Bruno. Se quiser informações sobre os produtos não hesite em nos contactar. Falando de Gerência de Mudanças, Gerência de Configuração, Gerência de Build e Planejamento de Equipe você pode citar o Rational Team Concert.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @patriciamantovani714 @FabiolaLopesCunhaGar
    Obrigado! Na verdade, essa apresentacao eh focada em solucoes open source, e o slide 19 acabou 'sobrando' da versao anterior dessa apresentacao. Mas, seu comentario eh importante: durante o curso eh importante citar outros fornecedores. Na proxima versao do curso (que vai acontecer dia 24/10), subo uma outra versao com isso mais acertado: vou remover o slide 19, e colocar um slide citando outros stacks ALM, incluindo o IBM Rational Jazz. Obrigado!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Concordo, uma vez que foi listado não só open source
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Oi Bruno, excelente apresentação! Se me permite, gostaria de sugerir que você inclua o RTC - Rational Team Concert no slide 19, uma vez que você está listando aí os mais relevantes do mercado.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
5,810
On SlideShare
0
From Embeds
0
Number of Embeds
2,044
Actions
Shares
0
Downloads
122
Comments
4
Likes
17
Embeds 0
No embeds

No notes for slide
  • abrir falando: eu estou mais motivado que o normal hoje em dia, pois o progresso da tecnologia tem trazido muitas facilidades para desenvolver softwares e eventualmente criar um business ao redor dele.
  • abrir falando: eu estou mais motivado que o normal hoje em dia, pois o progresso da tecnologia tem trazido muitas facilidades para desenvolver softwares e eventualmente criar um business ao redor dele.
  • abrir falando: eu estou mais motivado que o normal hoje em dia, pois o progresso da tecnologia tem trazido muitas facilidades para desenvolver softwares e eventualmente criar um business ao redor dele.
  • ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122

    1. 1. Application Lifecycle Management com ferramentas Open Source Minicurso MC-122 Globalcode Bruno Souza Evangelista Java e Open Source ToolsCloud @brjavaman
    2. 2. Palestrantes Bruno Souza bruno@javaman.com.br @brjavaman - http://java.mn Programador, Fundador da ToolsCloud http://www.toolscloud.com Material e Slides Vinicius Senger Kleber Xavier vinicius@globalcode.com.br @vsenger Programador, Fundador Globalcode kleber@globalcode.com.br Instrutor e Arquiteto de Software Globalcode
    3. 3. Lembretes! Curso AA1 online: ALM a fundo! http://www.globalcode.com.br/treinamentos/modulos/alm-testes Quer experimentar as ferramentas da ToolsCloud? Quer fazer parte da lista de discussoes sobre OpenALM? • http://jav.mn/tcgratis
    4. 4. ALM – O que é? Application Lifecycle Management: gerenciamento contínuo do software; Casamento da gestão de negócio com engenharia de software; Requer ferramentas integradas para gerenciar: Requisitos; Repositório de código; Construção; Arquitetura e codificação; Testes e qualidade Versões e componentes
    5. 5. ALM – Por que? Vantagens na adoção; Rastreabilidade e dados post-hoc; Gerenciamento integrado; Simplificação nos processos; Agilidade na construção do software; Aumento da reusabilidade; Diminuição dos riscos;
    6. 6. ALM • Independente de metodologia, arquitetura e tecnologia toda empresa se beneficia muito com ALM • Rastreabilidade, transparência, comunicação • ALM = é como álbum de fotografia do seu software, com retratos tirados automaticamente a cada mudança, falha, novo requisito, novo release, etc. • Todo mundo sai ganhando: bom para o developer, gerente, arquiteto, Scrum Master, P.O., V.P., CIO, CTO, Asponi, etc.
    7. 7. Ferramentas • Existem várias soluções de ALM no mercado: • Microsoft - Team Foundation Server • IBM - Rational Team Concert • Atlassian - Jira • Rally Software • Collabnet - TeamForge • HP - Quality Center • VersionOne
    8. 8. Open Source Liberdade de escolha de fornecedores Uso livre: excelente para pequenos e médios times Possibilidade de suporte local As ferramentas mais utilizadas pelos desenvolvedores Comunidade de plugins e ferramentas Disponível para parceiros e empresas contratadas
    9. 9. Repositórios de Código Fonte: ZeroTurnaround Developer Productivity Report 2013
    10. 10. Integração Contínua Fonte: ZeroTurnaround Developer Productivity Report 2013
    11. 11. Issue Trackers Fonte: ZeroTurnaround Developer Productivity Report 2013
    12. 12. Efeito na Previsibilidade dos Projetos Fonte: ZeroTurnaround Developer Productivity Report 2013 (apenas algumas ferramentas foram comparadas)
    13. 13. O que os “Rock Stars” usam? Fonte: ZeroTurnaround Developer Productivity Report 2013 (apenas algumas ferramentas foram comparadas)
    14. 14. ALM – ferramentas Pilha ALM open-source que usamos:
    15. 15. ● Pilha ALM Open Source na nuvem ● Ambiente montado em minutos ● Softwares atualizados e suporte ● Não precisa de novos servidores na sua empresa! ● ● Redmine, SVN, GIT, Hudson, Nexus integrados com LDAP: importante diferencial Experimente online as ferramentas desse mini-curso: ● https://demo.toolscloud.net ● user: toolscloud senha: toolscloud
    16. 16. ALM 1Novo projeto 2 Redmine 2 Git 2 Jenkins 3 Requisitos 4 Codificação 5 Build & Testes 10 Bugs e Melhorias 9Produção 6 Release 7 Nexus 8 Homologação Deployment Contínuo
    17. 17. ALM – 1a Semana 1. Gestão de componentes 3os com Nexus 2. Testes 3. Integração contínua
    18. 18. ALM – 1o Mês 1. Testes regressivos 2. Deployment contínuo básico 3. Gestão dos seus próprios componentes com Nexus
    19. 19. Depois 1. Testes avançados 2. Deployment contínuo avançado 3. Code review contínuo
    20. 20. O planejamento inicial Problema: Organizar os requisitos em entregas Atribuir os requisitos para seus desenvolvedores Acompanhar a evolução do desenvolvimento Solução: Utilizar um gerenciador de issues, como o Redmine
    21. 21. Processo – passo 1 requisitos e releases stakeholder
    22. 22. Redmine • Gerenciamento de Requisitos com: • Gestão de pendências; • Gerenciamento de horas gastas / time tracking; • Integração com SCM; • Conceito de projetos e sub-projetos; • Fórum, wiki, arquivos, news, calendário, gantt chart e sistema de segurança; • Software open-source construído em Ruby on Rails; • Centenas de plug-ins e módulos adicionais; • Muitas possibilidades de customização;
    23. 23. Redmine • Após login, temos dois principais itens: Projects, para entrar em um projeto e Administration para config. geral: Home
    24. 24. A organização do código fonte Problema: Compartilhar o código fonte entre os desenvolvedores do projeto Manter o histórico de alterações Solução: Utilizar um repositório de código fonte como o Git
    25. 25. Processo – passo 2 requisitos e releases stakeholder desenvolvedor código fonte visualização do histórico
    26. 26. Versionamento • No mundo open-source os destaques são: • CVS: sistema mais antigo e precário, porém, ainda muito utilizado. Trabalha com protocolo proprietário; • Subversion: evolução do CVS com disponibilização via HTTP (além de protocolo proprietário) e alta performance para versionamento; • GIT: mais moderno ainda, por se tratar de um repositório distribuído. Tem muitas vantagens, mas demanda mais conhecimento do usuário;
    27. 27. Versionamento • “Qualidade” dos commits • Cuidar bem das mensagens • Independente de decisão, escolha entre SVN e GIT! • GIT File System? • Hooks & ALM
    28. 28. Introdução ao Subversion • Subversion é um repositório client / server, não distribuído; • É mantido pelo grupo Apache: • subversion.apache.org • Instalação e administração simples; • Não requer conhecimentos avançados do usuário; • Excelente performance para gerar versões / cópias; • Pode disponibilizar dados por protocolo proprietário ou por HTTP / HTTPS;
    29. 29. Estrutura de trabalho • Convencionalmente trabalhamos com: • trunk (tronco): uma pasta que contém os arquivos de desenvolvimento do projeto. • branch (galho): são linhas concorrentes de desenvolvimento do projeto independentes; • tag (etiqueta): são versões releases efetivos de um projeto. 1Trunk 3Tag 2Branch
    30. 30. GIT • Distribuído: no lugar de checkout você clona o repositório • Seus commits são locais, portanto você pode trabalhar offline • Verbos: add commit log diff status branch merge push • Entre offline e online vários commits! • GIT ou Subversion?
    31. 31. Integração com Redmine • Navegar nos arquivos do SVN via Web clicando no item Repository:
    32. 32. Integração com Redmine • E o recurso mais útil é a possibilidade de você referenciar as Issues nas mensagens de commit; cd /home/almadmin/projetos-svn/projeto1/trunk touch novo-arquivo.txt svn commit –m “Correçao de problema de encoding da IssueID #2”
    33. 33. Gerenciamento das dependências Problema: Padronizar as bibliotecas de terceiros utilizadas pelo projeto Disponibilizar as bibliotecas utilizadas para a equipe de desenvolvimento Solução: Utilizar uma ferramenta de build com suporte a gerenciamento de dependências como o Maven Utilizar um gerenciador de repositórios como o Nexus
    34. 34. Processo – passo 3 requisitos e releases visualização do histórico stakeholder build dependências desenvolvedor código fonte
    35. 35. Introdução Nexus • O Maven pode baixar automaticamente bibliotecas da Internet (se open-source); • Isso é excelente para o desenvolvimento de pequenos times, agora se tivermos um time de 100 desenvolvedores criando projetos Maven que fazem downloads da Internet? • Fatalmente teremos um problema de rede até que todos os Mavens terminem seus downloads!
    36. 36. Introdução Nexus • Para ajudar a solucionar este tipo de problema contamos com Gerenciadores de Repositórios, que desempenham um papel de proxy para os demais: Developer Hudson Build com Maven jar: log4j, hibernate, spring etc. Nexus Internet
    37. 37. Introdução ao Nexus • O Nexus faz o download centralizado dos componentes fazendo um cache que ele utilizará para servir aos demais desenvolvedores; • Além do papel de cache, o Nexus também pode catalogar o componentes e artefatos da sua empresa, do seu negócio; • Isso facilita bastante o reuso entre equipes; • Maven + Nexus + Hudson: parceria perfeita!
    38. 38. Integração entre módulos Problema: Garantir que alterações em um dos módulos não quebrem o funcionamento de outros módulos Notificar os responsáveis em caso de quebra, o mais rapidamente possível Solução: Utilizar uma ferramenta de integração contínua como o Jenkins
    39. 39. Processo – parte 4 requisitos e releases stakeholder build visualização do histórico integração contínua dependências desenvolvedor código fonte
    40. 40. Integração Continua • Apresentamos o Redmine com SCM integrado. • Desta forma podemos ter um time de desenvolvimento compartilhando o mesmo servidor SCM para desenvolver as Issues do projeto; • Será que isso é o suficiente para nossa necessidade? • NÃO! Imagine que vários desenvolvedores podem fazer commit de código no fim do dia resultando em um código não-compilável;
    41. 41. Introdução ao Hudson / Jenkins ● ● Hudson/Jenkins são servidores open-source de integração continua Um “Continous integration server / CI server” pode desempenhar várias tarefas como: ● ● Build e teste; ● Publicação de resultados; ● ● Checkout de código-fonte; Comunicação com membros do time; Na prática: um agendador de tarefas de construção de softwares altamente customizável;
    42. 42. Introdução ao Hudson / Jenkins • Fácil instalação e configuração; • Interface é web based; • Pode fazer builds distribuídos; • Relatório de teste unitário; • Notificação do estado dos builds; • Notificação em caso de quebra;
    43. 43. Introdução ao Hudson / Jenkins • Arquitetura extensível baseada em plugins com mais de 150 de plugins disponíveis; • Por padrão vem com 4 plugins instalados: • CVS • SVN • Maven • SSH
    44. 44. Criando Jobs • Basicamente o Hudson pode trabalhar com projetos livres ou Maven; • Maior parte dos casos utilizamos Maven ou Ant; • Maven é o mais simples de se usar!
    45. 45. Criando Jobs •Em seguida configuramos o job indicando principalmente o repositório para checkout do projeto!
    46. 46. Criando Jobs Podemos clicar em Build Now e Hudson vai iniciar o checkout do código e depois vai disparar o build Maven!
    47. 47. Dashboard • O dashboard traz as informações sobre os diversos jobs / projetos configurados; • Este ícone indica a estabilidade dos builds:
    48. 48. Reutilização de módulos Problema: Disponibilizar os módulos desenvolvidos para reuso entre as equipes Solução: Utilizar uma ferramenta de gerenciamento de repositórios como o Nexus
    49. 49. Processo – parte 5 requisitos e releases stakeholder build visualização do histórico integração contínua dependências desenvolvedor código fonte publicação de artefatos
    50. 50. Configurando Maven • Devemos adicionar esta configuração em um arquivo settings.xml que ficará no diretório .m2 do usuário:
    51. 51. Configurando Maven • Para que o Maven possa fazer deployment de artefatos no Nexus:
    52. 52. Qualidade do código Problema: Garantir que as convenções e boas práticas estão sendo seguidas pelos desenvolvedores Visualizar as violações e a evolução da qualidade estrutural do código Solução: Utilizar uma ferramenta de análise estática do código como o Sonar
    53. 53. Processo – parte 6 requisitos e releases stakeholder build visualização do histórico integração contínua dependências desenvolvedor código fonte publicação de artefatos inspeção
    54. 54. Implantação em produção Problema: Implantar um módulo aprovado em produção Solução: Utilizar a ferramenta de integração contínua para fazer o deployment contínuo
    55. 55. Processo final requisitos e releases stakeholder build visualização do histórico integração contínua dependências desenvolvedor código fonte inspeção deploy publicação de artefatos servidor
    56. 56. Outras ferramentas Junit - Testes unitários Selenium - Testes de interface Web Jmeter - Testes de carga TestLink - Gerenciamento de casos de teste Vagrant – Automatização de servidor de desenvolvimento Chef – Automação de infraestrutura
    57. 57. Demonstração Experimente a demonstração por contra própria: https://demo.toolscloud.net User: toolscloud - Senha: toolscloud
    58. 58. Conclusões ● ● ● As ferramentas Maven, Nexus, Hudson/Jenkins, Redmine e Subversion formam uma poderosa solução de ALM; Todas as ferramentas são open-source; Este ambiente é agnóstico de linguagens, e funciona para projetos Delphi, C, C++, Ruby, PHP e outros; ● Muitas possibilidades de customização; ● A ToolsCloud oferece este ambiente como serviço da nuvem
    59. 59. Lembretes! Curso AA1 online: ALM a fundo! http://www.globalcode.com.br/treinamentos/modulos/alm-testes Quer experimentar as ferramentas da ToolsCloud? Quer fazer parte da lista de discussoes sobre OpenALM? • http://jav.mn/tcgratis
    60. 60. Obrigado! ● Vinicius Senger vinicius@globalcode.com.br @vsenger www.globalcode.com.br ● Bruno Souza bruno@javaman.com.br @brjavaman www.toolscloud.com
    61. 61. Dúvidas ? vinicius@globalcode.com.br kleber@globalcode.com.br bruno@javaman.com.br
    62. 62. Slides Extras Veja nos slides a seguir informações extras sobre como configurar algumas das ferramentas citadas nesse mini-curso.
    63. 63. Redmine • Download e Instalação • www.redmine.org • Precisa de Ruby 1.8, Rails 2.3.5, Rack 1.0.1, RubyGems 1.8, Rake, i18n, libmysql-ruby, libopenssl-ruby1.8;
    64. 64. SVN: Comandos básicos • Adicionar um arquivo ou diretório*: svn add <arquivo ou diretorio> • Remover arquivo ou diretório*: svn rm <arquivo ou diretorio> • Mover arquivo ou diretório*: svn mv <arquivo ou diretorio> • Listar conteúdo do repositório: svn ls <URL> • Reverter alterações locais: svn revert <arquivo> *Arquivos serão adicionados ou removidos no próximo commit
    65. 65. SVN / Git Integração com Redmine • O Redmine pode ser integrar com seu sistema de ; • Para isso, clique nos Settings do Projeto e, em seguida, escolha Repository:
    66. 66. SVN / Git Integração com Redmine • Ao vincular o projeto a um repositório você terá algumas integrações; • Últimas mudanças e commits no item Activities
    67. 67. SVN / Git Integração com Redmine • Você pode configurar as palavras que serão detectadas nas mensagens de commit em: Redmine –> Administration –> Settings -> Repositories Configuramos as palavras de referência aqui Fixing keywords podem mudar o status da Issue!
    68. 68. SVN / Git Integração com Redmine cd /home/almadmin/projetos-svn/projeto1/trunk touch novo-arquivo.txt svn commit –m “Correçao de problema closes #2”
    69. 69. Jenkins / Hudson: Instalação e inicialização • O Hudson pode funcionar de três formas: • Stand-alone: java –jar hudson.war • JNLP: https://hudson.dev.java.net/hudson.jnlp • JavaEE container: fazendo deploy do hudson.war Glassfish, Jboss, Tomcat, Jetty, Winstone, Websphere;
    70. 70. Jenkins / Hudson: Instalação e inicialização • Para acessar o Hudson abra um browser e digite a seguinte URL: http://localhost:8080/hudson-2.0.0 Configurações do Hudson Membros do Hudson e projetos Relacionamento entre projetos Views customizadas Executores de builds. O Hudson vem com 2 executores de builds por padrão.
    71. 71. Hudson / Jenkins: Configuração • Para fazer as configurações iniciais devemos clicar em Manage Hudson
    72. 72. Hudson / Jenkins: Configuração • Em seguida Configure System teremos acesso as principais configurações do Hudson: Representa o no. de executores de builds.
    73. 73. Hudson / Jenkins: Configuração • Após a instalação é importante configurar o local onde estão instalados JDK, Maven e Ant (se usar);
    74. 74. Hudson / Jenkins: Configuração • A outra configuração importante é uma conta de e-mail funcionando para o Hudson poder se comunicar com equipes:

    ×