O documento apresenta uma solução de Application Lifecycle Management (ALM) open source composta por ferramentas como Redmine, Subversion/Git, Maven, Nexus, Hudson/Jenkins. A pilha ALM descrita permite gerenciar todo o ciclo de vida de desenvolvimento de software de forma integrada e com baixo custo.
3. Mini Curso ALM Open Source Globalcode
● Esse material é baseado no mini-curso MC-122,
Introdução a ALM Open Source
● http://www.globalcode.com.br/gratuitos/minicursos/minicurso-introducao-a-alm-
open-source
● Esse é um minicurso gratuito de 3 horas, ministrado pela
Globalcode e pela ToolsCloud mensalmente
● A Globalcode também ministra um curso completo de ALM
Open Source online, o curso AA1 Online:
● http://www.globalcode.com.br/treinamentos/online/alm-testes
4. • 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 integrada;
Arquitetura e codificação;
Testes e qualidade;
Gerenciamento de versões e componentes;
A.L.M.
5. A.L.M.
• Independente de metodologia, arquitetura e tecnologia,
todos os times de desenvolvimento precisam de A.L.M.
• Não documentar o futuro (Agile / Scrum) é uma coisa,
poder rastrear o passado é outra;
• 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.
6. • Vantagens na adoção:
• Rastreabilidade e dados post-hoc;
• Cultura de planejamento de releases / backlog;
• Gerenciamento integrado;
• Simplificação nos processos;
• Agilidade na construção do software;
• Conseqüente aumento na cultura de testes;
• Aumento da reusabilidade;
A.L.M. - vantagens
7. • Expõe os ciclos de vida do software, facilitando e
motivando sua a gestão:
• Requisitos / Backlog / Atividade / User Story
• Documentação (wiki / files) e suporte (fórum)
• Versionamento, tags, brunches, ..
• Gestão de Componentes e repositórios
• Arquétipos Maven
• Construção
• Testes – Homologação - Produção
• Deployment
Gestão de Arquitetura
8. Pilha A.L.M. Open Source
Disciplina Software
Gerenciamento de Requisitos Redmine
Gestão de código / versionamento SVN e GIT
Construção e dependências Maven
Gerenciamento de arquétipos Maven
Integração Contínua Hudson / Jenkins
Repositório de componentes Nexus
Ferramenta para desenvolvimento ● Eclipse / NetBeans com
plugins
14. • 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;
Redmine
16. • Após login, temos dois principais itens: Projects, para
entrar em um projeto e Administration para config.
geral:
Redmine
Home
17. • Temos dezenas de opções de controladores de
versões de arquivos no mercado:
• Subversion / SVN
• CVS
• GIT
• Microsft Sourcesafe e TFS
• Borland Starteam
• Clearcase
Versionamento
18. • 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;
Versionamento
19. • “Qualidade” dos commits
• Cuidar bem das mensagens
• Independente de decisão, escolha entre SVN e GIT!
• GIT File System?
• Hooks & ALM
Versionamento
20. • 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;
Introdução ao Subversion
21. 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>
22. • Convencionalmente trabalhamos com:
• trunk (troco): 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.
Estrutura de trabalho
Trunk1
Branch2Tag3
23. • 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?
GIT
24. • O Redmine pode ser integrar com seu sistema de ;
• Para isso, clique nos Settings do Projeto e, em
seguida, escolha Repository:
Integração com Redmine
25. • Ao vincular o projeto a um repositório você terá algumas
integrações;
• Últimas mudanças e commits no item Activities
Integração com Redmine
26. • Navegar nos arquivos do SVN via Web clicando no
item Repository:
Integração com Redmine
27. • 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”
Integração com Redmine
28. • Você pode configurar as palavras que serão
detectadas nas mensagens de commit em:
Redmine –> Administration –> Settings ->
Repositories
Integração com Redmine
Configuramos as palavras de referência aqui
Fixing keywords podem mudar o status da Issue!
30. ●
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... Mesmo com essas ferramentas, é possível que
os desenvolvedores commitem código não-
compilável.
Integração Continua
31. ●
Hudson/Jenkins são servidores open-source de integração
continua
●
Um “Continous integration server / CI server” pode
desempenhar várias tarefas como:
●
Checkout de código-fonte;
●
Build e teste;
●
Publicação de resultados;
●
Comunicação com membros do time;
●
Na prática: um agendador de tarefas de construção de
softwares altamente customizável;
Introdução ao Hudson / Jenkins
32. • 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;
Introdução ao Hudson / Jenkins
33. • 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
Introdução ao Hudson / Jenkins
34. • 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;
Instalação e inicialização
35. • Para acessar o Hudson abra um browser e digite a
seguinte URL: http://localhost:8080/hudson-2.0.0
Instalação e inicialização
Executores de builds. O
Hudson vem com 2
executores de builds por
padrão.
Configurações do Hudson
Membros do Hudson e
projetos
Relacionamento entre
projetos
Views customizadas
36. • Para fazer as configurações iniciais devemos clicar em
Manage Hudson
Configuração
37. • Em seguida Configure System teremos acesso as
principais configurações do Hudson:
Configuração
Representa o no. de
executores de builds.
38. • Após a instalação é importante configurar o local
onde estão instalados JDK, Maven e Ant (se usar);
Configuração
39. • A outra configuração importante é uma conta de e-mail
funcionando para o Hudson poder se comunicar com
equipes:
Configuração
40. 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!
41. Criando Jobs
•Em seguida configuramos o
job indicando principalmente
o repositório para checkout
do projeto!
42. Criando Jobs
Podemos clicar em Build
Now e Hudson vai iniciar o
checkout do código e
depois vai disparar o build
Maven!
43. • O dashboard traz as informações sobre os diversos
jobs / projetos configurados;
• Este ícone indica a estabilidade dos builds:
Dashboard
44. • 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!
Introdução Nexus
45. • Para ajudar a solucionar este tipo de problema contamos
com Gerenciadores de Repositórios, que
desempenham um papel de proxy para os demais:
Introdução Nexus
Developer Hudson
Build com
Maven
jar: log4j, hibernate, spring etc.
Nexus
Internet
46. • 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!
Introdução ao Nexus
47. • Devemos adicionar esta configuração em um arquivo
settings.xml que ficará no diretório .m2 do usuário:
Configurando Maven
48. • Para que o Maven possa fazer deployment de
artefatos no Nexus:
Configurando Maven
49. Outras ferramentas
● Sonar – Análise de qualidade de software
● TestLink – Gerencia de Testes
● Vagrant – Automatização de servidor de desenvolvimento
● Chef – Automação de infraestrutura
50. ● 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
Conclusões
51. ● Pilha ALM como SaaS na nuvem
● Tudo isso que vimos, e mais:
● Ferramentas totalmente integradas
● Ambiente montado em minutos
● Não precisa de servidores na sua empresa!
● Softwares atualizados e suporte
● Experimente online as ferramentas desse mini-
curso:
● https://demo.toolscloud.com
● user: toolscloud senha: toolscloud