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
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
1. Application Lifecycle Management
com ferramentas Open Source
Minicurso MC-122 Globalcode
Bruno Souza
Evangelista Java e Open Source
ToolsCloud
@brjavaman
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. 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. 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. 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. 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. 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. 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
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
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
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. Redmine
• Após login, temos dois principais itens: Projects, para
entrar em um projeto e Administration para config.
geral:
Home
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. Processo – passo 2
requisitos e releases
stakeholder
desenvolvedor
código fonte
visualização
do histórico
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. Versionamento
• “Qualidade” dos commits
• Cuidar bem das mensagens
• Independente de decisão, escolha entre SVN e GIT!
• GIT File System?
• Hooks & ALM
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. 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. 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?
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. 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. Processo – passo 3
requisitos e releases
visualização
do histórico
stakeholder
build
dependências
desenvolvedor
código fonte
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. 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. 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. 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. Processo – parte 4
requisitos e releases
stakeholder
build
visualização
do histórico
integração contínua
dependências
desenvolvedor
código fonte
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. 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. 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. 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. 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. Criando Jobs
•Em seguida configuramos o
job indicando principalmente
o repositório para checkout
do projeto!
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. Dashboard
• O dashboard traz as informações sobre os diversos
jobs / projetos configurados;
• Este ícone indica a estabilidade dos builds:
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. Configurando Maven
• Devemos adicionar esta configuração em um arquivo
settings.xml que ficará no diretório .m2 do usuário:
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. 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
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. 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
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. 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
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. 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. 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. 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. 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. 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. 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.
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. Hudson / Jenkins:
Configuração
• Após a instalação é importante configurar o local
onde estão instalados JDK, Maven e Ant (se usar);
74. Hudson / Jenkins:
Configuração
• A outra configuração importante é uma conta de e-mail
funcionando para o Hudson poder se comunicar com
equipes:
Editor's Notes
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.