SlideShare uma empresa Scribd logo
1 de 103
Baixar para ler offline
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR
DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO
ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE
ADRIANO TEIXEIRA DE SOUZA
APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A
RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO
DE SOFTWARE
MONOGRAFIA DE ESPECIALIZAÇÃO
MEDIANEIRA
2014
ADRIANO TEIXEIRA DE SOUZA
APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A
RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE
SOFTWARE
Monografia apresentada como requisito
parcial à obtenção do título de Especialista
na Pós Graduação em Engenharia de
Software, da Universidade Tecnológica
Federal do Paraná – UTFPR – Câmpus
Medianeira.
Orientador: Prof. MSc. Wesley Klewerton
Guez Assunção.
Co-Orientador: Prof. MSc. Cristiano Marcos
Lunkes
MEDIANEIRA
2014
Ministério da Educação
Universidade Tecnológica Federal do Paraná
Diretoria de Graduação e Educação Profissional
Especialização em Engenharia de Software
TERMO DE APROVAÇÃO
APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A
RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE
SOFTWARE
Por
Adriano Teixeira de Souza
Esta monografia foi apresentada às 10:10 h do dia 07 de Agosto de 2014 como
requisito parcial para a obtenção do título de Especialista no curso de Engenharia
de Software, da Universidade Tecnológica Federal do Paraná, Câmpus
Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos
professores abaixo assinados. Após deliberação, a Banca Examinadora
considerou o trabalho aprovado.
______________________________________
Prof. MSc. Wesley Klewerton Guez Assunção
UTFPR – Câmpus Toledo
(orientador)
____________________________________
Prof. Esp. Márcio Angelo Matté
UTFPR – Câmpus Medianeira
_________________________________________
Prof. Dr. Pedro Luiz de Paula Filho
UTFPR – Câmpus Medianeira
Dedico a todos que estiveram ao meu lado
nesta etapa de aprendizado.
AGRADECIMENTOS
Agradeço a Deus por estar concluindo mais este passo para a construção do
conhecimento e por ter me conduzido com segurança nas constantes viagens até a
cidade de Medianeira.
Agradeço a minha querida esposa Keila Couto dos Santos por estar sempre
junto a mim e pelo grande esforço também empenhado nesta caminhada.
Agradeço ao grande amigo e Mestre Wesley Klewerton Guez Assunção pela
orientação e apoio na elaboração deste material, bem como pelo tempo dispensado
para acompanhar de perto este trabalho.
Agradeço de forma muito singela ao ilustríssimo Mestre Cristiano Marcos
Lunkes, excelentíssima pessoa e de coração muito humilde, pela disposição em
acompanhar este trabalho e pelo esforço empenhado para estar na cidade de
Medianeira colaborando nesta jornada.
Agradeço ao Mestre Alan Gavioli por ter trabalhado pela oferta deste curso e
pelo grande zelo com o mesmo.
Agradeço a todos os professores que contribuíram para o aprendizado
durante o decorrer deste curso.
Agradeço aos colegas de turma pela prazerosa companhia e troca de
experiência nestes inúmeros sábados.
“A percepção do desconhecido é a mais fascinante das experiências. O homem que
não tem os olhos abertos para o misterioso passará pela vida sem ver nada”.
(ALBERT EINSTEIN)
RESUMO
SOUZA, Adriano Teixeira de. APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA
VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO
DE SOFTWARE. 2014. 103f. Monografia (Especialização em Engenharia de
Software). Universidade Tecnológica Federal do Paraná, Medianeira, 2014.
Este trabalho tem por objetivo apresentar as contribuições que as técnicas de
Integração Contínua podem agregar ao processo de gerenciamento de configuração
de software. As técnicas avaliadas neste trabalho visam dar subsídios para
rastreabilidade de relacionamentos entre requisitos, artefatos e produto final durante
o ciclo de vida de um software. Para isso, é apresentada a revisão de literatura sobre
temas relacionados, ferramentas que viabilizam a aplicação destas técnicas e
elaborado um protótipo para demonstração da aplicação das mesmas. E finalmente,
são analisadas as informações providas pelas ferramentas e elaborado uma matriz
de rastreabilidade de artefatos de software.
Palavras-chave: Gerenciamento de Configuração, Controle de Versões,
Manutenção, Gerenciamento de Projetos.
ABSTRACT
SOUZA, Adriano Teixeira de. APPLICATION OF CONTINUOUS INTEGRATION TO
ENABLE THE TRACEABILITY OF ARTIFACTS DURING SOFTWARE
MAINTENANCE. 2014. 103f. Monograph (Lato Sensu Postgraduate on Software
Engineering). Technological Federal University of Paraná, Medianeira-Brazil, 2014.
This work has a goal of presenting the contribution that the Continuous Integration
technics can aggregate on the software configuration management process. The
evaluated technics on this work aim give subsidies to relationship traceability
between requirements, artifacts and end product during the software lifecycle. For
this, is presented the literature revision about the related subjects, tools to make
possible the application of this technics and prototype development to show the
applying of them. Finally, are analyzed the information provided by the tools and
elaborated one matrix of traceability of software artifacts.
Keywords: Configuration Management, Version Control, Maintaining, Project
Management.
LISTA DE FIGURAS
Figura 1 - Sistema de controle de versões distribuído ..............................................28
Figura 2 - Intercomunicação entre serviços...............................................................32
Figura 3 - Diagrama de classes do sistema de pedidos de venda ............................34
Figura 4 - Diagrama de caso de uso do sistema de pedidos de venda.....................35
Figura 5 - Diagrama de classes do sistema de pedidos de venda ............................35
Figura 6 - Domínio Microsoft Active Directory ...........................................................37
Figura 7 - Variável de ambiente JAVA_HOME..........................................................38
Figura 8 - Variável de ambiente Path com JDK.........................................................39
Figura 9 - Instalação do Microsoft Information Services............................................44
Figura 10 - Configuração do application pool para o site padrão ..............................45
Figura 11 - Variável de ambiente Path......................................................................46
Figura 12 - Configuração da máquina virtual Java para o Gitblit...............................49
Figura 13 - Configuração de para autenticação do Redmine ....................................51
Figura 14 - Configuração de usuário para atividades de desenvolvimento ...............52
Figura 15 - Configuração de autenticação do Jenkins ..............................................53
Figura 16 - Configuração do método de autorização do Jenkins ..............................53
Figura 17 - Repositório para controle de versões dos protótipos ..............................60
Figura 18 - Novo repositório Git a ser clonado..........................................................60
Figura 19 - Opção Git Clone......................................................................................61
Figura 20 - Confirmação de clone para repositório Git..............................................61
Figura 21 - Abertura do projeto para o protótipo no Redmine ...................................62
Figura 22 - Parametrização de novo repositório de código fonte ..............................63
Figura 23 - Ativação da restauração de pacotes NuGet............................................67
Figura 24 - Link para visualização de lista de tarefas em formato Atom ...................68
Figura 25 - Opção de acessar as configurações do TortoiseGit................................68
Figura 26 - Configuração do plugin TurtleMine .........................................................69
Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit...................................70
Figura 28 - Lista de tarefas apresentadas pelo TurtleMine .......................................70
Figura 29 - Tarefa do Redmine associada ao commit no Git ....................................71
Figura 30 - Link do Gitblit para o Redmine................................................................72
Figura 31 - Palavras-chaves de referência................................................................73
Figura 32 - Revisões associadas a uma tarefa .........................................................73
Figura 33 - Parâmetros de acesso aos serviços do Redmine ...................................75
Figura 34 - Seleção de hook script no Gitblit.............................................................75
Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine ...77
Figura 36 – Painel de principal do repositório de código fonte..................................78
Figura 37 - Detalhe de confirmação de alteração no código fonte ............................79
Figura 38 - Tela principal do Jenkins.........................................................................80
Figura 39 - Painel principal de um trabalho Jenkins..................................................81
Figura 40 - Detalhe de uma construção do Jenkins ..................................................82
Figura 41 - Registro de alterações do banco de dados.............................................84
Figura 42 - Tela principal de um projeto no SonarQube............................................85
Figura 43 - Tela hotspot do SonarQube ....................................................................86
Figura 44 - Visualização detalhada de violações no SonarQube ..............................86
LISTA DE QUADROS
Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly.......................41
Quadro 2 - Configuração inicial do Wildfly.................................................................41
Quadro 3 - Configuração de porta TCP para execução do serviço Gitblit.................47
Quadro 4 - Configuração de diretório base para repositórios....................................47
Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit ...............48
Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory..................48
Quadro 7 - Instalação do serviço Windows para o Gitblit..........................................49
Quadro 8 - Configuração de diretório temporário para o SonarQube........................56
Quadro 9 - Instalação do serviço para o SonarQube e inicialização.........................57
Quadro 10 - Configuração do mecanismo de autenticação do SonarQube ..............58
Quadro 11 - Habilitação de download de executável NuGet.....................................67
Quadro 12 - Configuração de link entre o Gitblit e o Redmine ..................................71
Quadro 13 - Configuração do hook script redmine-fetch...........................................74
Quadro 14 - Configuração do hook script Jenkins.....................................................76
Quadro 15 - Matriz de rastreabilidade de artefatos ...................................................87
LISTA DE TABELAS
Tabela 1 - Usuários cadastrados no Active Directory................................................37
Tabela 2 - Lista de plugins instalados no Jenkins .....................................................54
Tabela 3 - Parâmetros para o plugin MSBuild...........................................................54
Tabela 4 - Parâmetros para utilização da plataforma Java .......................................55
Tabela 5 - Parâmetros para utilização do Redmine ..................................................55
Tabela 6 - Parâmetros para o plugin SonarQube......................................................55
Tabela 7 - Parâmetros para o plugin Maven .............................................................56
Tabela 8 - Lista de plugins instalados no SonarQube...............................................57
Tabela 9 - Tabela de versões criadas para o projeto ................................................63
Tabela 10 - Listagem de tarefas de desenvolvimento ...............................................63
LISTA DE SIGLAS
API Application Programming Interface
CMMI Capability Maturity Model Integration
IDE Integrated Development Environment
JDBC Java Database Connectivity
JDK Java Development Kit
JRE Java Runtime Environment
LDAP Lightweight Directory Access Protocol
LTS Long Term Support
MPS.BR Melhoria de Processo do Software Brasileiro
SCM Software configuration management
SQL Structured Query Language
TCP/IP Transmission Control Protocol / Internet Protocol
XML eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .......................................................................................................16
1.1 OBJETIVO GERAL .............................................................................................17
1.2 OBJETIVOS ESPECÍFICOS ...............................................................................17
1.3 JUSTIFICATIVA ..................................................................................................17
2 FUNDAMENTAÇÃO TEÓRICA..............................................................................20
2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE ....20
2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE .............................21
2.3 A INTEGRAÇÃO CONTÍNUA..............................................................................22
2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO
SOFTWARE..............................................................................................................25
3 MATERIAL E MÉTODOS.......................................................................................26
3.1 FERRAMENTAS .................................................................................................26
3.1.1 Linguagem de Programação ............................................................................26
3.1.1.1 Java..............................................................................................................27
3.1.1.2 C#.................................................................................................................27
3.1.2 Git.....................................................................................................................28
3.1.3 Jenkins .............................................................................................................29
3.1.4 Redmine...........................................................................................................30
3.1.5 SonarQube.......................................................................................................30
3.1.6 Liquibase..........................................................................................................31
3.2 METODOLOGIA..................................................................................................31
3.2.1 Cenário de Integração Contínua ......................................................................31
3.2.2 Configuração do Ambiente para Desenvolvimento ..........................................33
3.2.3 Construção do Protótipo...................................................................................34
3.3 INSTALAÇÃO DAS FERRAMENTAS .................................................................36
3.3.1 Sistema Operacional Windows.........................................................................36
3.3.2 Instalação da Plataforma Java .........................................................................37
3.3.2.1 Kit de Desenvolvimento Java .......................................................................38
3.3.2.2 Instalação da Ferramenta de Automação de Compilação............................39
3.3.2.3 Servidor de Aplicações.................................................................................40
3.3.2.4 Ambiente de Desenvolvimento .....................................................................41
3.3.3 Instalação da Plataforma .Net ..........................................................................42
3.3.3.1 Framework .Net ............................................................................................43
3.3.3.2 Ambiente de Desenvolvimento .....................................................................43
3.3.3.3 Preparação para a Integração Contínua.......................................................43
3.3.3.4 Servidor de Aplicações.................................................................................44
3.3.4 Instalação do Sistema Controle de Versões Git...............................................45
3.3.4.1 Git.................................................................................................................46
3.3.4.2 Gitblit ............................................................................................................47
3.3.4.3 TortoiseGit....................................................................................................50
3.3.4.4 TurtleMine.....................................................................................................50
3.3.5 Instalação do Redmine.....................................................................................50
3.3.6 Instalação do Jenkins.......................................................................................52
3.3.7 Instalação do SonarQube.................................................................................56
3.3.8 Instalação do Liquibase....................................................................................59
3.4 CONFIGURAÇÃO DO PROJETO.......................................................................59
3.4.1 Criação de Repositório de Código Fonte..........................................................59
3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento .................................62
3.4.3 Configuração de Trabalhos no Jenkins ............................................................64
3.4.3.1 Trabalho para o Ambiente de Desenvolvimento...........................................64
3.4.3.2 Trabalho para o Ambiente de Homologação ................................................65
3.4.3.3 Trabalho para o Ambiente de Produção.......................................................66
3.4.3.4 Preparação de Projetos .Net para a Integração Contínua ............................66
3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE ..........................67
3.5.1 Seleção de Tarefas do Redmine para Commit no Git ......................................67
3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do
Gitblit ........................................................................................................................71
3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do
Redmine....................................................................................................................72
3.5.4 Hook Scripts no Gitblit......................................................................................74
3.5.4.1 Script para Comunicação de Commit ao Redmine.......................................74
3.5.4.2 Script para Execução de Trabalhos no Jenkins............................................76
4 RESULTADOS E DISCUSSÕES ...........................................................................77
4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE..........................77
4.2 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO GITBLIT.............................78
4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS ...........................80
4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE .......................83
4.5 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO SONARQUBE ...................84
4.6 MATRIZ DE RASTREABILIDADE.......................................................................87
5 CONCLUSÃO.........................................................................................................89
5.1 CONSIDERAÇÕES FINAIS ................................................................................89
5.2 TRABALHOS FUTUROS ....................................................................................90
REFERÊNCIAS.........................................................................................................91
APÊNDICE A - TRABALHO DO JENKINS (.NET DESENV).....................................93
APÊNDICE B - TRABALHO DO JENKINS (JAVA DESENV)....................................94
APÊNDICE C – TRABALHO DO JENKINS (.NET HOMOLOGAÇÃO) .....................95
APÊNDICE D - TRABALHO DO JENKINS (JAVA HOMOLOGAÇÃO) .....................96
APÊNDICE E – ARQUIVO LIQUIBASE PARA TABELA DE ESTADO .....................97
APÊNDICE F – ARQUIVO LIQUIBASE PARA TABELA DE CIDADE.......................98
APÊNDICE G - ARQUIVO LIQUIBASE PARA TABELA DE PRODUTOS ................99
APÊNDICE H - ARQUIVO LIQUIBASE PARA TABELA DE PARCEIROS .............100
APÊNDICE I – ARQUIVO LIQUIBASE PARA TABELA DE PEDIDO......................101
APÊNDICE J – ARQUIVO LIQUIBASE INICIALIZAÇÃO DA EXECUÇÃO .............102
16
1 INTRODUÇÃO
A manutenção e evolução dos produtos de software se fazem necessárias
para muitas organizações, pois estes elementos sustentam a base operacional e
estratégica das mesmas. Conforme SOMMERVILLE (2011), altos investimentos são
realizados e as organizações se tornam cada vez mais dependentes de sistemas
computacionais.
Mesmo havendo o reconhecimento da necessidade de uma abordagem
profissional para a condução de projetos de software, muitos profissionais o fazem
sem prévio conhecimento de métodos e técnicas apropriadas. De acordo com
PRESSMAN (2011), nestas condições gera-se um produto final de baixa qualidade e
fadado a um curto tempo de vida.
O mesmo autor (PRESSMAN, 2011) enfatiza que durante o ciclo de vida de
grandes projetos, alterações não controladas podem minar a reputação do software.
É necessário utilizar procedimentos humanos e ferramentas automatizadas a fim de
garantir o bom andamento do processo. Para FARLEY e HUMBLE (2014), todo
processo que puder ser automatizado deverá ser. A automatização possibilita
repetibilidade, testabilidade, garantia de execução de todas as etapas de um
procedimento.
Considerando o exposto, neste trabalho são exploradas ferramentas e
técnicas para gerenciamento de configuração de software aliadas a automatização
proporcionada pela Integração Contínua. Com isso obtém-se a rastreabilidade de
artefatos de software durante o ciclo de vida do produto. Desta forma, é possível
aferir quais tipos de artefatos podem ser relacionados com um requisito, uma
liberação de versão que está implantada, ou até mesmo quando e porque surgiu um
determinado artefato que se encontra no produto.
Os resultados obtidos são apresentados por meio de matriz de referência
cruzada informando qual o nível de rastreabilidade poderá se obter a partir de um
determinado artefato do processo de desenvolvimento e manutenção do software.
17
1.1 OBJETIVO GERAL
Aplicação da Integração Contínua para viabilizar a rastreabilidade de artefatos
durante a manutenção de software.
1.2 OBJETIVOS ESPECÍFICOS
Para atingir o objetivo geral os seguintes objetivos específicos são propostos:
a. Revisar de literatura sobre técnicas de Integração Contínua e
Gerenciamento de Configuração de Software;
b. Identificar técnicas que favorecem a obtenção da rastreabilidade de
artefatos.
c. Avaliar técnicas existentes para aplicação da Integração Contínua.
d. Verificar ferramentas de controle de versão, Integração Contínua,
gerenciamento de projetos, que possibilitem a aplicação das técnicas
avaliadas.
e. Elaborar uma aplicação experimental e configurar um ambiente integrado
para gerenciamento do ciclo de vida de aplicações, que serão utilizados
para verificação e aplicação das técnicas avaliadas.
1.3 JUSTIFICATIVA
Durante o ciclo de vida de um software há muitas mudanças de
funcionalidades, alterações de artefatos, adição de componentes, etc. Tais
manutenções provêm de mudanças nos requisitos de negócios, que serviram de
base para a concepção do produto, mudanças no ambiente onde o software está
sendo utilizado, adequações à legislação, ou até mesmo uma simples refatoração de
código. A manutenção do software é de suma importância para que o mesmo tenha
18
longo tempo de utilização. Entretanto, todos os eventos de desenvolvimento ou
manutenção do software devem ser registrados por meio de procedimento e técnicas
abordados pela Gerência de Configuração.
A Gerência de Configuração orienta o processo de desenvolvimento de
software para que seja possível identificar requisitos iniciais do sistema, registrar os
defeitos encontrados no produto bem como suas alterações ao longo de seu tempo
de vida. A Gerência de Configuração recomenda também o uso de ferramentas para
que seja possível ter o registro histórico de todas as alterações que ocorreram no
código fonte do software (SOMMERVILLE, 2011). As ferramentas comumente
utilizadas são sistemas de registro de bugs ou solicitações de desenvolvimento e
sistema de controle de versões de código fonte.
Estes tipos de ferramentas já estão difundidos no cenário de desenvolvimento
de software, contudo a abordagem da Gerência de Configuração vai além da
utilização destas. De acordo com SOMMERVILLE (2011), para a utilização eficiente
das técnicas de Gerência de Configuração é necessário:
a. Existir o registro de todas as requisições de mudanças em uma
ferramenta apropriada;
b. Ter a utilização de um mecanismo de controle de versões e não utilizá-lo
apenas como um repositório de arquivos, mas também registrar etiquetas
para marcar versões de produto, criar linhas de desenvolvimento
conhecidas com branch quando houver necessidade de implementações
ou correções em diferentes versões do software; e
c. Utilização de um sistema de compilação e construção automatizado que
consiga agregar código-fonte, bibliotecas e executar testes.
É importante ressaltar que PRESSMAN (2011) trás algumas características
importantes que o Gerenciamento de Configuração deve possibilitar, dentre elas
estão:
a. Controle de Requisitos – possibilita rastrear qual requisito gerou
determinado artefato do produto; e
b. Pistas de auditoria – trás informações que permite identificar quando,
por quem e por que alterações foram feitas no software.
19
Para que o Gerenciamento de Configuração aconteça com eficiência pode-se
utilizar técnicas de Integração Contínua. A Integração Contínua preza pela
automação do processo de construção do software, testes e implantação, durante a
confirmação de alteração do programa no sistema de controle de versões
(FOWLER, 2006).
A utilização de uma ferramenta para aplicação de técnicas de Integração
Contínua é de fundamental importância. Com a automação de procedimentos pode-
se montar um fluxo de trabalho para implantação do software que se inicia na
integração da manutenção dos diversos desenvolvedores até a implantação final em
ambiente produtivo. Sendo assim, não há intervenção manual na compilação ou
disponibilização do software em ambiente produtivo, o que dá a garantia de um nível
elevado de auditoria do processo de desenvolvimento ou até mesmo de repetições
ou testes do mesmo (SMART, 2011).
20
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo tem como objetivo apresentar os principais conceitos e técnicas
básicas para o entendimento do trabalho desenvolvido. São abordados aspectos
relacionados ao processo de desenvolvimento de software, gerenciamento da
configuração, Integração Contínua, e finalmente a rastreabilidade de artefatos de
software.
2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE
Durante o ciclo de vida de um software, diversas atividades são executadas
para que seja possível efetuar a construção do produto. São elencados e
especificados os requisitos, é elaborado projeto de banco de dados, arquitetura e
interface, posteriormente é desenvolvido o produto, os testes são efetuados e
finalmente ocorre a homologação do mesmo. Ao final destas atividades são
realizados os ajustes necessários a partir do feedback obtido e liberado o produto
para uso (SOMMERVILLE, 2011).
Uma vez concluído o processo de desenvolvimento do software e o produto
liberado para uso surgem necessidade de mudanças. As mudanças pode ser em
requisitos, novas tecnologias, necessidade de novos recursos ou mesmo para
correção de defeitos (PRESSMAN, 2011). De modo complementar, SOMMERVILE
(2011) apresenta a evolução do software como fator importante, pois as empresas
despendem grandes volumes financeiros nestes e existe grande dependência dos
mesmos para realização de suas atividades.
Fatores internos à equipe de desenvolvimento também podem gerar
manutenção do software. O processo de refatoração apresentado por FOWLER
(2004) propõe alterações do sistema sem que haja alteração do comportamento do
mesmo. Estas modificações podem ser efetuadas visando eliminar redundância ou
elementos não utilizados, melhorar a eficiência de algoritmos, adequar estrutura de
dados, reduzir o acoplamento e aumentar a coesão.
21
2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE
De acordo com PRESSMAN (2011) os processos de gerência de
configuração visam identificar e controlar alterações do software, garantir que
trabalhos de manutenção do produto sejam implementados corretamente, e prover
informações sobre as alterações a quem houver interesse. A gestão da configuração
se baseia em um conjunto de atividades que visam dar rastreabilidade e controle dos
trabalhos realizados durante o ciclo de vida do software.
SOMMERVILE (2011) apresenta quatro grandes atividades que resumem o
processo de gerenciamento de configuração, as quais são:
a. Gerenciamento de mudanças – diz respeito ao acompanhamento de
requisições de mudanças e avaliação de custo, impacto, como e quando
efetuar tal mudança;
b. Gerenciamento de versões – garantir a manutenção das diversas
revisões dos componentes para que haja o histórico de mudanças e
trabalho de diferentes desenvolvedores de forma distribuída e paralela
sem interferência mutua;
c. Construção do sistema – diz respeito à resolução de dependências1
de
artefatos e componentes externos a fim de gerar o sistema executável; e
d. Gerenciamento de releases – Preparar o software para disponibilizá-lo
ao cliente e manter o histórico de versões liberadas anteriormente.
Para haver um bom processo de Gerenciamento de Configuração é
necessário validar três itens básicos. Primeiramente, permitir identificar rapidamente
qual a versão exata dos artefatos que são implantados em produção.
Consequentemente deve ser possível recuperar facilmente a versão exata dos
artefatos que estão em produção. De forma complementar também é necessário que
haja possiblidades de se efetuar pequenas correções na versão dos artefatos que
estão em produção, compilar novamente esta versão corrigida e implantar a mesma
(AIELLO e SACHS, 2011).
1
Agregar artefatos necessários para a construção do software, tais como biblioteca de código.
22
Além disso, um processo de gerenciamento de configuração bem definido e
aplicado é requisito para obtenção de certificações de qualidade, tais como CMMI e
MPS.BR.
Segundo SOFTEX (2013), o processo gerenciamento de configuração é
importante para o desenvolvimento de software, pois permite que haja o controle
sobre o que é desenvolvido e alterado. A necessidade deste processo é definida em
seu Guia de Fundamentação para Implementação do Nível F, o segundo nível em
sua escala de níveis de maturidade, que se inicia com o nível G com o tema de
Gerenciamento de Processos e Requisitos e segue até o nível A, que possui foco na
otimização do processo.
Para CMMI (2014), o Gerenciamento da Configuração deve:
a. Garantir a seleção de item de trabalho para cada versão do software a ser
desenvolvida;
b. Controlar as alterações nos documentos que guiam o desenvolvimento; e
c. Prover status e dados sobre a configuração do software para
desenvolvedores, usuários finais e clientes.
O guia CMMI for Development em sua versão 1.3 também apresenta que um
dos propósitos fundamentais do Gerenciamento da Configuração é a auditoria da
configuração.
2.3 A INTEGRAÇÃO CONTÍNUA
Conforme FOWLER (2006), o processo de Integração Contínua é baseado
em um conjunto de práticas que visam agilizar o processo de implantação, diminuir a
quantidade de defeitos no sistema ou o mesmo diminuir o tempo de permanência de
um defeito no sistema. Dentre estas práticas podem ser destacadas:
a. Automatização de build – envolve a automatização do agrupamento de
artefatos, resolução de dependência, atualização de banco de dados e
compilação do software. Esta automatização previne a ocorrência de
23
erros neste processo, proporciona um processo testável e que pode ser
repetido.
b. Build auto testável - apresenta a inclusão de testes automatizados como
elemento fundamental para validação e verificação do software, indo além
da compilação e chegando a verificar se cada funcionalidade foi
desenvolvida conforme especificado. Com isso é possível obter maior
segurança na implantação.
c. Commits frequentes – é de fundamental importância que os membros da
equipe de desenvolvimento enviem suas alterações para o sistema de
controle de versões em um curto intervalo de tempo. É recomendável que
isso seja feito em um período máximo de um dia. Esta prática favorece a
localização rápida de defeitos decorrente da integração do trabalho de
diversos desenvolvedores.
d. Cada commit deve atualizar o repositório em um servidor de
integração – o serviço de Integração Contínua monitora o repositório do
software e inicia a construção automatizada sempre que uma alteração do
código fonte for enviada ao repositório e emite notificação em caso de
falha na construção.
e. Todos devem ver o que está acontecendo – em um processo de
Integração Contínua é importante que toda a equipe possa obter
facilmente o estado do build e as mudanças que foram realizadas no
sistema. É recomentado que o servidor de Integração Contínua possa
apresentar tais informações por meio de um site que possa ser
visualizado de forma facilitada.
f. Automatização da implantação do sistema – para maior efetividade do
processo é necessário que os procedimentos de implantação do software
sejam automatizados de forma que permita sua execução em diversos
servidores, tais como ambiente de teste, homologação ou produção. Com
isso é minimizado o tempo de implantação e a incidência de erros.
De acordo com DUVALL, MATYAS e MATYAS (2007), a Integração Contínua
tem como alguns dos principais fundamentos: redução de riscos, redução de
processos manuais repetitivos e permitir melhor visibilidade do projeto.
24
A redução de riscos pode ser obtida devido à integração frequente do código,
o que possibilita a detecção prévia de defeitos mediante a inspeção automatizada do
código, pode-se obter informações de complexidade deste código a cada alteração,
também é possível coletar dados referentes à aderência a padrões de codificação,
cobertura de testes e duplicação de código. Devido à execução da construção do
software no servidor de Integração Contínua é possível prevenir que o sistema
mantenha referencias para elementos como artefatos e variáveis de ambiente
exclusivas do contexto do desenvolvedor.
Com a automatização de processos repetitivos como recuperação de código a
partir de um sistema de controle de versões, compilação, atualização de base de
dados, teste, inspeção, implantação e criação de uma etiqueta (tag) no sistema de
controle de versões, é possível que o processo seja executado toda vez que o
código for alterado e sempre com os mesmos passos e da mesma forma. Deste
modo as pessoas podem manter o foco em trabalhos de alto valor agregado. Outro
ponto importante é que o processo de build seja construído de tal forma que possa
ser executado a partir de um único comando.
Um serviço para Integração Contínua pode prover informações em tempo real
sobre status da construção, métricas de qualidade e defeitos. Também é possível
manter informações de tendências bem como outras informações por meio de
plugins.
De forma complementar FARLEY e HUMBLE (2014) observam que não é
necessário somente ter um processo de construção e implantação automatizado,
mas é importante que o mesmo abra a possibilidade de reverter uma implantação
sem sucesso. Caso contrário o ambiente produtivo será penalizado caso haja algum
imprevisto, seja por motivo de depuração de uma aplicação no ambiente ou mesmo
pela permanência do defeito. No entanto, é de suma importância observar relações
de dependência entre sistemas integrados, ou mesmo os impactos da implantação
no banco de dados, pois procedimentos de reversão da implantação podem ter
limitações relevantes.
25
2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO
SOFTWARE
Conforme EDWARDS e HOWELL (1991), uma lista de requisitos corretos e
consistentes não garantem que o produto de software final estará de acordo com as
expectativas dos stakeholders. É necessário que o projeto do produto esteja
alinhado aos requisitos e posteriormente à implementação esteja coerente com o
que se espera. Com um processo provido de rastreabilidade é possível identificar
incoerências entre estas fases do desenvolvimento de software ou até mesmo
evidenciar a mudança de um requisito após o mesmo ter sido desenvolvimento no
produto.
A rastreabilidade de artefatos dá condições de auditoria de todas as
características de um sistema e saber que alterações foram efetuadas a partir de
uma requisição de mudança do produto. Ter um processo com rastreabilidade
possibilita saber qual requisito gerou uma determinada característica do sistema,
qual a origem de tal requisito, verificar se o projeto e a implementação foram
executados corretamente (HAMILTON e BEEBY, 1991).
Podem-se obter recursos de rastreabilidade no processo de desenvolvimento
de software de duas formas. Uma é a geração de links diretos na aplicação de
gerenciamento de configuração, de forma que seja possível, a partir de cliques,
navegar de um requisito para um registro de alteração no controle de versões, saber
qual foi o requisito que está associado a um conjunto de alterações de artefatos, ou
mesmo a partir do registro de uma construção do software visualizar as alterações
de código que estão contidas no mesmo. Outra forma é a obtenção de tais
informações por meio de relatórios e matrizes de relacionamento, dentre outros
(EDWARDS e HOWELL, 1991).
FARLEY e HUMBLE (2014) ressaltam ainda, a importância fundamental de
que o processo de Gerenciamento de Configuração possibilite que se consiga saber,
a partir de um binário em execução, qual a revisão no controle de versões deu
origem ao mesmo, de forma que, havendo a necessidade de correção de um
software que esteja em produção, seja possível fazê-la sem dispêndio de grande
esforço para obter o código fonte correspondente.
26
3 MATERIAL E MÉTODOS
Este capítulo apresenta as ferramentas que são utilizadas para aplicação dos
conceitos e técnicas, bem como a metodologia abordada neste trabalho. O capítulo
está dividido em cinco seções, sendo que a primeira expõe as ferramentas e a
segunda a metodologia utilizada, na terceira parte é apresentada a instalação destas
ferramentas, posteriormente a configuração inicial da mesma e finaliza com algumas
configurações adicionais para prover a rastreabilidade.
3.1 FERRAMENTAS
As ferramentas empregadas na abordagem prática deste trabalho são:
linguagens de programação Java e C#, sistema de controle de versão Git, servidor
de Integração Contínua Jenkins, gerenciador de projetos Redmine, plataforma para
gerenciamento de qualidade do código SonarQube, e Liquibase para controle de
versão de elementos de banco de dados. Tais ferramentas são apresentadas a
seguir.
3.1.1 Linguagem de Programação
A pesquisa realizada neste trabalho tem como base as linguagens de
programação Java2
e C#3
. São duas das linguagens de programação mais utilizadas
profissionalmente, segundo o Índice TIOBE4
de 2014. De forma complementar
MOMBREA (2014), salienta que tais linguagens de programação são as mais
relevantes para desenvolvimento de sistemas em ambiente corporativo, e também
proporciona maior facilidade para o aprendizado de outras linguagens.
2
http://www.oracle.com/br/technologies/java/overview/index.html
3
http://msdn.microsoft.com/pt-br/library/67ef8sbd.aspx
4
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
27
3.1.1.1 Java
Conforme FLANAGAN (2005), Java é uma linguagem orientada a objeto com
sintaxe similar a C. É uma linguagem de implementação híbrida, ou seja, quando um
código fonte é compilado, ele é convertido em byte codes que são códigos binários
portáveis para qualquer arquitetura de hardware que possua uma máquina virtual
Java para interpretá-los.
Quando o Java é instalado para desenvolvimento de aplicações, o mesmo
disponibiliza um conjunto básico de classes APIs (Application Programming
Interface) para entrada/saída de dados, comunicação em rede, componentes de
interface gráfica, dentre outros que juntos formam a plataforma Java (FLANAGAN,
2005).
Como linguagem de programação, Java foi projetada para que
desenvolvedores escrevam programas robustos com facilidade (FLANAGAN, 2005).
3.1.1.2 C#
A linguagem de programação C# é orientada a objetos, possui sintaxe
simples, é considerada moderna e é semelhante a C++ ou Java. Esta linguagem
também tem por objetivo fornecer base para construção de aplicações robustas e
com longo tempo de vida (HEJLSBERG et al, 2011).
De acordo com HEJLSBERG et al (2011), C# também trabalha pelo modo de
implementação híbrido, ou seja, sua compilação gera um código intermediário
denominado .NET Common Language Interface, que é interpretado pelo .NET
Common Language Runtime.
28
3.1.2 Git
Como ferramenta open source para controle de versão, optou-se pelo Git5
,
conforme recomendado por FOWLER (2010). Devido a sua característica de ser
distribuído permite uma utilização mais eficiente no acesso a logs históricos. Não é
necessário requisição ao repositório principal para toda consulta de log, pois todos
tem uma cópia completa do repositório consigo. O Git também favorece a
segurança, pois um novo membro que se junta à equipe pode trabalhar a partir de
um repositório de um desenvolvedor sênior da equipe de modo que este valide seus
desenvolvimentos e envia ao repositório central.
Git é um sistema de controle de versões distribuído, ou seja, todo check out
do repositório se torna uma cópia completa do repositório principal e pode ser
compartilhada com outros desenvolvedores. Conforme CHACON (2009), este
modelo de trabalho permite que diversas equipes possam trabalhar simultaneamente
no mesmo projeto.
A Figura 1 possibilita o melhor entendimento do modelo.
Figura 1 - Sistema de controle de versões distribuído
Fonte: CHACON (2009)
5
http://git-scm.com/
29
De acordo com CHACON (2009) o Git também possui uma forma de
execução de eventos que são disparados em alguns momentos quando são
realizados procedimentos nesta ferramenta. Estes eventos executam scripts que
podem ser customizados e são denominados hook scripts. Existem scripts que
podem ser executados quando ocorrem eventos no ambiente cliente, tais como
checar se uma mensagem de confirmação de alteração no código fonte foi escrita de
acordo com o padrão definido para o repositório. Também existem scripts que
podem ser executados no lado do servidor, antes ou depois do mesmo processar um
recebimento de alterações do código fonte.
Estes scripts do lado do servidor podem ser utilizados para acionar atividades
de Integração Contínua a cada alteração no repositório principal.
3.1.3 Jenkins
Para aplicação da Integração Contínua, foi escolhido o Jenkins6
, que é uma
ferramenta open source, derivada do Hudson e escrita em Java. É uma ferramenta
utilizada por equipes de vários tamanhos e em projeto que fazem uso de diversas
tecnologias e linguagens de programação (SMART, 2011).
O Jenkins se propõe a ser fácil de usar, tem uma interface simples e intuitiva.
Esta ferramenta possui uma ampla comunidade, que desenvolve, adiciona novas
características e corrige bugs rapidamente, gerando novas versões constantemente.
No entanto para usuários e empresas que não são afetos a ciclos curtos de
atualizações, o Jenkins mantem um versão Long-Term Support (LTS) que garante
um tempo maior de vida para uma determinada versão, para a qual é disponibilizada
correções por um tempo diferenciado da versão padrão (SMART, 2011).
6
http://jenkins-ci.org/
30
3.1.4 Redmine
Para gerenciamento de projetos optou-se pelo Redmine7
, que é uma
ferramenta open source escrita em Ruby on Rails. Esta ferramenta possui uma
variedade de recursos para auxiliar na condução de projetos, tais como: controle de
perfis de acesso, gráfico de Gantt, calendário, planejamento de versões e tarefas
necessárias para liberação destas, integração com sistema de controle de versões,
gerenciamento de documentos e notícias (LESYUK, 2013). O Redmine também
possui uma API de integração que permite à outras ferramentas desenvolver plugins
de integração para registrar suas atividades.
3.1.5 SonarQube
SonarQube8
é uma ferramenta open source que foi escolhido para apresentar
relatórios da qualidade do código. Trabalhando em conjunto com uma ferramenta de
Integração Contínua, pode-se conseguir grande melhora na qualidade do código.
Esta ferramenta aponta problemas de aderência a padrões de codificação
inseridos pelos desenvolvedores, cobertura de testes, duplicações de código,
documentação no código (como Javadoc), complexidade ciclomática, provendo
análises de evolução destas métricas (CAMPBELL e PAPAPETROU, 2014).
As informações registradas possibilitam um acompanhamento temporal da
evolução da qualidade do software e auditar quem e quando realizou alterações que
interferiram na qualidade da codificação.
7
http://www.redmine.org/
8
http://www.sonarqube.org/
31
3.1.6 Liquibase
Finalmente, foi utilizada a ferramenta open source Liquibase9
para dar suporte
ao versionamento de elementos do banco de dados. Esta ferramenta permite
armazenar todas as alterações em arquivo XML (eXtensible Markup Language),
fazer atualização de itens de banco de dados, bem como retroceder a um estado
anterior dos mesmos. O Liquibase possibilita a geração de arquivo com a diferença
de objetos entre dois bancos de dados, gerar um arquivo com objetos de um banco
de dados existente para ser transportado para outro ambiente, ou simplesmente
para gerar uma posição inicial de versionamento. Com o Liquibase é possível
realizar a alteração do banco de dados a partir da utilização de Ant, Maven, Servlet
ou mesmo linha de comando. Esta ferramenta trabalha com mais de dez sistemas
gerenciadores de banco de dados, dentre os quais estão: Oracle, Microsoft SQL
Server e MySQL.
3.2 METODOLOGIA
A apresentação da metodologia utilizada está dividida em três seções, sendo
que a primeira trata do cenário de integração continua utilizada, a configuração do
ambiente para validação e finalmente a construção do protótipo.
3.2.1 Cenário de Integração Contínua
Além do sistema utilizado como protótipo foi montado um cenário de
Integração Contínua com um servidor para gerenciamento do ciclo de vida de
aplicações. Neste servidor foram instaladas as ferramentas a serem avaliadas: Git,
9
http://www.liquibase.org/
32
Liquibase, Jenkins, Redmine, SonarQube, Java e .Net. A Figura 2 ilustra as
comunicações entre os sistemas para Integração Contínua.
Figura 2 - Intercomunicação entre serviços
Fonte: Autoria própria.
A Figura 2 apresenta as seguintes atividades de processo de
desenvolvimento:
a. Inicialmente ocorre à construção do software na máquina do
desenvolvedor e o este utiliza um conjunto de bibliotecas de código
disponibilizadas para desenvolvimento;
b. Cada biblioteca utilizada na construção do software é obtida a partir de
um repositório, e é utilizado um recurso de resolução de dependências
apropriado para a tecnologia, que pode ser Maven10
para o ambiente Java
ou NuGet11
para .Net;
10
http://maven.apache.org/
11
https://www.nuget.org/
33
c. Após ter desenvolvido os requisitos e realizado uma construção com
sucesso, o desenvolvedor confirma as alterações no serviço repositório de
fontes, onde é realizado o controle de versões;
d. O repositório de fontes notifica o servidor de Integração Contínua de que
houve uma mudança no código fonte;
e. É iniciado um trabalho no servidor de Integração Contínua que obtém os
códigos do programa, efetua a construção com resolução de
dependências no mesmo mecanismo utilizado pelo desenvolvedor
anteriormente;
f. Na sequência é feito atualização dos objetos do banco de dados para a
última versão por meio do Liquibase;
g. Depois é processada a análise para coleta de métricas pelo SonarQube,
onde se obtém dados como: cumprimento de padrões de codificação,
comentários e documentação de código, complexidade ciclomática, dentre
outros; e
h. Finalmente, caso seja necessário, é realizada a implantação do software
no devido servidor de aplicação que lhe for conveniente.
3.2.2 Configuração do Ambiente para Desenvolvimento
Após a configuração das ferramentas, foram realizados os seguintes
procedimentos:
a. Abertura de projeto no sistema de gerenciamento de projetos Redmine;
b. Registro de requisitos e atividades de desenvolvimento no sistema de
gerenciamento de projetos;
c. Associação de tarefas de desenvolvimento aos membros da equipe;
d. Abertura de um projeto no sistema de controle de versões Git;
e. Criação do fluxo de trabalho para implantação do software, no Jenkins,
com atividades a serem realizadas no momento da disponibilização do
software em ambiente de desenvolvimento, ambiente de qualificação
(homologação) e ambiente produtivo;
34
f. Desenvolvimento do software protótipo (apresentado na seção 3.2.3) e
utilização do sistema de versionamento de software;
g. Realização de alterações no software e confirmação das alterações no
controle de versão;
Os resultados destas etapas contribuirão para rastreabilidade do processo de
desenvolvimento, conforme apresentado no Capítulo 4 deste trabalho.
3.2.3 Construção do Protótipo
Para demonstrar a metodologia deste trabalho, é utilizado um exemplo
ilustrativo de um sistema simples de pedidos. O sistema possui apenas uma tela de
pedidos de venda e seus cadastros correlatos, conforme especificação apresentada
a seguir.
A Figura 3 apresenta o diagrama das classes de entidades a utilizadas no
desenvolvimento do protótipo. A representação dos métodos foi omitida para
possibilitar o melhor entendimento do modelo.
Figura 3 - Diagrama de classes do sistema de pedidos de venda
Fonte: Autoria própria.
35
Este software tem apenas um caso de uso que representa o lançamento de
pedidos de venda. O diagrama apresentado na Figura 4 representa este caso de
uso.
Figura 4 - Diagrama de caso de uso do sistema de pedidos de venda
Fonte: Autoria própria.
A Figura 5 traz o diagrama de sequência que demonstra o fluxo de ações e
respostas do software. Este diagrama trás inicialmente a preparação inicial do
pedido a partir dos dados de cliente e data de vencimento. Posteriormente é
realizada a inserção dos itens com suas referentes quantidade do pedido.
Finalmente é apresentada a operação “salvar” que realiza a gravação do pedido e
informa o numero do mesmo para o usuário.
Figura 5 - Diagrama de sequencia do sistema de pedidos de venda
Fonte: Autoria própria.
36
3.3 INSTALAÇÃO DAS FERRAMENTAS
O conteúdo desta seção mostra informações relevantes sobre a instalação e
configuração do conjunto de ferramentas, sendo elas: o sistema operacional
Windows, plataforma de desenvolvimento, sistema de controle de versões Git,
sistema para gerenciamento de projetos Redmine, sistema para métricas de
software SonarQube, e sistema para Integração Contínua Jenkins.
3.3.1 Sistema Operacional Windows
A instalação das ferramentas é realizada em servidor com sistema
operacional Microsoft Windows 2008 R2 com arquitetura de 64 bits executando em
uma máquina virtual na plataforma VMware Workstation. Esta máquina virtual possui
dois núcleos de processamento, contém 1,5 gigabytes de memória e executa sob o
endereço IP 192.168.118.137.
O sistema operacional Windows foi utilizado para possibilitar a demonstração
das ferramentas tanto para plataforma Java quando para Microsoft .Net. Para
equipes dedicadas exclusivamente a plataforma Java, todas as ferramentas de base
poderiam ser instaladas em sistema operacional Linux.
Neste servidor, foi configurado o Microsoft Active Directory para gerenciar
autenticações de forma centralizada para todas as ferramentas utilizadas neste
trabalho, favorecendo desta forma a rastreabilidade.
O domínio configurado é apresentado na Figura 6, conforme a seguir:
37
Figura 6 - Domínio Microsoft Active Directory
Fonte: Autoria própria.
Neste domínio foram criados dois usuários e dois grupos, conforme
apresentado na Tabela 1.
Tabela 1 - Usuários cadastrados no Active Directory
Nome Descrição Grupo
aplicacao Utilizado para autenticar usuários
no domínio Active Directory
usuarios
desenv Utilizado para simular operações de
desenvolvimento
usuarios, administradores
Fonte: Autoria própria.
3.3.2 Instalação da Plataforma Java
A preparação do ambiente para execução da plataforma Java foi segmentado
em três etapas, sendo elas:
a. Instalação do kit de desenvolvimento;
b. Instalação da ferramenta para automação de compilação
c. Instalação do servidor de aplicações; e
d. Instalação da ferramenta de desenvolvimento.
38
As três primeiras foram executadas no ambiente de desenvolvimento e no
servidor, a quarta etapa foi executada apenas no ambiente de desenvolvimento. Tais
etapas são descritas a seguir.
3.3.2.1 Kit de Desenvolvimento Java
Para execução dos procedimentos deste trabalho optou-se pela última versão
estável, para arquitetura de 64 bits, do ambiente de desenvolvimento Java também
conhecida com Java Development Kit (JDK) que é a JDK 7u5112
.
O instalador foi executado seguindo as configurações padrão, tendo apenas o
diretório de instalação modificado para C:Serverjdk1.7.0_51_x64. Depois de
finalizada a execução do instalador, foi criada uma variável de ambiente do
Windows, chamada JAVA_HOME, a qual teve como conteúdo o diretório da
instalação da JDK, conforme Figura 7.
Figura 7 - Variável de ambiente JAVA_HOME
Fonte: Autoria própria.
12
http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html
39
De forma complementar também foi adicionado o endereço
%JAVA_HOME%bin à variável de ambiente Path, conforme Figura 8.
Figura 8 - Variável de ambiente Path com JDK
Fonte: Autoria própria.
3.3.2.2 Instalação da Ferramenta de Automação de Compilação
A ferramenta Maven foi utilizada para automatizar o processo de compilação
da aplicação Java. O instalador desta aplicação foi obtido no endereço web oficial13
e sua instalação foi realizada por meio da descompactação do arquivo no diretório
C:Serverapache-maven-3.2.1.
De forma complementar também foi necessário a criação de uma variável de
ambiente denominada M2_HOME, cujo valor é o caminho do diretório de instalação da
ferramenta. Para finalizar a instalação do Maven foi adicionado o valor
%M2_HOME%bin à variável de ambiente PATH. Os procedimentos para a criação
destas variáveis foram omitidos, pois são similares aos apresentados na seção
3.3.2.1.
13
http://maven.apache.org/download.cgi
40
3.3.2.3 Servidor de Aplicações
Também foi instalado o software Wildfly para ser utilizado como servidor de
aplicações Java Enterprise Edition. Este software é o sucessor do JBoss14
, que
assim era chamado até a versão 7. O mesmo foi obtido através do site do
desenvolvedor15
e sua instalação foi realizada por meio da descompactação do
arquivo no diretório C:Serverwildfly-8.0.0.Final. A utilização de outro
servidor de aplicação poderia ser feita sem impactos no resultado da pesquisa.
Todavia deve-se observar que os comandos de implantação da aplicação e o plugin
necessário no ambiente de desenvolvimento seriam diferentes.
Três configurações adicionais foram necessárias para que o Wildfly estivesse
executando de forma plena:
a. Alteração de endereço e porta TCP/IP para execução;
b. Adição de usuário para funções administrativas;
c. Instalação do serviço Windows para inicialização do servidor.
O Quadro 1 apresenta a alteração realizada no arquivo de configuração do
Wildfly “standalonecondigurationstandalone.xml”, sob o diretório de
instalação do Wildfly.
14
http://jbossas.jboss.org/
15
http://wildfly.org/downloads/
41
Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly
O Quadro 2 apresenta a execução dos comandos necessários para a
realização destas configurações.
Quadro 2 - Configuração inicial do Wildfly
3.3.2.4 Ambiente de Desenvolvimento
Para ambiente de desenvolvimento na plataforma Java optou-se pela
ferramenta open source Eclipse IDE for Java EE Developers, sendo que foi utilizada
42
a versão 4.3.2 obtida no endereço oficial16
. Para instalação da mesma foi apenas
descompactado o arquivo obtido em uma pasta local denominada
c:javaeclipse. Qualquer outra ferramenta poderia ter sido utilizada sem
impactar o resultado do processo de desenvolvimento.
Foi necessária também a instalação do plugin JBoss Tools17
para integração
do ambiente de desenvolvimento com o servidor de aplicações Wildfly. Para
instalação deste plugin foi acessado o menu “Help” do Eclipse e acessado a opção
“Eclipse Market Place”. Nesta tela foi realizado a busca pelas palavras “JBoss Tools”
e selecionado a opção de instalação para o item “JBoss Tools (Kepler) 4.1.2 Final”.
3.3.3 Instalação da Plataforma .Net
A preparação do ambiente para execução de aplicações .Net foi divida em
quatro etapas, sendo elas:
a. Instalação framework .Net;
b. Instalação do ambiente de desenvolvimento;
c. Preparação para integração contínua; e
d. Instalação do servidor de aplicações.
As etapas “a” e “b” foram no ambiente de desenvolvimento e no lado do
servidor foram executadas todas as etapas, com exceção do item “b”.
16
https://www.eclipse.org/downloads/
17
http://tools.jboss.org/
43
3.3.3.1 Framework .Net
Para esta plataforma que é base para a linguagem C#, foi obtido o instalador
do Microsoft .Net Framework 4.518
. Os procedimentos de instalação seguiram
configurações padrão sugeridas pelo próprio instalador.
3.3.3.2 Ambiente de Desenvolvimento
A instalação do ambiente de desenvolvimento foi realizada a partir da mídia
da versão Visual Studio Professional 2012 obtida a partir do site Microsoft
DreamSpark for Academic Institutions. Sua instalação seguiu com todas as
configurações padrão.
3.3.3.3 Preparação para a Integração Contínua
Para realizar a compilação do projeto no servidor foi necessário instalar o
Windows Software Development Kit for Windows 819
e o Microsoft Visual Studio
Express 2012 for Web20
. O processo de compilação necessita de algumas
bibliotecas e referências que são próprias da ferramenta de desenvolvimento e não
são instaladas com o framework .Net. Ambas as ferramentas foram instaladas a
partir de suas opções padrão.
No ambiente do servidor também foi necessário realizar a instalação do
Microsoft Web Deploy v3.521
para possibilitar a automação de implantação de
aplicações no servidor web Internet Information Services. Este utilitário foi instalado
com uso de suas configurações padrão.
18
http://www.microsoft.com/pt-br/download/details.aspx?id=40779
19
http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx
20
http://www.microsoft.com/en-us/download/details.aspx?id=30669
44
3.3.3.4 Servidor de Aplicações
Para possibilitar a execução da aplicação em ASP.Net no servidor, também
foi preciso instalar o servidor Internet Information Services. Para isso foi necessário
acessar a opção “Server Manager” (Gerenciador do Servidor) a partir do menu de
ferramentas administrativas do Windows e adicionar o papel (role) de Web Server ao
servidor Windows, marcando as opções apropriadas para ASP.Net, de acordo com a
Figura 9.
Figura 9 - Instalação do Microsoft Information Services
Fonte: Autoria própria.
Também foi necessário alterar a configuração do site padrão do Internet
Information Services para executar na porta TCP/IP 8888, pois a porta padrão 80
seria utilizada pelo servidor web Apache para a execução do Redmine. De forma
complementar também foi alterado o site padrão para utilizar o Application Pool
baseado no Framewok .Net 4, conforme Figura 10.
21
http://www.microsoft.com/en-us/download/details.aspx?id=39277
45
Figura 10 - Configuração do application pool para o site padrão
Fonte: Autoria própria.
Finalmente, para conexão com banco de dados MySQL utilizado no
desenvolvimento do protótipo, se fez necessário a instalação do driver apropriado, o
qual foi obtido no site oficial22
e instalado utilizando suas configurações padrão.
3.3.4 Instalação do Sistema Controle de Versões Git
Foram utilizadas quatro ferramentas para possibilizar a geração de
rastreabilidade a partir do controle de versões. Sendo elas apresentadas a seguir.
22
http://dev.mysql.com/downloads/connector/net/
46
3.3.4.1 Git
Este é o mecanismo de controle de versões propriamente dito, o qual teve
sua versão 1.9.0 para sistema operacional Microsoft Windows obtida a partir do
site do Git23
.
No servidor, este software foi instalado seguindo suas opções padrão, com
exceção do diretório de instalação, que foi modificado para c:ServerGit e
adicionado o caminho C:ServerGitcmd à variável de ambiente Path no
Windows conforme Figura 11.
Figura 11 - Variável de ambiente Path
Fonte: Autoria própria.
No ambiente cliente todas as opções padrão foram mantidas.
23
http://git-scm.com/download
47
3.3.4.2 Gitblit
Este software disponibiliza uma interface web para visualização e
gerenciamento dos repositórios de fontes no servidor, sendo utilizada a versão
1.4.0 Gitblit GO 24
para Microsoft Windows.
A instalação do Gitblit foi realizada a partir da descompactação do arquivo
obtido para o diretório c:Servergitblit-1.4.0, e configuração da porta de
execução do serviço no arquivo datagitblit.properties, que se encontra sob
o diretório de instalação da aplicação. Conforme Quadro 3.
Quadro 3 - Configuração de porta TCP para execução do serviço Gitblit
Também foi criado o diretório base para criação dos repositórios em
c:ServerRepositórios e parametrizado no arquivo de configuração do serviço, de
acordo com Quadro 4.
Quadro 4 - Configuração de diretório base para repositórios
24
http://gitblit.com
48
Para configuração do mecanismo de autenticação do Gitblit com Microsoft
Active Directory, foi configurado o provedor de autenticação para o protocolo
Lightweight Directory Access Protocol (LDAP) de acordo com Quadro 5.
Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit
De forma complementar também foram configurados os parâmetros para
acesso ao do Gitblit ao domínio do Active Directory, indicando o endereço do
servidor, configuração do domínio, usuário para leitura do servidor de domínio no
momento da autenticação, e grupo de usuários administradores da ferramenta
Gitblit. O Quadro 6 mostra as configurações realizadas no arquivo
gitiblit.properties.
Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory
Após estas configurações, foi necessário instalar o serviço do Windows
responsável pela execução do Gitblit, por meio do comando instalService. Este
comando é disponibilizado no diretório de instalação do mesmo, conforme Quadro 7.
49
Quadro 7 - Instalação do serviço Windows para o Gitblit
Posteriormente foi necessário configurar o Gitblit para execução por meio de
serviço do Windows, onde foi necessário executar o aplicativo gitblitw.exe
contido no diretório de instalação do software (neste caso c:Servergitblit-
1.4.0) e indicar ao mesmo o caminho de instalação do Java Runtime Environment
(JRE), conforme Figura 12
Figura 12 - Configuração da máquina virtual Java para o Gitblit
Fonte: Autoria própria.
50
Após estas configurações foi possível iniciar o serviço do Windows e acessar
a interface da ferramenta por meio do endereço http://ip_do_servidor:8181.
3.3.4.3 TortoiseGit
Este é um aplicativo utilizado para cliente do servidor Git, permitindo a
realização de todas as operações necessárias, relacionadas ao controle de versões
no ambiente de desenvolvimento. Para este aplicativo foi utilizada a versão 1.8.7
para 64 bits25
. Este programa foi instalado no lado cliente mantendo as opções
padrão do instalador.
3.3.4.4 TurtleMine
O TurtleMine26
é um plugin para integração do TortoiseGit com as tarefas
existentes no sistema de gerenciamento de projetos Redmine, sendo que para este
trabalho foi utilizado em sua versão 1.2.0.1 para 64 bits. De forma semelhante ao
TortoiseGit, este aplicativo também foi instalado com suas configurações padrão.
3.3.5 Instalação do Redmine
Para preparação do sistema Redmine, optou-se pela utilização do instalador
Bitnami Redmine Stack disponibilizado no site oficial27
em sua versão v2.5.0. Este
instalador é pré-configurado com todo conjunto de infraestrutura necessária para
execução do Redmine, tais como servidor web Apache, linguagem de programação
Ruby com framework Rails e banco de dados MySQL.
25
https://code.google.com/p/tortoisegit
26
https://code.google.com/p/turtlemine/
27
http://bitnami.com/stack/redmine
51
O instalador Bitnami foi executado mantendo-se todas as opções padrão, de
modo que apenas o diretório c:Server foi indicado como destino da instalação.
Após a instalação foi acessada a interface da ferramenta por meio do
endereço http://ip_do_servidor/redmine com as credenciais de
administrador, que foram definidas no momento da instalação da mesma. Realizou-
se então a configuração mecanismo de autenticação a partir do Microsoft Active
Directory conforme Figura 13
Figura 13 - Configuração de para autenticação do Redmine
Fonte: Autoria própria.
Também foi realizada a configuração de uma conta de usuário a ser utilizada
durante as atividades desenvolvidas neste trabalho. Conforme apresentado na
Figura 14.
52
Figura 14 - Configuração de usuário para atividades de desenvolvimento
Fonte: Autoria própria.
3.3.6 Instalação do Jenkins
O servidor de Integração Contínua Jenkins28
foi instalado a partir da obtenção
do pacote nativo para Windows, sendo que versão utilizada neste trabalho foi a
1.532.2 Long-Term Support (LTS), escolhida por ser uma versão de suporte
estendido. Este pacote de instalação foi executado seguido suas opções padrão e
informado apenas o diretório de instalação para C:ServerJenkins.
Com a instalação desta ferramenta concluída, foi inicializado o serviço do
Windows referente à mesma e acessado a interface desta através do endereço
http://ip_do_servidor:8080.
Como em todos os serviços anteriormente mencionados, foi realizada a
configuração do mecanismo de autenticação para que o Jenkins utilize o mecanismo
Microsoft Active Directory para validar senhas de usuário. A Figura 15 apresenta as
configurações efetuadas na seção de “Configuração de Segurança Global” acessada
pelo menu “Gerenciar o Jenkins”.
28
http://jenkins-ci.org/
53
Figura 15 - Configuração de autenticação do Jenkins
Fonte: Autoria própria.
De forma complementar, foi alterado o método de autorização para
“Segurança baseado em matriz” e atribuído todas as permissões ao usuário
“desenv” para que o mesmo opere com administrador da ferramenta. Para usuários
não autenticados foi permitida apenas a visualização dos trabalhos já configurados,
conforme Figura 16.
Figura 16 - Configuração do método de autorização do Jenkins
Fonte: Autoria própria.
54
Foram instalados alguns plugins no Jenkins para viabilizar este trabalho. A
Tabela 2 apresenta a lista de plugins utilizados neste trabalho.
Tabela 2 - Lista de plugins instalados no Jenkins
Nome Descrição
Git Client Plugin Integração com Git
Git Plugin Integração com Git
Downstream Buildview Plugin Permite a visualização de trabalhos dependentes
Redmine Plugin Integração com o Redmine
MSBuild Plugin Suporte para compilação de projetos .Net
MSTest Plugin Execução de testes unitários em .Net
Build Keeper Plugin Bloqueia a deleção de instância de trabalho.
Copy Artifact Plugin Copia artefatos entre projetos
Jenkins Sonar Plugin Integração com SonarQube
Workspace Cleanup Plugin Realiza limpeza do workspace
Fonte: Autoria própria.
Para funcionamento do plugin MSBuild foi configurado na seção “MSBuild” do
painel de gerenciamento de configurações do Jenkins, os parâmetros apresentados
na Tabela 3.
Tabela 3 - Parâmetros para o plugin MSBuild
Parâmetro Valor
MSBuild Name Net Framework 4.5
Path to MSBuild C:WindowsMicrosoft.NETFramework64v4.0.30319MSBuild.exe
Fonte: Autoria própria.
A configuração para utilização da plataforma Java foi feita por meio do item
“JDK”, que está presenta na seção de gerenciamento de configurações do Jenkins.
A Tabela 4 mostra os parâmetros informados.
55
Tabela 4 - Parâmetros para utilização da plataforma Java
Parâmetro Valor
Nome JDK 8
JAVA_HOME C:Serverjdk1.8.0_05_x64
Fonte: Autoria própria.
Para que o Jenkins consiga fazer a integração com Redmine é necessário a
configurações de alguns parâmetros na seção de gerenciamento do Jenkins, item
“Redmine”. A Tabela 5 exibe os parâmetros a serem ajustados.
Tabela 5 - Parâmetros para utilização do Redmine
Parâmetro Valor
Nome Intranet
Base URL http://192.168.118.137/redmine/
Version Number 2.5
Fonte: Autoria própria.
Também foi configurado o plugin do SonarQube. Para isso os parâmetros
apresentados na Tabela 6 foram ajustados na seção de gerenciamento de
configurações do Jenkins, item “Sonnar Runner”:
Tabela 6 - Parâmetros para o plugin SonarQube
Parâmetro Valor
Nome Sonar-Runer-2.3
SONAR_RUNNER_HOME C:Serversonar-runner-2.3
Fonte: Autoria própria.
Para utilização do Maven para compilação de aplicações Java se fez
necessário a configuração referente plugin no item “Maven” na seção de
gerenciamento do Jenkins. A Tabela 7 apresenta esta configuração.
56
Tabela 7 - Parâmetros para o plugin Maven
Parâmetro Valor
Nome Maven-3.2.1
MAVEN_HOME C:Serverapache-maven-3.2.1
Fonte: Autoria própria.
3.3.7 Instalação do SonarQube
O software SonarQube29
foi instalado a partir da obtenção da versão 3.7.4,
que é uma versão Long-Term Support (LTS), também escolhida por ser uma versão
de suporte estendido. O arquivo obtido foi descompactado no diretório
C:Serversonar-3.7.4.
Após este procedimento foi editado o arquivo c:Serversonar-
3.7.4etcwrapper.conf e adicionado a configuração no inicio do arquivo para
indicar o diretório temporário a ser utilizado pelo serviço, conforme Quadro 8. Caso
esta alteração não seja realizada, ocorrerá um erro ao inicializar o serviço, pois o
mesmo tentará criar um diretório temporário dentro de um diretório do sistema.
Quadro 8 - Configuração de diretório temporário para o SonarQube
Também foi instalado o serviço do Windows responsável pela execução do
SonarQube e inicializado o mesmo posteriormente. O Quadro 9 apresenta os
comandos executados para realizar esta atividade.
29
http://www.sonarqube.org/
57
Quadro 9 - Instalação do serviço para o SonarQube e inicialização.
Após realização destes procedimentos a interface do SonarQube pode ser
acessada pelo endereço http://ip_do_servidor:9000.
Para melhor aderência da ferramenta a este trabalho foram utilizados alguns
plugins, os quais estão definidos na Tabela 8.
Tabela 8 - Lista de plugins instalados no SonarQube
Nome Descrição
C# Módulo para linguagem C#
.NET Módulo para plataforma .Net
Java Módulo para suportar linguagem Java
LDAP Módulo para autenticação no Microsoft Active Directory
SCM Activity Módulo para coletar estatísticas do controle de versões
Fonte: Autoria própria.
O Quadro 10 apresenta as configurações efetuadas para que o SonarQube
faça autenticação contra o domínio Active Directory, como as demais ferramentas
utilizadas neste trabalho. Nesta parametrização é indicando o endereço do servidor,
configuração do domínio, usuário para leitura do servidor de domínio no momento da
autenticação. O Quadro 10 mostra as configurações realizadas no arquivo
sonar.properties que está no diretório conf sob o diretório de instalação do
SonarQube.
58
Quadro 10 - Configuração do mecanismo de autenticação do SonarQube
Com estas configurações foi necessário renomear os grupos de usuário
padrão do SonarQube para que fosse possível também a sincronização destes com
o Active Directory. O grupo sonar-administrators passou a se chamar
administradores e o grupo sonar-users passou para usuários.
Para realização da análise do código é necessário também o uso do utilitário
Sonar Runner30
. Neste trabalho foi utilizada a versão 2.4 deste software. Sua
instalação foi realizada por meio da descompactação do arquivo zip no diretório
c:Serversonar-runner-2.4.
Finalmente, a ferramenta está pronta para computar métricas do projeto a
partir do Jenkins.
30
http://docs.codehaus.org/display/SONAR/Installing+and+Configuring+SonarQube+Runner
59
3.3.8 Instalação do Liquibase
Para instalação do Liquibase31
foi necessário apenas obter o arquivo da
versão 3.1.1 e descompactá-lo no diretório c:ServerLiquibase. Esta
ferramenta precisa que haja uma biblioteca Java para conexão ao banco de dados
(driver JDBC – Java Database Connectivity) no subdiretório lib dentro do diretório
de instalação. Para este trabalho foi utilizado o driver MySQL Connector 5.1.3032
para conexão ao banco de dados MySQL SQL Server. Este serviço foi utilizado para
manter compatibilidade da implementação dos protótipos em Java e C#. Qualquer
banco de dados relacional suportado pela plataforma Java poderia ser utilizado.
3.4 CONFIGURAÇÃO DO PROJETO
Esta seção descreve os procedimentos realizados em todas as ferramentas
abordadas para configuração do projeto de sistema realizado neste trabalho.
3.4.1 Criação de Repositório de Código Fonte
Foi acessada a interface do Gitblit, conforme descrito na seção anterior, foram
criados dois repositórios de fontes, sendo um para realizar o controle de versões do
protótipo na plataforma Java e outro para armazenar os códigos do protótipo na
plataforma .Net. A Figura 17 apresenta os repositórios criados no Gitblit.
31
http://www.liquibase.org/download/index.html
32
http://dev.mysql.com/downloads/connector/j/
60
Figura 17 - Repositório para controle de versões dos protótipos
Fonte: Autoria própria.
Com a criação destes repositórios foi feito o clone do mesmo no ambiente
utilizado para desenvolvimento. Sendo necessário acessar o repositório, copiar o
endereço do mesmo conforme Figura 18.
Figura 18 - Novo repositório Git a ser clonado
Fonte: Autoria própria.
Depois de efetuado a cópia do endereço, é necessário acessar a opção “Git
clone” do menu de contexto do Windows a partir de um diretório vazio, conforme
Figura 19.
61
Figura 19 - Opção Git Clone
Fonte: Autoria própria.
A partir da opção citada será apresentada a Figura 20 solicitando a
confirmação para iniciar a execução da cópia do repositório. Neste momento não é
necessário realizar nenhuma alteração das opções disponíveis. Também se pode
observar que o endereço do repositório já foi preenchido automaticamente no devido
campo.
Figura 20 - Confirmação de clone para repositório Git
Fonte: Autoria própria.
Neste momento é necessário confirmar a operação de clone do repositório e
aguardar sua conclusão, momento em que o repositório já estará pronto para
receber os arquivos do projeto de software.
62
3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento
Após a configuração inicial do sistema foram abertos dois projetos no
Redmine, sendo uma para o protótipo na plataforma .Net e outro para o protótipo na
plataforma Java. A Figura 21 apresenta tela de abertura de projeto nesta ferramenta,
para o protótipo para a plataforma .Net.
Figura 21 - Abertura do projeto para o protótipo no Redmine
Fonte: Autoria própria.
Tendo sido aberto o novo projeto, foi adicionado o usuário “desenv” com o
papel de “gerente”. Também foram abertas versões do projeto a serem
desenvolvidas, conforme Tabela 9.
63
Tabela 9 - Tabela de versões criadas para o projeto
Nome Descrição
Versão 1 - Cadastro Versão para entrega dos cadastros básicos
Versão 2 - Lançamento Versão para entrega do lançamento de pedidos
Fonte: Autoria própria.
Para haver a possibilidade de visualização dos códigos fontes do sistema
protótipo a partir do Redmine, foi adicionada ao projeto a parametrização necessária,
nas configurações do projeto por meio da seção denominada “Repositórios”
conforme Figura 22.
Figura 22 - Parametrização de novo repositório de código fonte
Fonte: Autoria própria.
A partir da conclusão destas configurações, foram adicionadas, no Redmine,
as tarefas de desenvolvimento do tipo “Funcionalidade”, que representam os
requisitos, de acordo com Tabela 10.
Tabela 10 - Listagem de tarefas de desenvolvimento
Título Atribuído para Versão
Cadastro de estado Desenvolvedor Versão 1 - Cadastro
Cadastro de cidade Desenvolvedor Versão 1 - Cadastro
Cadastro de produto Desenvolvedor Versão 1 - Cadastro
Cadastro de produto Desenvolvedor Versão 1 - Cadastro
Lançamento de pedidos Desenvolvedor Versão 2 - Lançamento
Fonte: Autoria própria.
64
Após estes procedimentos terem sido concluídos, foi realizada uma cópia
deste projeto, para que fosse possível ter o projeto idêntico para o protótipo a ser
desenvolvido na plataforma Java. Neste procedimento foram necessárias alterações
nos campos destinados à informação do nome do projeto e sua descrição, bem
como na parametrização do repositório de códigos fontes. Estas alterações foram
realizadas apenas para manter a correta referência para o projeto destinado ao
protótipo na plataforma Java.
3.4.3 Configuração de Trabalhos no Jenkins
Foram criados três trabalhos no Jenkins para cada protótipo desenvolvido
sendo um em Java e outro em C#. As seções a seguir descrevem o conteúdo de
cada trabalho.
3.4.3.1 Trabalho para o Ambiente de Desenvolvimento
O primeiro trabalho é executado no ambiente de desenvolvimento quando o
controle de versão notifica uma mudança no código fonte da aplicação e efetua os
seguintes passos:
a. Obtêm-se os códigos fontes do sistema;
b. Realiza-se a compilação dos códigos fontes;
c. Atualizam-se os objetos de banco de dados com o Liquibase;
d. Implanta-se a nova versão do sistema no servidor de desenvolvimento;
e. Coletam-se as métricas do código fonte pelo SonarQube; e
f. Arquivam-se os artefatos para posterior implantação no ambiente de
homologação e produto.
65
Além dos passos citados, o trabalho Jenkins de desenvolvimento também tem
a configuração de uma seção de promoção, onde foi configurada a promoção para
homologação e para produção. Os passos a serem executados neste caso são:
a. Executa-se o trabalho apropriado para a promoção, no caso o segundo
(de homologação) ou terceiro (de produção);
b. Adiciona-se uma tag ou marcação no controle de versões registrando que
a determinada versão do código fonte foi implantada no ambiente de
homologação ou de produção; e
c. Marca-se o build para ser arquivado de forma permanente.
O Apêndice A apresenta a configuração do primeiro trabalho do Jenkins para
o sistema em C# e o Apêndice B apresenta as referentes configurações para o
sistema em Java.
3.4.3.2 Trabalho para o Ambiente de Homologação
O segundo trabalho é executado a partir de uma promoção para homologação
do primeiro trabalho. Neste momento as seguintes etapas são executadas:
a. Obtém-se uma cópia do binário implantado no ambiente de
desenvolvimento, bem como os arquivos Liquibase com o conjunto de
alterações aplicado no banco de dados;
b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de
homologação;
c. Implanta-se a aplicação no servidor de homologação; e
d. Arquivam-se os artefatos utilizados para possível auditoria.
O Apêndice C apresenta a configuração do segundo trabalho do Jenkins para
o sistema em C# e o Apêndice C apresenta as referentes configurações para o
sistema em Java.
66
3.4.3.3 Trabalho para o Ambiente de Produção
O terceiro trabalho é executado a partir de uma promoção para produção do
primeiro trabalho. Neste momento as seguintes etapas são executadas:
a. Obtém-se uma cópia do binário implantado no ambiente de
desenvolvimento, bem como os arquivos Liquibase com o conjunto de
alterações aplicado no banco de dados;
b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de
produção;
c. Implanta-se a aplicação no servidor de produção; e
d. Arquivam-se os artefatos utilizados para possível auditoria.
As configurações do terceiro trabalho do Jenkins não foram anexadas, pois
são baseadas no segundo trabalho e tem os mesmos passos. As alterações
realizadas para criação do terceiro trabalho são apenas no que se refere aos nomes
de servidores, para que os artefatos tenham como destino o servidor de produção.
3.4.3.4 Preparação de Projetos .Net para a Integração Contínua
Para possibilitar a compilação do projeto .Net é necessário ativar a opção
“Enable NuGet Package Restore” na solução .Net, conforme Figura 23:
67
Figura 23 - Ativação da restauração de pacotes NuGet.
Fonte: Autoria própria.
De maneira complementar, é necessário alterar o arquivo “nuget.targets”
que foi criado no diretório “.nuget” para que o parâmetro “DownloadNugetExe”
fique conforme a linha apresentada no Quadro 11.
Quadro 11 - Habilitação de download de executável NuGet.
3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE
Esta seção aborda alguns procedimentos necessários para que as
ferramentas permitam a automação de atividades necessárias para garantir a
rastreabilidade e Integração Contínua.
3.5.1 Seleção de Tarefas do Redmine para Commit no Git
Para a utilização do plugin TurtleMine juntamente com o Redmine, é
necessário efetuar a configuração do mesmo para visualizar as tarefas cadastradas
68
para o projeto. É necessário acessar o Redmine, e copiar o link para visualização da
listagem de tarefas em formato Atom, conforme Figura 24.
Figura 24 - Link para visualização de lista de tarefas em formato Atom
Fonte: Autoria própria.
Tendo copiado o link, é necessário acessar as configurações do TortoiseGit
para o projeto a partir do menu de contexto do Windows, conforme Figura 25.
Figura 25 - Opção de acessar as configurações do TortoiseGit
Fonte: Autoria própria.
69
É necessário selecionar a opção “Issue Tracker Integration”, e adicionar a
integração com Redmine, indicando o diretório onde foi clonado o projeto no campo
“Working Tree Path” o colar o link Atom que foi copiado anteriormente no campo
“Parameters”. No campo “Provider” mantém-se a opção “TurtleMine – 64bit”.
Figura 26 - Configuração do plugin TurtleMine
Fonte: Autoria própria.
A partir da conclusão destas alterações, será disponibilizado um botão na tela
de commit do Tortoise, conforme apresentado na Figura 27, para que seja possível
escolher a tarefa do Redmine que está associada ao mesmo.
70
Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit
Fonte: Autoria própria.
A partir desta opção podemos selecionar as tarefas que estão sendo
atendidas por meio do commit.
Figura 28 - Lista de tarefas apresentadas pelo TurtleMine
Fonte: Autoria própria.
A tarefa selecionada será vinculada ao commit realizado conforme Figura 29.
Isto irá gerar o primeiro vinculo de rastreabilidade que poderá ser visualizado na tela
do Gitblit, do Redmine e do Jenkins, conforme será apresentado no Capítulo 4 deste
trabalho.
71
Figura 29 - Tarefa do Redmine associada ao commit no Git
Fonte: Autoria própria.
3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do
Gitblit
Com o ajuste da configuração do Gitblit demonstrado no Quadro 12 é possível
gerar um link para que na interface do Gitblit para acesso direto a tarefa do Redmine
vinculada ao commit.
Quadro 12 - Configuração de link entre o Gitblit e o Redmine
Desta forma a tela de visualização de commits no Gitblit terá no cabeçalho um
link para a tarefa do Redmine, que é apresentado na Figura 30
72
Figura 30 - Link do Gitblit para o Redmine
Fonte: Autoria própria.
3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do
Redmine
Os procedimentos citados anteriormente garantem a manutenção de uma
ligação entre uma confirmação de alteração de código fonte no controle de versão
com uma atividade do Redmine. No entanto, também é possível gerar a associação
de uma tarefa do Redmine com todos os commits relacionados à mesma. Para
viabilizar isto é necessário configurar quais palavras chaves presentes na
mensagem de commit deverão ser consideradas. Isto deve ser feito por meio do
painel administrativo do sistema Redmine, na seção “Repositórios” no parâmetro
“Palavras-chaves de referencia”, apresentado na Figura 31. Desta forma, todos os
commits contendo qualquer uma destas palavras chaves serão vinculados a
referente tarefa.
73
Figura 31 - Palavras-chaves de referência
Fonte: Autoria própria.
Após estas configurações, todos os envios de alterações realizados para o
servidor terão associação dos commits a cada tarefa mencionada na descrição dos
mesmos. A Figura 32 apresenta o quadro “Revisões associadas” do Redmine
apresenta todas as relações de commit com tarefas do mesmo.
Figura 32 - Revisões associadas a uma tarefa
Fonte: Autoria própria.
74
Este é um dos principais elementos de rastreabilidade gerados neste trabalho,
pois permitirá a rastreabilidade de cada artefato gerado a partir de um determinado
requisito do sistema.
3.5.4 Hook Scripts no Gitblit
O Gitblit permite a utilização de hook script para a execução de atividades
quaisquer no momento em que é feito um envio de commits ao servidor (push).
Neste trabalho foram configurados hook scripts para informar o Redmine que deve
fazer nova leitura do repositório e para inicializar execução de um trabalho no
Jenkins.
Todos os scripts utilizados pelo Gitblit estão sob o diretório “datagroovy”,
dentro do diretório de instalação da ferramenta.
3.5.4.1 Script para Comunicação de Commit ao Redmine
A instalação do Gitblit disponibiliza um hook script com nome redmine-
fetch.groovy , onde podem ser realizadas as configurações para comunicação
com o serviço Redmine. O Quadro 13 mostra os ajustes realizados neste script para
utilização neste trabalho.
Quadro 13 - Configuração do hook script redmine-fetch
O valor da chave de acesso ao Redmine (API-Key) utilizado nesta
configuração precisa ser gerado por meio do painel administrativo do próprio sistema
75
Redmine, na seção “Repositórios” onde se deve marcar as opções apresentadas na
Figura 33 e executar o comando “Gerar uma chave”, conforme a seguir.
Figura 33 - Parâmetros de acesso aos serviços do Redmine
Fonte: Autoria própria.
Para ativar a execução do script é necessário editar o repositório no Gitblit e
marcar o referente hook script como selecionado, de acordo com a Figura 34.
Figura 34 - Seleção de hook script no Gitblit
Fonte: Autoria própria.
Feito estas configurações, as associações mencionadas na seção 3.5.3
estarão sendo concretizadas de forma automática.
76
3.5.4.2 Script para Execução de Trabalhos no Jenkins
Outro hook script disponibilizado pelo Gitblit é o jenkins.groovy, onde
podem ser realizadas as configurações necessárias para que o mesmo acione a
execução de trabalhos do Jenkins. Este script ativará a execução de trabalhos que
estão configurados para utilizar repositórios de código fonte que estão no Gitblit. O
Quadro 14 mostra os ajustes realizados neste script para utilização neste trabalho.
Quadro 14 - Configuração do hook script Jenkins
Para ativar a execução deste script é necessário editar o repositório no Gitblit
e marcar o referente hook script como selecionado, conforme mencionado
anteriormente na Figura 34.
77
4 RESULTADOS E DISCUSSÕES
A apresentação dos resultados obtidos neste trabalho foi organizada em
algumas seções de análise, sendo elas para: Redmine, Gitblit, Jenkins, Liquibase e
SonarQube. De forma complementar existem duas seções que apresentam a
composição da rastreabilidade no processo e a matriz de rastreabilidade de artefatos
e conclusão final.
4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE
Para o objetivo desta pesquisa, a única informação provida pelo Redmine que
foi utilizada para rastreabilidade é a listagem de revisões associadas a cada tarefa,
conforme apresentado na Figura 35. A partir desta listagem é possível obter as
revisões do controle de versão que foram originadas desta tarefa.
Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine
Fonte: Autoria própria.
78
Existe um plugin para o Jenkins, denominado Redmine Plugin33
, que permite
a comunicação do Jenkins diretamente com o Redmine, o que possibilitaria a
geração de informações para ligar estes dois softwares. Contudo, em testes
realizados este recurso não se apresentou em condições de uso, pois após a
realização de configurações o mesmo não realizou as atualizações das tarefas do
Redmine (como esperado), desta forma foi descartado do escopo desta pesquisa.
4.2 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO GITBLIT
A partir do acesso ao repositório de fontes no controle de versões pode-se ter
algumas informações para a rastreabilidade do processo de desenvolvimento.
Dentre elas estão, as etiquetas adicionadas pelo trabalho do Jenkins, as quais
informam qual o dia e hora que foram realizadas promoções de trabalhos para o
ambiente de homologação e produção (item “a” e “b” marcado na Figura 36).
Também é possível visualizar qual tarefa do Redmine está relacionada a cada
confirmação de alteração de código fonte (item “c” marcado na Figura 36).
Figura 36 – Painel de principal do repositório de código fonte
Fonte: Autoria própria.
33
https://wiki.jenkins-ci.org/display/JENKINS/Redmine+Plugin
79
Quando é selecionada uma determinada confirmação de alteração de fontes
para visualização de detalhes, é possível obter outras informações relevantes para a
rastreabilidade do desenvolvimento. A Figura 37 apresenta estas informações e na
sequência são apresentados os significados de cada informação.
Figura 37 - Detalhe de confirmação de alteração no código fonte
Fonte: Autoria própria.
As informações apresentadas na Figura 37 são as seguintes:
a. Etiquetas que indicam data e hora, bem como qual instância de trabalho
do Jenkins utilizou esta revisão do código fonte em uma promoção para
homologação ou produção;
b. Data e hora da confirmação de alteração no repositório de código fonte;
c. Dados do desenvolvedor que confirmou a alteração no repositório;
d. Descrição da mensagem de confirmação da alteração contendo um link
diretor para a tarefa do Redmine mencionada; e
e. Lista de artefatos alterados nesta revisão do controle versões.
80
4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS
O acompanhamento da rastreabilidade do processo de software partindo-se
do produto final entregue pode ser iniciado a partir do Jenkins. Ao acessar a tela
principal deste, pode-se visualizar a listagem de todos os trabalhos configurados no
sistema, conforme Figura 38.
Figura 38 - Tela principal do Jenkins
Fonte: Autoria própria.
Acessando o trabalho principal (neste caso o trabalho “Prototipo”), pode-se
verificar as informações conforme apresentado na Figura 39.
81
Figura 39 - Painel principal de um trabalho Jenkins
Fonte: Autoria própria.
Nesta tela é possível visualizar as seguintes informações:
a. Lista com histórico das construções realizadas com seus referentes
número de identificação, data da realização, e ainda alguns ícones, sendo
que a estrela azul indica que aquela instância do trabalho foi promovida
para homologação, a estrela verde indica que a instância do trabalho foi
promovida para produção, o cadeado informa que os dados arquivados
nesta instância do trabalho não será apagado, e o último ícone azul em
82
formato de meia lua indica que aquela instância do trabalho foi analisada
pelo SonarQube.
b. Conjunto de links para os artefatos arquivados na última construção. Tais
artefatos podem ser resgatados novamente para fins de auditoria.
c. Link para listagem de alterações de código fonte que estão contidas na
última instância do trabalho Jenkins executado.
d. Lista de projetos filhos que serão executados a partir do trabalho Jenkins
atual.
e. Link para o endereço do projeto Redmine relacionado ao trabalho
Jenkins.
f. Listagem de promoções do trabalho atual. Permite verificar data e hora
que houve as promoções do trabalho Jenkins para os ambientes de
homologação e produção.
g. Link para acessar as métricas do software referenciado no trabalho
Jenkins atual.
Ao selecionar uma instância de trabalho do Jenkins será apresentada a tela,
conforme Figura 40, com detalhes daquela construção.
Figura 40 - Detalhe de uma construção do Jenkins
Fonte: Autoria própria.
83
Na Figura 40 foram destacadas algumas áreas da tela, conforme segue:
a. Artefatos gerados ou utilizados na construção que foram arquivados para
gerar evidências e possibilitar auditoria;
b. Lista de confirmações de alterações de fontes que foram enviadas ao
controle de versões e que acionaram e execução do trabalho Jenkins,
com links para visualização de detalhes das mesmas, tarefa do Redmine
relacionada e visualização de detalhes diretamente no sistema de
controle de versões Gitblit;
c. Indicativo de que a instância do trabalho atual foi acionada a partir de uma
alteração no controle de versões;
d. Informação sobre qual foi a revisão do controle de versões utilizada para
este instância do trabalho;
e. Links para acessar a listagem de todas as confirmações de alterações no
controle de versão, bem como seus detalhes;
f. Apresentação das saídas de linha de comando que foram geradas a partir
da execução da instância atual do trabalho do Jenkins;
g. Link para acessar a relação de trabalhos dependentes (neste caso
trabalho de Homologação e Produção). Também são apresentados seus
status de execução e, caso já tenham sido executado, a data e hora de
execução e seu referente status; e
h. Lista de promoções executadas para a instância atual do trabalho
Jenkins.
4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE
Com a execução do conjunto de alterações configuradas para execução do
Liquibase (Apêndices E, F, G, H, I e J), o trabalho configurado no Jenkins
sincronizou os objetos de banco de dados e gerou algumas informações relevantes
para a auditoria de alterações no banco de dados.
84
Todas as alterações realizadas pelo Liquibase são registradas em uma tabela
do banco de dados nomeada DATABASECHANGELOG. Estas informações são
apresentadas na Figura 41.
Figura 41 - Registro de alterações do banco de dados
Fonte: Autoria própria.
Como informações relevantes para auditoria das alterações de banco de
dados têm-se:
a. Autor de cada alteração;
b. Arquivo utilizado como base para realizar a alteração;
c. Data e hora de execução de cada alteração;
d. Ordem de execução de cada arquivo;
e. Descrição resumida dos tipos de alterações realizadas; e
f. O comentário inserido no arquivo de alterações do banco de dados.
Tendo como base a data e hora da execução é possível saber qual foi o
trabalho do Jenkins que acionou esta alteração, e posterior auditoria dos arquivos
que originaram as mesmas. Com estas informações também é possível rastrear a
versão do sistema que foi implantada gerando determinada alteração no banco de
dados.
4.5 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO SONARQUBE
As informações providas pelo SonarQube não colaboram diretamente para a
obtenção da rastreabilidade de artefatos no processo de desenvolvimento de
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software
Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software

Mais conteúdo relacionado

Destaque

Estrutura de Dados em Java (Revisão de Algoritimos em Java)
Estrutura de Dados em Java (Revisão de Algoritimos em Java)Estrutura de Dados em Java (Revisão de Algoritimos em Java)
Estrutura de Dados em Java (Revisão de Algoritimos em Java)Adriano Teixeira de Souza
 
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)Adriano Teixeira de Souza
 
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...Adriano Teixeira de Souza
 
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)Adriano Teixeira de Souza
 
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)Adriano Teixeira de Souza
 
Estrutura de dados em Java - Filas com lista encadeada
Estrutura de dados em Java - Filas com lista encadeada Estrutura de dados em Java - Filas com lista encadeada
Estrutura de dados em Java - Filas com lista encadeada Adriano Teixeira de Souza
 
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMSSistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMSAdriano Teixeira de Souza
 
Estrutura de Dados em Java (Funções e Procedimentos)
Estrutura de Dados em Java (Funções e Procedimentos)Estrutura de Dados em Java (Funções e Procedimentos)
Estrutura de Dados em Java (Funções e Procedimentos)Adriano Teixeira de Souza
 
Estrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisEstrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisFabrício Lopes Sanchez
 
Estrutura de dados em Java - Ponteiros e Alocação de Memória
Estrutura de dados em Java - Ponteiros e Alocação de Memória Estrutura de dados em Java - Ponteiros e Alocação de Memória
Estrutura de dados em Java - Ponteiros e Alocação de Memória Adriano Teixeira de Souza
 
Curso Básico de Java - Aula 7
Curso Básico de Java - Aula 7Curso Básico de Java - Aula 7
Curso Básico de Java - Aula 7PeslPinguim
 

Destaque (20)

Estrutura de Dados em Java (Revisão de Algoritimos em Java)
Estrutura de Dados em Java (Revisão de Algoritimos em Java)Estrutura de Dados em Java (Revisão de Algoritimos em Java)
Estrutura de Dados em Java (Revisão de Algoritimos em Java)
 
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)
Estrutura de Dados em Java (Variáveis Compostas - Vetores e Matrizes)
 
Estrutura de Dados em Java (Introdução)
Estrutura de Dados em Java (Introdução)Estrutura de Dados em Java (Introdução)
Estrutura de Dados em Java (Introdução)
 
Estrutura de dados em Java - Recursividade
Estrutura de dados em Java - RecursividadeEstrutura de dados em Java - Recursividade
Estrutura de dados em Java - Recursividade
 
Estrutura de dados em Java - Pilhas
Estrutura de dados em Java - PilhasEstrutura de dados em Java - Pilhas
Estrutura de dados em Java - Pilhas
 
Estrutura de dados em Java - Filas
Estrutura de dados em Java - FilasEstrutura de dados em Java - Filas
Estrutura de dados em Java - Filas
 
Estrutura de dados - Árvores Binárias
Estrutura de dados - Árvores BináriasEstrutura de dados - Árvores Binárias
Estrutura de dados - Árvores Binárias
 
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...
Ferramentas para desenvolvimento web com produtividade - Artigo Final - Pos-G...
 
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)
Estrutura de Dados em Java (Introdução à Programação Orientada a Objetos)
 
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)
Sistemas Distribuídos - Comunicação Distribuída - EJB (JBoss 7)
 
Estrutura de dados em Java - Filas com lista encadeada
Estrutura de dados em Java - Filas com lista encadeada Estrutura de dados em Java - Filas com lista encadeada
Estrutura de dados em Java - Filas com lista encadeada
 
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMSSistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS
Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS
 
Estrutura de Dados em Java (Funções e Procedimentos)
Estrutura de Dados em Java (Funções e Procedimentos)Estrutura de Dados em Java (Funções e Procedimentos)
Estrutura de Dados em Java (Funções e Procedimentos)
 
Estrutura de dados em Java - Filas
Estrutura de dados em Java - Filas Estrutura de dados em Java - Filas
Estrutura de dados em Java - Filas
 
Recursividade
RecursividadeRecursividade
Recursividade
 
Estruturas de dados
Estruturas de dadosEstruturas de dados
Estruturas de dados
 
Estrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisEstrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentais
 
Estrutura de dados em Java - Ponteiros e Alocação de Memória
Estrutura de dados em Java - Ponteiros e Alocação de Memória Estrutura de dados em Java - Ponteiros e Alocação de Memória
Estrutura de dados em Java - Ponteiros e Alocação de Memória
 
Slide teixeira e souza
Slide teixeira e souzaSlide teixeira e souza
Slide teixeira e souza
 
Curso Básico de Java - Aula 7
Curso Básico de Java - Aula 7Curso Básico de Java - Aula 7
Curso Básico de Java - Aula 7
 

Semelhante a Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software

UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...antonio sérgio nogueira
 
Trabalho de Conclusão de Curso de Graduação
Trabalho de Conclusão de Curso de GraduaçãoTrabalho de Conclusão de Curso de Graduação
Trabalho de Conclusão de Curso de GraduaçãoDaniel Fernando Pigatto
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...JADSON SANTOS
 
Usabilidade e Arquitetura de Informação de Websites de Governos Municipais
Usabilidade e Arquitetura de Informação de Websites de Governos MunicipaisUsabilidade e Arquitetura de Informação de Websites de Governos Municipais
Usabilidade e Arquitetura de Informação de Websites de Governos MunicipaisMarcelo Ramos
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfJoelManuel8
 
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOSMÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOSLeno Matos Lisboa
 
Monografia - Qualidade Afetiva de Elementos Visuais
Monografia - Qualidade Afetiva de Elementos VisuaisMonografia - Qualidade Afetiva de Elementos Visuais
Monografia - Qualidade Afetiva de Elementos VisuaisMarcelo Henrique
 
Gestao contexto qos_qoe
Gestao contexto qos_qoeGestao contexto qos_qoe
Gestao contexto qos_qoeIP10
 
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-Raboni Santos
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...Paulo Steinhauser
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...Paulo Steinhauser
 
O impacto da engenharia social na segurança da informaçao
O impacto da engenharia social na segurança da informaçaoO impacto da engenharia social na segurança da informaçao
O impacto da engenharia social na segurança da informaçaoSoftD Abreu
 
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃO
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃOO IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃO
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃOSoftD Abreu
 
Viabilidade em cluster de alto desempenho
Viabilidade em cluster de alto desempenhoViabilidade em cluster de alto desempenho
Viabilidade em cluster de alto desempenhoRogério Cardoso
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...Marcelo Dieder
 
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...Felipe Nascimento
 
DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216Valter Inacio Jr.
 
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...Leonardo Sepulcri
 
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...Ramon Santos
 

Semelhante a Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software (20)

UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWAR...
 
Trabalho de Conclusão de Curso de Graduação
Trabalho de Conclusão de Curso de GraduaçãoTrabalho de Conclusão de Curso de Graduação
Trabalho de Conclusão de Curso de Graduação
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
 
Usabilidade e Arquitetura de Informação de Websites de Governos Municipais
Usabilidade e Arquitetura de Informação de Websites de Governos MunicipaisUsabilidade e Arquitetura de Informação de Websites de Governos Municipais
Usabilidade e Arquitetura de Informação de Websites de Governos Municipais
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdf
 
Projeto de graduação
Projeto de graduaçãoProjeto de graduação
Projeto de graduação
 
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOSMÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
 
Monografia - Qualidade Afetiva de Elementos Visuais
Monografia - Qualidade Afetiva de Elementos VisuaisMonografia - Qualidade Afetiva de Elementos Visuais
Monografia - Qualidade Afetiva de Elementos Visuais
 
Gestao contexto qos_qoe
Gestao contexto qos_qoeGestao contexto qos_qoe
Gestao contexto qos_qoe
 
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-
Desenvolvimento seguro-de-aplicações-web-seguindo-a-metodologia-owasp-
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
 
O impacto da engenharia social na segurança da informaçao
O impacto da engenharia social na segurança da informaçaoO impacto da engenharia social na segurança da informaçao
O impacto da engenharia social na segurança da informaçao
 
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃO
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃOO IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃO
O IMPACTO DA ENGENHARIA SOCIAL NA SEGURANÇA DA INFORMAÇÃO
 
Viabilidade em cluster de alto desempenho
Viabilidade em cluster de alto desempenhoViabilidade em cluster de alto desempenho
Viabilidade em cluster de alto desempenho
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
 
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
 
DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216
 
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...
COMPREENDENDO A COMPUTAÇÃO AUTONÔMICA NO AMBIENTE DE TECNOLOGIA DA INFORMAÇÃO...
 
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...
TCC: Avaliação de Dependabilidade e Análise de Sensibilidade de uma Plataform...
 

Mais de Adriano Teixeira de Souza

Paradigmas de Linguagens de Programação - Gerenciamento de Memória em Java
Paradigmas de Linguagens de Programação - Gerenciamento de Memória em JavaParadigmas de Linguagens de Programação - Gerenciamento de Memória em Java
Paradigmas de Linguagens de Programação - Gerenciamento de Memória em JavaAdriano Teixeira de Souza
 
Ferramentas para desenvolvimento web com produtividade - Slide Artigo (2009)
Ferramentas para desenvolvimento web com produtividade -  Slide Artigo (2009)Ferramentas para desenvolvimento web com produtividade -  Slide Artigo (2009)
Ferramentas para desenvolvimento web com produtividade - Slide Artigo (2009)Adriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks Adriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Modularização, componentização e re...
Paradigmas de Linguagens de Programação - Modularização, componentização e re...Paradigmas de Linguagens de Programação - Modularização, componentização e re...
Paradigmas de Linguagens de Programação - Modularização, componentização e re...Adriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Tratamento de Exceções
Paradigmas de Linguagens de Programação - Tratamento de ExceçõesParadigmas de Linguagens de Programação - Tratamento de Exceções
Paradigmas de Linguagens de Programação - Tratamento de ExceçõesAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Estruturas de Controle
Paradigmas de Linguagens de Programação - Estruturas de ControleParadigmas de Linguagens de Programação - Estruturas de Controle
Paradigmas de Linguagens de Programação - Estruturas de ControleAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Expressões e Instruções de Atribuição
Paradigmas de Linguagens de Programação - Expressões e Instruções de AtribuiçãoParadigmas de Linguagens de Programação - Expressões e Instruções de Atribuição
Paradigmas de Linguagens de Programação - Expressões e Instruções de AtribuiçãoAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Tipos primitivos e compostos
Paradigmas de Linguagens de Programação - Tipos primitivos e compostosParadigmas de Linguagens de Programação - Tipos primitivos e compostos
Paradigmas de Linguagens de Programação - Tipos primitivos e compostosAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Tipos Abstratos de Dados
Paradigmas de Linguagens de Programação - Tipos Abstratos de DadosParadigmas de Linguagens de Programação - Tipos Abstratos de Dados
Paradigmas de Linguagens de Programação - Tipos Abstratos de DadosAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Escopo estático/dinâmico
Paradigmas de Linguagens de Programação - Escopo estático/dinâmicoParadigmas de Linguagens de Programação - Escopo estático/dinâmico
Paradigmas de Linguagens de Programação - Escopo estático/dinâmicoAdriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...Adriano Teixeira de Souza
 
Paradigmas de Linguagens de Programação - Classificações
Paradigmas de Linguagens de Programação - ClassificaçõesParadigmas de Linguagens de Programação - Classificações
Paradigmas de Linguagens de Programação - ClassificaçõesAdriano Teixeira de Souza
 
Estrutura de dados - Introdução a linguagem C
Estrutura de dados - Introdução a linguagem CEstrutura de dados - Introdução a linguagem C
Estrutura de dados - Introdução a linguagem CAdriano Teixeira de Souza
 

Mais de Adriano Teixeira de Souza (14)

Responsive web design
Responsive web designResponsive web design
Responsive web design
 
Paradigmas de Linguagens de Programação - Gerenciamento de Memória em Java
Paradigmas de Linguagens de Programação - Gerenciamento de Memória em JavaParadigmas de Linguagens de Programação - Gerenciamento de Memória em Java
Paradigmas de Linguagens de Programação - Gerenciamento de Memória em Java
 
Ferramentas para desenvolvimento web com produtividade - Slide Artigo (2009)
Ferramentas para desenvolvimento web com produtividade -  Slide Artigo (2009)Ferramentas para desenvolvimento web com produtividade -  Slide Artigo (2009)
Ferramentas para desenvolvimento web com produtividade - Slide Artigo (2009)
 
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks
Paradigmas de Linguagens de Programação - Biblioteca de Classes e Frameworks
 
Paradigmas de Linguagens de Programação - Modularização, componentização e re...
Paradigmas de Linguagens de Programação - Modularização, componentização e re...Paradigmas de Linguagens de Programação - Modularização, componentização e re...
Paradigmas de Linguagens de Programação - Modularização, componentização e re...
 
Paradigmas de Linguagens de Programação - Tratamento de Exceções
Paradigmas de Linguagens de Programação - Tratamento de ExceçõesParadigmas de Linguagens de Programação - Tratamento de Exceções
Paradigmas de Linguagens de Programação - Tratamento de Exceções
 
Paradigmas de Linguagens de Programação - Estruturas de Controle
Paradigmas de Linguagens de Programação - Estruturas de ControleParadigmas de Linguagens de Programação - Estruturas de Controle
Paradigmas de Linguagens de Programação - Estruturas de Controle
 
Paradigmas de Linguagens de Programação - Expressões e Instruções de Atribuição
Paradigmas de Linguagens de Programação - Expressões e Instruções de AtribuiçãoParadigmas de Linguagens de Programação - Expressões e Instruções de Atribuição
Paradigmas de Linguagens de Programação - Expressões e Instruções de Atribuição
 
Paradigmas de Linguagens de Programação - Tipos primitivos e compostos
Paradigmas de Linguagens de Programação - Tipos primitivos e compostosParadigmas de Linguagens de Programação - Tipos primitivos e compostos
Paradigmas de Linguagens de Programação - Tipos primitivos e compostos
 
Paradigmas de Linguagens de Programação - Tipos Abstratos de Dados
Paradigmas de Linguagens de Programação - Tipos Abstratos de DadosParadigmas de Linguagens de Programação - Tipos Abstratos de Dados
Paradigmas de Linguagens de Programação - Tipos Abstratos de Dados
 
Paradigmas de Linguagens de Programação - Escopo estático/dinâmico
Paradigmas de Linguagens de Programação - Escopo estático/dinâmicoParadigmas de Linguagens de Programação - Escopo estático/dinâmico
Paradigmas de Linguagens de Programação - Escopo estático/dinâmico
 
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...
Paradigmas de Linguagens de Programação - Quatro Paradigmas + Ambientes de Pr...
 
Paradigmas de Linguagens de Programação - Classificações
Paradigmas de Linguagens de Programação - ClassificaçõesParadigmas de Linguagens de Programação - Classificações
Paradigmas de Linguagens de Programação - Classificações
 
Estrutura de dados - Introdução a linguagem C
Estrutura de dados - Introdução a linguagem CEstrutura de dados - Introdução a linguagem C
Estrutura de dados - Introdução a linguagem C
 

Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software

  • 1. UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE ADRIANO TEIXEIRA DE SOUZA APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE SOFTWARE MONOGRAFIA DE ESPECIALIZAÇÃO MEDIANEIRA 2014
  • 2. ADRIANO TEIXEIRA DE SOUZA APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE SOFTWARE Monografia apresentada como requisito parcial à obtenção do título de Especialista na Pós Graduação em Engenharia de Software, da Universidade Tecnológica Federal do Paraná – UTFPR – Câmpus Medianeira. Orientador: Prof. MSc. Wesley Klewerton Guez Assunção. Co-Orientador: Prof. MSc. Cristiano Marcos Lunkes MEDIANEIRA 2014
  • 3. Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Graduação e Educação Profissional Especialização em Engenharia de Software TERMO DE APROVAÇÃO APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE SOFTWARE Por Adriano Teixeira de Souza Esta monografia foi apresentada às 10:10 h do dia 07 de Agosto de 2014 como requisito parcial para a obtenção do título de Especialista no curso de Engenharia de Software, da Universidade Tecnológica Federal do Paraná, Câmpus Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado. ______________________________________ Prof. MSc. Wesley Klewerton Guez Assunção UTFPR – Câmpus Toledo (orientador) ____________________________________ Prof. Esp. Márcio Angelo Matté UTFPR – Câmpus Medianeira _________________________________________ Prof. Dr. Pedro Luiz de Paula Filho UTFPR – Câmpus Medianeira
  • 4. Dedico a todos que estiveram ao meu lado nesta etapa de aprendizado.
  • 5. AGRADECIMENTOS Agradeço a Deus por estar concluindo mais este passo para a construção do conhecimento e por ter me conduzido com segurança nas constantes viagens até a cidade de Medianeira. Agradeço a minha querida esposa Keila Couto dos Santos por estar sempre junto a mim e pelo grande esforço também empenhado nesta caminhada. Agradeço ao grande amigo e Mestre Wesley Klewerton Guez Assunção pela orientação e apoio na elaboração deste material, bem como pelo tempo dispensado para acompanhar de perto este trabalho. Agradeço de forma muito singela ao ilustríssimo Mestre Cristiano Marcos Lunkes, excelentíssima pessoa e de coração muito humilde, pela disposição em acompanhar este trabalho e pelo esforço empenhado para estar na cidade de Medianeira colaborando nesta jornada. Agradeço ao Mestre Alan Gavioli por ter trabalhado pela oferta deste curso e pelo grande zelo com o mesmo. Agradeço a todos os professores que contribuíram para o aprendizado durante o decorrer deste curso. Agradeço aos colegas de turma pela prazerosa companhia e troca de experiência nestes inúmeros sábados.
  • 6. “A percepção do desconhecido é a mais fascinante das experiências. O homem que não tem os olhos abertos para o misterioso passará pela vida sem ver nada”. (ALBERT EINSTEIN)
  • 7. RESUMO SOUZA, Adriano Teixeira de. APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE SOFTWARE. 2014. 103f. Monografia (Especialização em Engenharia de Software). Universidade Tecnológica Federal do Paraná, Medianeira, 2014. Este trabalho tem por objetivo apresentar as contribuições que as técnicas de Integração Contínua podem agregar ao processo de gerenciamento de configuração de software. As técnicas avaliadas neste trabalho visam dar subsídios para rastreabilidade de relacionamentos entre requisitos, artefatos e produto final durante o ciclo de vida de um software. Para isso, é apresentada a revisão de literatura sobre temas relacionados, ferramentas que viabilizam a aplicação destas técnicas e elaborado um protótipo para demonstração da aplicação das mesmas. E finalmente, são analisadas as informações providas pelas ferramentas e elaborado uma matriz de rastreabilidade de artefatos de software. Palavras-chave: Gerenciamento de Configuração, Controle de Versões, Manutenção, Gerenciamento de Projetos.
  • 8. ABSTRACT SOUZA, Adriano Teixeira de. APPLICATION OF CONTINUOUS INTEGRATION TO ENABLE THE TRACEABILITY OF ARTIFACTS DURING SOFTWARE MAINTENANCE. 2014. 103f. Monograph (Lato Sensu Postgraduate on Software Engineering). Technological Federal University of Paraná, Medianeira-Brazil, 2014. This work has a goal of presenting the contribution that the Continuous Integration technics can aggregate on the software configuration management process. The evaluated technics on this work aim give subsidies to relationship traceability between requirements, artifacts and end product during the software lifecycle. For this, is presented the literature revision about the related subjects, tools to make possible the application of this technics and prototype development to show the applying of them. Finally, are analyzed the information provided by the tools and elaborated one matrix of traceability of software artifacts. Keywords: Configuration Management, Version Control, Maintaining, Project Management.
  • 9. LISTA DE FIGURAS Figura 1 - Sistema de controle de versões distribuído ..............................................28 Figura 2 - Intercomunicação entre serviços...............................................................32 Figura 3 - Diagrama de classes do sistema de pedidos de venda ............................34 Figura 4 - Diagrama de caso de uso do sistema de pedidos de venda.....................35 Figura 5 - Diagrama de classes do sistema de pedidos de venda ............................35 Figura 6 - Domínio Microsoft Active Directory ...........................................................37 Figura 7 - Variável de ambiente JAVA_HOME..........................................................38 Figura 8 - Variável de ambiente Path com JDK.........................................................39 Figura 9 - Instalação do Microsoft Information Services............................................44 Figura 10 - Configuração do application pool para o site padrão ..............................45 Figura 11 - Variável de ambiente Path......................................................................46 Figura 12 - Configuração da máquina virtual Java para o Gitblit...............................49 Figura 13 - Configuração de para autenticação do Redmine ....................................51 Figura 14 - Configuração de usuário para atividades de desenvolvimento ...............52 Figura 15 - Configuração de autenticação do Jenkins ..............................................53 Figura 16 - Configuração do método de autorização do Jenkins ..............................53 Figura 17 - Repositório para controle de versões dos protótipos ..............................60 Figura 18 - Novo repositório Git a ser clonado..........................................................60 Figura 19 - Opção Git Clone......................................................................................61 Figura 20 - Confirmação de clone para repositório Git..............................................61 Figura 21 - Abertura do projeto para o protótipo no Redmine ...................................62 Figura 22 - Parametrização de novo repositório de código fonte ..............................63 Figura 23 - Ativação da restauração de pacotes NuGet............................................67 Figura 24 - Link para visualização de lista de tarefas em formato Atom ...................68 Figura 25 - Opção de acessar as configurações do TortoiseGit................................68 Figura 26 - Configuração do plugin TurtleMine .........................................................69 Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit...................................70 Figura 28 - Lista de tarefas apresentadas pelo TurtleMine .......................................70 Figura 29 - Tarefa do Redmine associada ao commit no Git ....................................71 Figura 30 - Link do Gitblit para o Redmine................................................................72 Figura 31 - Palavras-chaves de referência................................................................73 Figura 32 - Revisões associadas a uma tarefa .........................................................73 Figura 33 - Parâmetros de acesso aos serviços do Redmine ...................................75 Figura 34 - Seleção de hook script no Gitblit.............................................................75 Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine ...77 Figura 36 – Painel de principal do repositório de código fonte..................................78 Figura 37 - Detalhe de confirmação de alteração no código fonte ............................79 Figura 38 - Tela principal do Jenkins.........................................................................80 Figura 39 - Painel principal de um trabalho Jenkins..................................................81 Figura 40 - Detalhe de uma construção do Jenkins ..................................................82
  • 10. Figura 41 - Registro de alterações do banco de dados.............................................84 Figura 42 - Tela principal de um projeto no SonarQube............................................85 Figura 43 - Tela hotspot do SonarQube ....................................................................86 Figura 44 - Visualização detalhada de violações no SonarQube ..............................86
  • 11. LISTA DE QUADROS Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly.......................41 Quadro 2 - Configuração inicial do Wildfly.................................................................41 Quadro 3 - Configuração de porta TCP para execução do serviço Gitblit.................47 Quadro 4 - Configuração de diretório base para repositórios....................................47 Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit ...............48 Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory..................48 Quadro 7 - Instalação do serviço Windows para o Gitblit..........................................49 Quadro 8 - Configuração de diretório temporário para o SonarQube........................56 Quadro 9 - Instalação do serviço para o SonarQube e inicialização.........................57 Quadro 10 - Configuração do mecanismo de autenticação do SonarQube ..............58 Quadro 11 - Habilitação de download de executável NuGet.....................................67 Quadro 12 - Configuração de link entre o Gitblit e o Redmine ..................................71 Quadro 13 - Configuração do hook script redmine-fetch...........................................74 Quadro 14 - Configuração do hook script Jenkins.....................................................76 Quadro 15 - Matriz de rastreabilidade de artefatos ...................................................87
  • 12. LISTA DE TABELAS Tabela 1 - Usuários cadastrados no Active Directory................................................37 Tabela 2 - Lista de plugins instalados no Jenkins .....................................................54 Tabela 3 - Parâmetros para o plugin MSBuild...........................................................54 Tabela 4 - Parâmetros para utilização da plataforma Java .......................................55 Tabela 5 - Parâmetros para utilização do Redmine ..................................................55 Tabela 6 - Parâmetros para o plugin SonarQube......................................................55 Tabela 7 - Parâmetros para o plugin Maven .............................................................56 Tabela 8 - Lista de plugins instalados no SonarQube...............................................57 Tabela 9 - Tabela de versões criadas para o projeto ................................................63 Tabela 10 - Listagem de tarefas de desenvolvimento ...............................................63
  • 13. LISTA DE SIGLAS API Application Programming Interface CMMI Capability Maturity Model Integration IDE Integrated Development Environment JDBC Java Database Connectivity JDK Java Development Kit JRE Java Runtime Environment LDAP Lightweight Directory Access Protocol LTS Long Term Support MPS.BR Melhoria de Processo do Software Brasileiro SCM Software configuration management SQL Structured Query Language TCP/IP Transmission Control Protocol / Internet Protocol XML eXtensible Markup Language
  • 14. SUMÁRIO 1 INTRODUÇÃO .......................................................................................................16 1.1 OBJETIVO GERAL .............................................................................................17 1.2 OBJETIVOS ESPECÍFICOS ...............................................................................17 1.3 JUSTIFICATIVA ..................................................................................................17 2 FUNDAMENTAÇÃO TEÓRICA..............................................................................20 2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE ....20 2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE .............................21 2.3 A INTEGRAÇÃO CONTÍNUA..............................................................................22 2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO SOFTWARE..............................................................................................................25 3 MATERIAL E MÉTODOS.......................................................................................26 3.1 FERRAMENTAS .................................................................................................26 3.1.1 Linguagem de Programação ............................................................................26 3.1.1.1 Java..............................................................................................................27 3.1.1.2 C#.................................................................................................................27 3.1.2 Git.....................................................................................................................28 3.1.3 Jenkins .............................................................................................................29 3.1.4 Redmine...........................................................................................................30 3.1.5 SonarQube.......................................................................................................30 3.1.6 Liquibase..........................................................................................................31 3.2 METODOLOGIA..................................................................................................31 3.2.1 Cenário de Integração Contínua ......................................................................31 3.2.2 Configuração do Ambiente para Desenvolvimento ..........................................33 3.2.3 Construção do Protótipo...................................................................................34 3.3 INSTALAÇÃO DAS FERRAMENTAS .................................................................36 3.3.1 Sistema Operacional Windows.........................................................................36 3.3.2 Instalação da Plataforma Java .........................................................................37 3.3.2.1 Kit de Desenvolvimento Java .......................................................................38 3.3.2.2 Instalação da Ferramenta de Automação de Compilação............................39 3.3.2.3 Servidor de Aplicações.................................................................................40 3.3.2.4 Ambiente de Desenvolvimento .....................................................................41
  • 15. 3.3.3 Instalação da Plataforma .Net ..........................................................................42 3.3.3.1 Framework .Net ............................................................................................43 3.3.3.2 Ambiente de Desenvolvimento .....................................................................43 3.3.3.3 Preparação para a Integração Contínua.......................................................43 3.3.3.4 Servidor de Aplicações.................................................................................44 3.3.4 Instalação do Sistema Controle de Versões Git...............................................45 3.3.4.1 Git.................................................................................................................46 3.3.4.2 Gitblit ............................................................................................................47 3.3.4.3 TortoiseGit....................................................................................................50 3.3.4.4 TurtleMine.....................................................................................................50 3.3.5 Instalação do Redmine.....................................................................................50 3.3.6 Instalação do Jenkins.......................................................................................52 3.3.7 Instalação do SonarQube.................................................................................56 3.3.8 Instalação do Liquibase....................................................................................59 3.4 CONFIGURAÇÃO DO PROJETO.......................................................................59 3.4.1 Criação de Repositório de Código Fonte..........................................................59 3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento .................................62 3.4.3 Configuração de Trabalhos no Jenkins ............................................................64 3.4.3.1 Trabalho para o Ambiente de Desenvolvimento...........................................64 3.4.3.2 Trabalho para o Ambiente de Homologação ................................................65 3.4.3.3 Trabalho para o Ambiente de Produção.......................................................66 3.4.3.4 Preparação de Projetos .Net para a Integração Contínua ............................66 3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE ..........................67 3.5.1 Seleção de Tarefas do Redmine para Commit no Git ......................................67 3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do Gitblit ........................................................................................................................71 3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do Redmine....................................................................................................................72 3.5.4 Hook Scripts no Gitblit......................................................................................74 3.5.4.1 Script para Comunicação de Commit ao Redmine.......................................74 3.5.4.2 Script para Execução de Trabalhos no Jenkins............................................76 4 RESULTADOS E DISCUSSÕES ...........................................................................77 4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE..........................77 4.2 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO GITBLIT.............................78
  • 16. 4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS ...........................80 4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE .......................83 4.5 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO SONARQUBE ...................84 4.6 MATRIZ DE RASTREABILIDADE.......................................................................87 5 CONCLUSÃO.........................................................................................................89 5.1 CONSIDERAÇÕES FINAIS ................................................................................89 5.2 TRABALHOS FUTUROS ....................................................................................90 REFERÊNCIAS.........................................................................................................91 APÊNDICE A - TRABALHO DO JENKINS (.NET DESENV).....................................93 APÊNDICE B - TRABALHO DO JENKINS (JAVA DESENV)....................................94 APÊNDICE C – TRABALHO DO JENKINS (.NET HOMOLOGAÇÃO) .....................95 APÊNDICE D - TRABALHO DO JENKINS (JAVA HOMOLOGAÇÃO) .....................96 APÊNDICE E – ARQUIVO LIQUIBASE PARA TABELA DE ESTADO .....................97 APÊNDICE F – ARQUIVO LIQUIBASE PARA TABELA DE CIDADE.......................98 APÊNDICE G - ARQUIVO LIQUIBASE PARA TABELA DE PRODUTOS ................99 APÊNDICE H - ARQUIVO LIQUIBASE PARA TABELA DE PARCEIROS .............100 APÊNDICE I – ARQUIVO LIQUIBASE PARA TABELA DE PEDIDO......................101 APÊNDICE J – ARQUIVO LIQUIBASE INICIALIZAÇÃO DA EXECUÇÃO .............102
  • 17. 16 1 INTRODUÇÃO A manutenção e evolução dos produtos de software se fazem necessárias para muitas organizações, pois estes elementos sustentam a base operacional e estratégica das mesmas. Conforme SOMMERVILLE (2011), altos investimentos são realizados e as organizações se tornam cada vez mais dependentes de sistemas computacionais. Mesmo havendo o reconhecimento da necessidade de uma abordagem profissional para a condução de projetos de software, muitos profissionais o fazem sem prévio conhecimento de métodos e técnicas apropriadas. De acordo com PRESSMAN (2011), nestas condições gera-se um produto final de baixa qualidade e fadado a um curto tempo de vida. O mesmo autor (PRESSMAN, 2011) enfatiza que durante o ciclo de vida de grandes projetos, alterações não controladas podem minar a reputação do software. É necessário utilizar procedimentos humanos e ferramentas automatizadas a fim de garantir o bom andamento do processo. Para FARLEY e HUMBLE (2014), todo processo que puder ser automatizado deverá ser. A automatização possibilita repetibilidade, testabilidade, garantia de execução de todas as etapas de um procedimento. Considerando o exposto, neste trabalho são exploradas ferramentas e técnicas para gerenciamento de configuração de software aliadas a automatização proporcionada pela Integração Contínua. Com isso obtém-se a rastreabilidade de artefatos de software durante o ciclo de vida do produto. Desta forma, é possível aferir quais tipos de artefatos podem ser relacionados com um requisito, uma liberação de versão que está implantada, ou até mesmo quando e porque surgiu um determinado artefato que se encontra no produto. Os resultados obtidos são apresentados por meio de matriz de referência cruzada informando qual o nível de rastreabilidade poderá se obter a partir de um determinado artefato do processo de desenvolvimento e manutenção do software.
  • 18. 17 1.1 OBJETIVO GERAL Aplicação da Integração Contínua para viabilizar a rastreabilidade de artefatos durante a manutenção de software. 1.2 OBJETIVOS ESPECÍFICOS Para atingir o objetivo geral os seguintes objetivos específicos são propostos: a. Revisar de literatura sobre técnicas de Integração Contínua e Gerenciamento de Configuração de Software; b. Identificar técnicas que favorecem a obtenção da rastreabilidade de artefatos. c. Avaliar técnicas existentes para aplicação da Integração Contínua. d. Verificar ferramentas de controle de versão, Integração Contínua, gerenciamento de projetos, que possibilitem a aplicação das técnicas avaliadas. e. Elaborar uma aplicação experimental e configurar um ambiente integrado para gerenciamento do ciclo de vida de aplicações, que serão utilizados para verificação e aplicação das técnicas avaliadas. 1.3 JUSTIFICATIVA Durante o ciclo de vida de um software há muitas mudanças de funcionalidades, alterações de artefatos, adição de componentes, etc. Tais manutenções provêm de mudanças nos requisitos de negócios, que serviram de base para a concepção do produto, mudanças no ambiente onde o software está sendo utilizado, adequações à legislação, ou até mesmo uma simples refatoração de código. A manutenção do software é de suma importância para que o mesmo tenha
  • 19. 18 longo tempo de utilização. Entretanto, todos os eventos de desenvolvimento ou manutenção do software devem ser registrados por meio de procedimento e técnicas abordados pela Gerência de Configuração. A Gerência de Configuração orienta o processo de desenvolvimento de software para que seja possível identificar requisitos iniciais do sistema, registrar os defeitos encontrados no produto bem como suas alterações ao longo de seu tempo de vida. A Gerência de Configuração recomenda também o uso de ferramentas para que seja possível ter o registro histórico de todas as alterações que ocorreram no código fonte do software (SOMMERVILLE, 2011). As ferramentas comumente utilizadas são sistemas de registro de bugs ou solicitações de desenvolvimento e sistema de controle de versões de código fonte. Estes tipos de ferramentas já estão difundidos no cenário de desenvolvimento de software, contudo a abordagem da Gerência de Configuração vai além da utilização destas. De acordo com SOMMERVILLE (2011), para a utilização eficiente das técnicas de Gerência de Configuração é necessário: a. Existir o registro de todas as requisições de mudanças em uma ferramenta apropriada; b. Ter a utilização de um mecanismo de controle de versões e não utilizá-lo apenas como um repositório de arquivos, mas também registrar etiquetas para marcar versões de produto, criar linhas de desenvolvimento conhecidas com branch quando houver necessidade de implementações ou correções em diferentes versões do software; e c. Utilização de um sistema de compilação e construção automatizado que consiga agregar código-fonte, bibliotecas e executar testes. É importante ressaltar que PRESSMAN (2011) trás algumas características importantes que o Gerenciamento de Configuração deve possibilitar, dentre elas estão: a. Controle de Requisitos – possibilita rastrear qual requisito gerou determinado artefato do produto; e b. Pistas de auditoria – trás informações que permite identificar quando, por quem e por que alterações foram feitas no software.
  • 20. 19 Para que o Gerenciamento de Configuração aconteça com eficiência pode-se utilizar técnicas de Integração Contínua. A Integração Contínua preza pela automação do processo de construção do software, testes e implantação, durante a confirmação de alteração do programa no sistema de controle de versões (FOWLER, 2006). A utilização de uma ferramenta para aplicação de técnicas de Integração Contínua é de fundamental importância. Com a automação de procedimentos pode- se montar um fluxo de trabalho para implantação do software que se inicia na integração da manutenção dos diversos desenvolvedores até a implantação final em ambiente produtivo. Sendo assim, não há intervenção manual na compilação ou disponibilização do software em ambiente produtivo, o que dá a garantia de um nível elevado de auditoria do processo de desenvolvimento ou até mesmo de repetições ou testes do mesmo (SMART, 2011).
  • 21. 20 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo tem como objetivo apresentar os principais conceitos e técnicas básicas para o entendimento do trabalho desenvolvido. São abordados aspectos relacionados ao processo de desenvolvimento de software, gerenciamento da configuração, Integração Contínua, e finalmente a rastreabilidade de artefatos de software. 2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE Durante o ciclo de vida de um software, diversas atividades são executadas para que seja possível efetuar a construção do produto. São elencados e especificados os requisitos, é elaborado projeto de banco de dados, arquitetura e interface, posteriormente é desenvolvido o produto, os testes são efetuados e finalmente ocorre a homologação do mesmo. Ao final destas atividades são realizados os ajustes necessários a partir do feedback obtido e liberado o produto para uso (SOMMERVILLE, 2011). Uma vez concluído o processo de desenvolvimento do software e o produto liberado para uso surgem necessidade de mudanças. As mudanças pode ser em requisitos, novas tecnologias, necessidade de novos recursos ou mesmo para correção de defeitos (PRESSMAN, 2011). De modo complementar, SOMMERVILE (2011) apresenta a evolução do software como fator importante, pois as empresas despendem grandes volumes financeiros nestes e existe grande dependência dos mesmos para realização de suas atividades. Fatores internos à equipe de desenvolvimento também podem gerar manutenção do software. O processo de refatoração apresentado por FOWLER (2004) propõe alterações do sistema sem que haja alteração do comportamento do mesmo. Estas modificações podem ser efetuadas visando eliminar redundância ou elementos não utilizados, melhorar a eficiência de algoritmos, adequar estrutura de dados, reduzir o acoplamento e aumentar a coesão.
  • 22. 21 2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE De acordo com PRESSMAN (2011) os processos de gerência de configuração visam identificar e controlar alterações do software, garantir que trabalhos de manutenção do produto sejam implementados corretamente, e prover informações sobre as alterações a quem houver interesse. A gestão da configuração se baseia em um conjunto de atividades que visam dar rastreabilidade e controle dos trabalhos realizados durante o ciclo de vida do software. SOMMERVILE (2011) apresenta quatro grandes atividades que resumem o processo de gerenciamento de configuração, as quais são: a. Gerenciamento de mudanças – diz respeito ao acompanhamento de requisições de mudanças e avaliação de custo, impacto, como e quando efetuar tal mudança; b. Gerenciamento de versões – garantir a manutenção das diversas revisões dos componentes para que haja o histórico de mudanças e trabalho de diferentes desenvolvedores de forma distribuída e paralela sem interferência mutua; c. Construção do sistema – diz respeito à resolução de dependências1 de artefatos e componentes externos a fim de gerar o sistema executável; e d. Gerenciamento de releases – Preparar o software para disponibilizá-lo ao cliente e manter o histórico de versões liberadas anteriormente. Para haver um bom processo de Gerenciamento de Configuração é necessário validar três itens básicos. Primeiramente, permitir identificar rapidamente qual a versão exata dos artefatos que são implantados em produção. Consequentemente deve ser possível recuperar facilmente a versão exata dos artefatos que estão em produção. De forma complementar também é necessário que haja possiblidades de se efetuar pequenas correções na versão dos artefatos que estão em produção, compilar novamente esta versão corrigida e implantar a mesma (AIELLO e SACHS, 2011). 1 Agregar artefatos necessários para a construção do software, tais como biblioteca de código.
  • 23. 22 Além disso, um processo de gerenciamento de configuração bem definido e aplicado é requisito para obtenção de certificações de qualidade, tais como CMMI e MPS.BR. Segundo SOFTEX (2013), o processo gerenciamento de configuração é importante para o desenvolvimento de software, pois permite que haja o controle sobre o que é desenvolvido e alterado. A necessidade deste processo é definida em seu Guia de Fundamentação para Implementação do Nível F, o segundo nível em sua escala de níveis de maturidade, que se inicia com o nível G com o tema de Gerenciamento de Processos e Requisitos e segue até o nível A, que possui foco na otimização do processo. Para CMMI (2014), o Gerenciamento da Configuração deve: a. Garantir a seleção de item de trabalho para cada versão do software a ser desenvolvida; b. Controlar as alterações nos documentos que guiam o desenvolvimento; e c. Prover status e dados sobre a configuração do software para desenvolvedores, usuários finais e clientes. O guia CMMI for Development em sua versão 1.3 também apresenta que um dos propósitos fundamentais do Gerenciamento da Configuração é a auditoria da configuração. 2.3 A INTEGRAÇÃO CONTÍNUA Conforme FOWLER (2006), o processo de Integração Contínua é baseado em um conjunto de práticas que visam agilizar o processo de implantação, diminuir a quantidade de defeitos no sistema ou o mesmo diminuir o tempo de permanência de um defeito no sistema. Dentre estas práticas podem ser destacadas: a. Automatização de build – envolve a automatização do agrupamento de artefatos, resolução de dependência, atualização de banco de dados e compilação do software. Esta automatização previne a ocorrência de
  • 24. 23 erros neste processo, proporciona um processo testável e que pode ser repetido. b. Build auto testável - apresenta a inclusão de testes automatizados como elemento fundamental para validação e verificação do software, indo além da compilação e chegando a verificar se cada funcionalidade foi desenvolvida conforme especificado. Com isso é possível obter maior segurança na implantação. c. Commits frequentes – é de fundamental importância que os membros da equipe de desenvolvimento enviem suas alterações para o sistema de controle de versões em um curto intervalo de tempo. É recomendável que isso seja feito em um período máximo de um dia. Esta prática favorece a localização rápida de defeitos decorrente da integração do trabalho de diversos desenvolvedores. d. Cada commit deve atualizar o repositório em um servidor de integração – o serviço de Integração Contínua monitora o repositório do software e inicia a construção automatizada sempre que uma alteração do código fonte for enviada ao repositório e emite notificação em caso de falha na construção. e. Todos devem ver o que está acontecendo – em um processo de Integração Contínua é importante que toda a equipe possa obter facilmente o estado do build e as mudanças que foram realizadas no sistema. É recomentado que o servidor de Integração Contínua possa apresentar tais informações por meio de um site que possa ser visualizado de forma facilitada. f. Automatização da implantação do sistema – para maior efetividade do processo é necessário que os procedimentos de implantação do software sejam automatizados de forma que permita sua execução em diversos servidores, tais como ambiente de teste, homologação ou produção. Com isso é minimizado o tempo de implantação e a incidência de erros. De acordo com DUVALL, MATYAS e MATYAS (2007), a Integração Contínua tem como alguns dos principais fundamentos: redução de riscos, redução de processos manuais repetitivos e permitir melhor visibilidade do projeto.
  • 25. 24 A redução de riscos pode ser obtida devido à integração frequente do código, o que possibilita a detecção prévia de defeitos mediante a inspeção automatizada do código, pode-se obter informações de complexidade deste código a cada alteração, também é possível coletar dados referentes à aderência a padrões de codificação, cobertura de testes e duplicação de código. Devido à execução da construção do software no servidor de Integração Contínua é possível prevenir que o sistema mantenha referencias para elementos como artefatos e variáveis de ambiente exclusivas do contexto do desenvolvedor. Com a automatização de processos repetitivos como recuperação de código a partir de um sistema de controle de versões, compilação, atualização de base de dados, teste, inspeção, implantação e criação de uma etiqueta (tag) no sistema de controle de versões, é possível que o processo seja executado toda vez que o código for alterado e sempre com os mesmos passos e da mesma forma. Deste modo as pessoas podem manter o foco em trabalhos de alto valor agregado. Outro ponto importante é que o processo de build seja construído de tal forma que possa ser executado a partir de um único comando. Um serviço para Integração Contínua pode prover informações em tempo real sobre status da construção, métricas de qualidade e defeitos. Também é possível manter informações de tendências bem como outras informações por meio de plugins. De forma complementar FARLEY e HUMBLE (2014) observam que não é necessário somente ter um processo de construção e implantação automatizado, mas é importante que o mesmo abra a possibilidade de reverter uma implantação sem sucesso. Caso contrário o ambiente produtivo será penalizado caso haja algum imprevisto, seja por motivo de depuração de uma aplicação no ambiente ou mesmo pela permanência do defeito. No entanto, é de suma importância observar relações de dependência entre sistemas integrados, ou mesmo os impactos da implantação no banco de dados, pois procedimentos de reversão da implantação podem ter limitações relevantes.
  • 26. 25 2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO SOFTWARE Conforme EDWARDS e HOWELL (1991), uma lista de requisitos corretos e consistentes não garantem que o produto de software final estará de acordo com as expectativas dos stakeholders. É necessário que o projeto do produto esteja alinhado aos requisitos e posteriormente à implementação esteja coerente com o que se espera. Com um processo provido de rastreabilidade é possível identificar incoerências entre estas fases do desenvolvimento de software ou até mesmo evidenciar a mudança de um requisito após o mesmo ter sido desenvolvimento no produto. A rastreabilidade de artefatos dá condições de auditoria de todas as características de um sistema e saber que alterações foram efetuadas a partir de uma requisição de mudança do produto. Ter um processo com rastreabilidade possibilita saber qual requisito gerou uma determinada característica do sistema, qual a origem de tal requisito, verificar se o projeto e a implementação foram executados corretamente (HAMILTON e BEEBY, 1991). Podem-se obter recursos de rastreabilidade no processo de desenvolvimento de software de duas formas. Uma é a geração de links diretos na aplicação de gerenciamento de configuração, de forma que seja possível, a partir de cliques, navegar de um requisito para um registro de alteração no controle de versões, saber qual foi o requisito que está associado a um conjunto de alterações de artefatos, ou mesmo a partir do registro de uma construção do software visualizar as alterações de código que estão contidas no mesmo. Outra forma é a obtenção de tais informações por meio de relatórios e matrizes de relacionamento, dentre outros (EDWARDS e HOWELL, 1991). FARLEY e HUMBLE (2014) ressaltam ainda, a importância fundamental de que o processo de Gerenciamento de Configuração possibilite que se consiga saber, a partir de um binário em execução, qual a revisão no controle de versões deu origem ao mesmo, de forma que, havendo a necessidade de correção de um software que esteja em produção, seja possível fazê-la sem dispêndio de grande esforço para obter o código fonte correspondente.
  • 27. 26 3 MATERIAL E MÉTODOS Este capítulo apresenta as ferramentas que são utilizadas para aplicação dos conceitos e técnicas, bem como a metodologia abordada neste trabalho. O capítulo está dividido em cinco seções, sendo que a primeira expõe as ferramentas e a segunda a metodologia utilizada, na terceira parte é apresentada a instalação destas ferramentas, posteriormente a configuração inicial da mesma e finaliza com algumas configurações adicionais para prover a rastreabilidade. 3.1 FERRAMENTAS As ferramentas empregadas na abordagem prática deste trabalho são: linguagens de programação Java e C#, sistema de controle de versão Git, servidor de Integração Contínua Jenkins, gerenciador de projetos Redmine, plataforma para gerenciamento de qualidade do código SonarQube, e Liquibase para controle de versão de elementos de banco de dados. Tais ferramentas são apresentadas a seguir. 3.1.1 Linguagem de Programação A pesquisa realizada neste trabalho tem como base as linguagens de programação Java2 e C#3 . São duas das linguagens de programação mais utilizadas profissionalmente, segundo o Índice TIOBE4 de 2014. De forma complementar MOMBREA (2014), salienta que tais linguagens de programação são as mais relevantes para desenvolvimento de sistemas em ambiente corporativo, e também proporciona maior facilidade para o aprendizado de outras linguagens. 2 http://www.oracle.com/br/technologies/java/overview/index.html 3 http://msdn.microsoft.com/pt-br/library/67ef8sbd.aspx 4 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
  • 28. 27 3.1.1.1 Java Conforme FLANAGAN (2005), Java é uma linguagem orientada a objeto com sintaxe similar a C. É uma linguagem de implementação híbrida, ou seja, quando um código fonte é compilado, ele é convertido em byte codes que são códigos binários portáveis para qualquer arquitetura de hardware que possua uma máquina virtual Java para interpretá-los. Quando o Java é instalado para desenvolvimento de aplicações, o mesmo disponibiliza um conjunto básico de classes APIs (Application Programming Interface) para entrada/saída de dados, comunicação em rede, componentes de interface gráfica, dentre outros que juntos formam a plataforma Java (FLANAGAN, 2005). Como linguagem de programação, Java foi projetada para que desenvolvedores escrevam programas robustos com facilidade (FLANAGAN, 2005). 3.1.1.2 C# A linguagem de programação C# é orientada a objetos, possui sintaxe simples, é considerada moderna e é semelhante a C++ ou Java. Esta linguagem também tem por objetivo fornecer base para construção de aplicações robustas e com longo tempo de vida (HEJLSBERG et al, 2011). De acordo com HEJLSBERG et al (2011), C# também trabalha pelo modo de implementação híbrido, ou seja, sua compilação gera um código intermediário denominado .NET Common Language Interface, que é interpretado pelo .NET Common Language Runtime.
  • 29. 28 3.1.2 Git Como ferramenta open source para controle de versão, optou-se pelo Git5 , conforme recomendado por FOWLER (2010). Devido a sua característica de ser distribuído permite uma utilização mais eficiente no acesso a logs históricos. Não é necessário requisição ao repositório principal para toda consulta de log, pois todos tem uma cópia completa do repositório consigo. O Git também favorece a segurança, pois um novo membro que se junta à equipe pode trabalhar a partir de um repositório de um desenvolvedor sênior da equipe de modo que este valide seus desenvolvimentos e envia ao repositório central. Git é um sistema de controle de versões distribuído, ou seja, todo check out do repositório se torna uma cópia completa do repositório principal e pode ser compartilhada com outros desenvolvedores. Conforme CHACON (2009), este modelo de trabalho permite que diversas equipes possam trabalhar simultaneamente no mesmo projeto. A Figura 1 possibilita o melhor entendimento do modelo. Figura 1 - Sistema de controle de versões distribuído Fonte: CHACON (2009) 5 http://git-scm.com/
  • 30. 29 De acordo com CHACON (2009) o Git também possui uma forma de execução de eventos que são disparados em alguns momentos quando são realizados procedimentos nesta ferramenta. Estes eventos executam scripts que podem ser customizados e são denominados hook scripts. Existem scripts que podem ser executados quando ocorrem eventos no ambiente cliente, tais como checar se uma mensagem de confirmação de alteração no código fonte foi escrita de acordo com o padrão definido para o repositório. Também existem scripts que podem ser executados no lado do servidor, antes ou depois do mesmo processar um recebimento de alterações do código fonte. Estes scripts do lado do servidor podem ser utilizados para acionar atividades de Integração Contínua a cada alteração no repositório principal. 3.1.3 Jenkins Para aplicação da Integração Contínua, foi escolhido o Jenkins6 , que é uma ferramenta open source, derivada do Hudson e escrita em Java. É uma ferramenta utilizada por equipes de vários tamanhos e em projeto que fazem uso de diversas tecnologias e linguagens de programação (SMART, 2011). O Jenkins se propõe a ser fácil de usar, tem uma interface simples e intuitiva. Esta ferramenta possui uma ampla comunidade, que desenvolve, adiciona novas características e corrige bugs rapidamente, gerando novas versões constantemente. No entanto para usuários e empresas que não são afetos a ciclos curtos de atualizações, o Jenkins mantem um versão Long-Term Support (LTS) que garante um tempo maior de vida para uma determinada versão, para a qual é disponibilizada correções por um tempo diferenciado da versão padrão (SMART, 2011). 6 http://jenkins-ci.org/
  • 31. 30 3.1.4 Redmine Para gerenciamento de projetos optou-se pelo Redmine7 , que é uma ferramenta open source escrita em Ruby on Rails. Esta ferramenta possui uma variedade de recursos para auxiliar na condução de projetos, tais como: controle de perfis de acesso, gráfico de Gantt, calendário, planejamento de versões e tarefas necessárias para liberação destas, integração com sistema de controle de versões, gerenciamento de documentos e notícias (LESYUK, 2013). O Redmine também possui uma API de integração que permite à outras ferramentas desenvolver plugins de integração para registrar suas atividades. 3.1.5 SonarQube SonarQube8 é uma ferramenta open source que foi escolhido para apresentar relatórios da qualidade do código. Trabalhando em conjunto com uma ferramenta de Integração Contínua, pode-se conseguir grande melhora na qualidade do código. Esta ferramenta aponta problemas de aderência a padrões de codificação inseridos pelos desenvolvedores, cobertura de testes, duplicações de código, documentação no código (como Javadoc), complexidade ciclomática, provendo análises de evolução destas métricas (CAMPBELL e PAPAPETROU, 2014). As informações registradas possibilitam um acompanhamento temporal da evolução da qualidade do software e auditar quem e quando realizou alterações que interferiram na qualidade da codificação. 7 http://www.redmine.org/ 8 http://www.sonarqube.org/
  • 32. 31 3.1.6 Liquibase Finalmente, foi utilizada a ferramenta open source Liquibase9 para dar suporte ao versionamento de elementos do banco de dados. Esta ferramenta permite armazenar todas as alterações em arquivo XML (eXtensible Markup Language), fazer atualização de itens de banco de dados, bem como retroceder a um estado anterior dos mesmos. O Liquibase possibilita a geração de arquivo com a diferença de objetos entre dois bancos de dados, gerar um arquivo com objetos de um banco de dados existente para ser transportado para outro ambiente, ou simplesmente para gerar uma posição inicial de versionamento. Com o Liquibase é possível realizar a alteração do banco de dados a partir da utilização de Ant, Maven, Servlet ou mesmo linha de comando. Esta ferramenta trabalha com mais de dez sistemas gerenciadores de banco de dados, dentre os quais estão: Oracle, Microsoft SQL Server e MySQL. 3.2 METODOLOGIA A apresentação da metodologia utilizada está dividida em três seções, sendo que a primeira trata do cenário de integração continua utilizada, a configuração do ambiente para validação e finalmente a construção do protótipo. 3.2.1 Cenário de Integração Contínua Além do sistema utilizado como protótipo foi montado um cenário de Integração Contínua com um servidor para gerenciamento do ciclo de vida de aplicações. Neste servidor foram instaladas as ferramentas a serem avaliadas: Git, 9 http://www.liquibase.org/
  • 33. 32 Liquibase, Jenkins, Redmine, SonarQube, Java e .Net. A Figura 2 ilustra as comunicações entre os sistemas para Integração Contínua. Figura 2 - Intercomunicação entre serviços Fonte: Autoria própria. A Figura 2 apresenta as seguintes atividades de processo de desenvolvimento: a. Inicialmente ocorre à construção do software na máquina do desenvolvedor e o este utiliza um conjunto de bibliotecas de código disponibilizadas para desenvolvimento; b. Cada biblioteca utilizada na construção do software é obtida a partir de um repositório, e é utilizado um recurso de resolução de dependências apropriado para a tecnologia, que pode ser Maven10 para o ambiente Java ou NuGet11 para .Net; 10 http://maven.apache.org/ 11 https://www.nuget.org/
  • 34. 33 c. Após ter desenvolvido os requisitos e realizado uma construção com sucesso, o desenvolvedor confirma as alterações no serviço repositório de fontes, onde é realizado o controle de versões; d. O repositório de fontes notifica o servidor de Integração Contínua de que houve uma mudança no código fonte; e. É iniciado um trabalho no servidor de Integração Contínua que obtém os códigos do programa, efetua a construção com resolução de dependências no mesmo mecanismo utilizado pelo desenvolvedor anteriormente; f. Na sequência é feito atualização dos objetos do banco de dados para a última versão por meio do Liquibase; g. Depois é processada a análise para coleta de métricas pelo SonarQube, onde se obtém dados como: cumprimento de padrões de codificação, comentários e documentação de código, complexidade ciclomática, dentre outros; e h. Finalmente, caso seja necessário, é realizada a implantação do software no devido servidor de aplicação que lhe for conveniente. 3.2.2 Configuração do Ambiente para Desenvolvimento Após a configuração das ferramentas, foram realizados os seguintes procedimentos: a. Abertura de projeto no sistema de gerenciamento de projetos Redmine; b. Registro de requisitos e atividades de desenvolvimento no sistema de gerenciamento de projetos; c. Associação de tarefas de desenvolvimento aos membros da equipe; d. Abertura de um projeto no sistema de controle de versões Git; e. Criação do fluxo de trabalho para implantação do software, no Jenkins, com atividades a serem realizadas no momento da disponibilização do software em ambiente de desenvolvimento, ambiente de qualificação (homologação) e ambiente produtivo;
  • 35. 34 f. Desenvolvimento do software protótipo (apresentado na seção 3.2.3) e utilização do sistema de versionamento de software; g. Realização de alterações no software e confirmação das alterações no controle de versão; Os resultados destas etapas contribuirão para rastreabilidade do processo de desenvolvimento, conforme apresentado no Capítulo 4 deste trabalho. 3.2.3 Construção do Protótipo Para demonstrar a metodologia deste trabalho, é utilizado um exemplo ilustrativo de um sistema simples de pedidos. O sistema possui apenas uma tela de pedidos de venda e seus cadastros correlatos, conforme especificação apresentada a seguir. A Figura 3 apresenta o diagrama das classes de entidades a utilizadas no desenvolvimento do protótipo. A representação dos métodos foi omitida para possibilitar o melhor entendimento do modelo. Figura 3 - Diagrama de classes do sistema de pedidos de venda Fonte: Autoria própria.
  • 36. 35 Este software tem apenas um caso de uso que representa o lançamento de pedidos de venda. O diagrama apresentado na Figura 4 representa este caso de uso. Figura 4 - Diagrama de caso de uso do sistema de pedidos de venda Fonte: Autoria própria. A Figura 5 traz o diagrama de sequência que demonstra o fluxo de ações e respostas do software. Este diagrama trás inicialmente a preparação inicial do pedido a partir dos dados de cliente e data de vencimento. Posteriormente é realizada a inserção dos itens com suas referentes quantidade do pedido. Finalmente é apresentada a operação “salvar” que realiza a gravação do pedido e informa o numero do mesmo para o usuário. Figura 5 - Diagrama de sequencia do sistema de pedidos de venda Fonte: Autoria própria.
  • 37. 36 3.3 INSTALAÇÃO DAS FERRAMENTAS O conteúdo desta seção mostra informações relevantes sobre a instalação e configuração do conjunto de ferramentas, sendo elas: o sistema operacional Windows, plataforma de desenvolvimento, sistema de controle de versões Git, sistema para gerenciamento de projetos Redmine, sistema para métricas de software SonarQube, e sistema para Integração Contínua Jenkins. 3.3.1 Sistema Operacional Windows A instalação das ferramentas é realizada em servidor com sistema operacional Microsoft Windows 2008 R2 com arquitetura de 64 bits executando em uma máquina virtual na plataforma VMware Workstation. Esta máquina virtual possui dois núcleos de processamento, contém 1,5 gigabytes de memória e executa sob o endereço IP 192.168.118.137. O sistema operacional Windows foi utilizado para possibilitar a demonstração das ferramentas tanto para plataforma Java quando para Microsoft .Net. Para equipes dedicadas exclusivamente a plataforma Java, todas as ferramentas de base poderiam ser instaladas em sistema operacional Linux. Neste servidor, foi configurado o Microsoft Active Directory para gerenciar autenticações de forma centralizada para todas as ferramentas utilizadas neste trabalho, favorecendo desta forma a rastreabilidade. O domínio configurado é apresentado na Figura 6, conforme a seguir:
  • 38. 37 Figura 6 - Domínio Microsoft Active Directory Fonte: Autoria própria. Neste domínio foram criados dois usuários e dois grupos, conforme apresentado na Tabela 1. Tabela 1 - Usuários cadastrados no Active Directory Nome Descrição Grupo aplicacao Utilizado para autenticar usuários no domínio Active Directory usuarios desenv Utilizado para simular operações de desenvolvimento usuarios, administradores Fonte: Autoria própria. 3.3.2 Instalação da Plataforma Java A preparação do ambiente para execução da plataforma Java foi segmentado em três etapas, sendo elas: a. Instalação do kit de desenvolvimento; b. Instalação da ferramenta para automação de compilação c. Instalação do servidor de aplicações; e d. Instalação da ferramenta de desenvolvimento.
  • 39. 38 As três primeiras foram executadas no ambiente de desenvolvimento e no servidor, a quarta etapa foi executada apenas no ambiente de desenvolvimento. Tais etapas são descritas a seguir. 3.3.2.1 Kit de Desenvolvimento Java Para execução dos procedimentos deste trabalho optou-se pela última versão estável, para arquitetura de 64 bits, do ambiente de desenvolvimento Java também conhecida com Java Development Kit (JDK) que é a JDK 7u5112 . O instalador foi executado seguindo as configurações padrão, tendo apenas o diretório de instalação modificado para C:Serverjdk1.7.0_51_x64. Depois de finalizada a execução do instalador, foi criada uma variável de ambiente do Windows, chamada JAVA_HOME, a qual teve como conteúdo o diretório da instalação da JDK, conforme Figura 7. Figura 7 - Variável de ambiente JAVA_HOME Fonte: Autoria própria. 12 http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html
  • 40. 39 De forma complementar também foi adicionado o endereço %JAVA_HOME%bin à variável de ambiente Path, conforme Figura 8. Figura 8 - Variável de ambiente Path com JDK Fonte: Autoria própria. 3.3.2.2 Instalação da Ferramenta de Automação de Compilação A ferramenta Maven foi utilizada para automatizar o processo de compilação da aplicação Java. O instalador desta aplicação foi obtido no endereço web oficial13 e sua instalação foi realizada por meio da descompactação do arquivo no diretório C:Serverapache-maven-3.2.1. De forma complementar também foi necessário a criação de uma variável de ambiente denominada M2_HOME, cujo valor é o caminho do diretório de instalação da ferramenta. Para finalizar a instalação do Maven foi adicionado o valor %M2_HOME%bin à variável de ambiente PATH. Os procedimentos para a criação destas variáveis foram omitidos, pois são similares aos apresentados na seção 3.3.2.1. 13 http://maven.apache.org/download.cgi
  • 41. 40 3.3.2.3 Servidor de Aplicações Também foi instalado o software Wildfly para ser utilizado como servidor de aplicações Java Enterprise Edition. Este software é o sucessor do JBoss14 , que assim era chamado até a versão 7. O mesmo foi obtido através do site do desenvolvedor15 e sua instalação foi realizada por meio da descompactação do arquivo no diretório C:Serverwildfly-8.0.0.Final. A utilização de outro servidor de aplicação poderia ser feita sem impactos no resultado da pesquisa. Todavia deve-se observar que os comandos de implantação da aplicação e o plugin necessário no ambiente de desenvolvimento seriam diferentes. Três configurações adicionais foram necessárias para que o Wildfly estivesse executando de forma plena: a. Alteração de endereço e porta TCP/IP para execução; b. Adição de usuário para funções administrativas; c. Instalação do serviço Windows para inicialização do servidor. O Quadro 1 apresenta a alteração realizada no arquivo de configuração do Wildfly “standalonecondigurationstandalone.xml”, sob o diretório de instalação do Wildfly. 14 http://jbossas.jboss.org/ 15 http://wildfly.org/downloads/
  • 42. 41 Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly O Quadro 2 apresenta a execução dos comandos necessários para a realização destas configurações. Quadro 2 - Configuração inicial do Wildfly 3.3.2.4 Ambiente de Desenvolvimento Para ambiente de desenvolvimento na plataforma Java optou-se pela ferramenta open source Eclipse IDE for Java EE Developers, sendo que foi utilizada
  • 43. 42 a versão 4.3.2 obtida no endereço oficial16 . Para instalação da mesma foi apenas descompactado o arquivo obtido em uma pasta local denominada c:javaeclipse. Qualquer outra ferramenta poderia ter sido utilizada sem impactar o resultado do processo de desenvolvimento. Foi necessária também a instalação do plugin JBoss Tools17 para integração do ambiente de desenvolvimento com o servidor de aplicações Wildfly. Para instalação deste plugin foi acessado o menu “Help” do Eclipse e acessado a opção “Eclipse Market Place”. Nesta tela foi realizado a busca pelas palavras “JBoss Tools” e selecionado a opção de instalação para o item “JBoss Tools (Kepler) 4.1.2 Final”. 3.3.3 Instalação da Plataforma .Net A preparação do ambiente para execução de aplicações .Net foi divida em quatro etapas, sendo elas: a. Instalação framework .Net; b. Instalação do ambiente de desenvolvimento; c. Preparação para integração contínua; e d. Instalação do servidor de aplicações. As etapas “a” e “b” foram no ambiente de desenvolvimento e no lado do servidor foram executadas todas as etapas, com exceção do item “b”. 16 https://www.eclipse.org/downloads/ 17 http://tools.jboss.org/
  • 44. 43 3.3.3.1 Framework .Net Para esta plataforma que é base para a linguagem C#, foi obtido o instalador do Microsoft .Net Framework 4.518 . Os procedimentos de instalação seguiram configurações padrão sugeridas pelo próprio instalador. 3.3.3.2 Ambiente de Desenvolvimento A instalação do ambiente de desenvolvimento foi realizada a partir da mídia da versão Visual Studio Professional 2012 obtida a partir do site Microsoft DreamSpark for Academic Institutions. Sua instalação seguiu com todas as configurações padrão. 3.3.3.3 Preparação para a Integração Contínua Para realizar a compilação do projeto no servidor foi necessário instalar o Windows Software Development Kit for Windows 819 e o Microsoft Visual Studio Express 2012 for Web20 . O processo de compilação necessita de algumas bibliotecas e referências que são próprias da ferramenta de desenvolvimento e não são instaladas com o framework .Net. Ambas as ferramentas foram instaladas a partir de suas opções padrão. No ambiente do servidor também foi necessário realizar a instalação do Microsoft Web Deploy v3.521 para possibilitar a automação de implantação de aplicações no servidor web Internet Information Services. Este utilitário foi instalado com uso de suas configurações padrão. 18 http://www.microsoft.com/pt-br/download/details.aspx?id=40779 19 http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx 20 http://www.microsoft.com/en-us/download/details.aspx?id=30669
  • 45. 44 3.3.3.4 Servidor de Aplicações Para possibilitar a execução da aplicação em ASP.Net no servidor, também foi preciso instalar o servidor Internet Information Services. Para isso foi necessário acessar a opção “Server Manager” (Gerenciador do Servidor) a partir do menu de ferramentas administrativas do Windows e adicionar o papel (role) de Web Server ao servidor Windows, marcando as opções apropriadas para ASP.Net, de acordo com a Figura 9. Figura 9 - Instalação do Microsoft Information Services Fonte: Autoria própria. Também foi necessário alterar a configuração do site padrão do Internet Information Services para executar na porta TCP/IP 8888, pois a porta padrão 80 seria utilizada pelo servidor web Apache para a execução do Redmine. De forma complementar também foi alterado o site padrão para utilizar o Application Pool baseado no Framewok .Net 4, conforme Figura 10. 21 http://www.microsoft.com/en-us/download/details.aspx?id=39277
  • 46. 45 Figura 10 - Configuração do application pool para o site padrão Fonte: Autoria própria. Finalmente, para conexão com banco de dados MySQL utilizado no desenvolvimento do protótipo, se fez necessário a instalação do driver apropriado, o qual foi obtido no site oficial22 e instalado utilizando suas configurações padrão. 3.3.4 Instalação do Sistema Controle de Versões Git Foram utilizadas quatro ferramentas para possibilizar a geração de rastreabilidade a partir do controle de versões. Sendo elas apresentadas a seguir. 22 http://dev.mysql.com/downloads/connector/net/
  • 47. 46 3.3.4.1 Git Este é o mecanismo de controle de versões propriamente dito, o qual teve sua versão 1.9.0 para sistema operacional Microsoft Windows obtida a partir do site do Git23 . No servidor, este software foi instalado seguindo suas opções padrão, com exceção do diretório de instalação, que foi modificado para c:ServerGit e adicionado o caminho C:ServerGitcmd à variável de ambiente Path no Windows conforme Figura 11. Figura 11 - Variável de ambiente Path Fonte: Autoria própria. No ambiente cliente todas as opções padrão foram mantidas. 23 http://git-scm.com/download
  • 48. 47 3.3.4.2 Gitblit Este software disponibiliza uma interface web para visualização e gerenciamento dos repositórios de fontes no servidor, sendo utilizada a versão 1.4.0 Gitblit GO 24 para Microsoft Windows. A instalação do Gitblit foi realizada a partir da descompactação do arquivo obtido para o diretório c:Servergitblit-1.4.0, e configuração da porta de execução do serviço no arquivo datagitblit.properties, que se encontra sob o diretório de instalação da aplicação. Conforme Quadro 3. Quadro 3 - Configuração de porta TCP para execução do serviço Gitblit Também foi criado o diretório base para criação dos repositórios em c:ServerRepositórios e parametrizado no arquivo de configuração do serviço, de acordo com Quadro 4. Quadro 4 - Configuração de diretório base para repositórios 24 http://gitblit.com
  • 49. 48 Para configuração do mecanismo de autenticação do Gitblit com Microsoft Active Directory, foi configurado o provedor de autenticação para o protocolo Lightweight Directory Access Protocol (LDAP) de acordo com Quadro 5. Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit De forma complementar também foram configurados os parâmetros para acesso ao do Gitblit ao domínio do Active Directory, indicando o endereço do servidor, configuração do domínio, usuário para leitura do servidor de domínio no momento da autenticação, e grupo de usuários administradores da ferramenta Gitblit. O Quadro 6 mostra as configurações realizadas no arquivo gitiblit.properties. Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory Após estas configurações, foi necessário instalar o serviço do Windows responsável pela execução do Gitblit, por meio do comando instalService. Este comando é disponibilizado no diretório de instalação do mesmo, conforme Quadro 7.
  • 50. 49 Quadro 7 - Instalação do serviço Windows para o Gitblit Posteriormente foi necessário configurar o Gitblit para execução por meio de serviço do Windows, onde foi necessário executar o aplicativo gitblitw.exe contido no diretório de instalação do software (neste caso c:Servergitblit- 1.4.0) e indicar ao mesmo o caminho de instalação do Java Runtime Environment (JRE), conforme Figura 12 Figura 12 - Configuração da máquina virtual Java para o Gitblit Fonte: Autoria própria.
  • 51. 50 Após estas configurações foi possível iniciar o serviço do Windows e acessar a interface da ferramenta por meio do endereço http://ip_do_servidor:8181. 3.3.4.3 TortoiseGit Este é um aplicativo utilizado para cliente do servidor Git, permitindo a realização de todas as operações necessárias, relacionadas ao controle de versões no ambiente de desenvolvimento. Para este aplicativo foi utilizada a versão 1.8.7 para 64 bits25 . Este programa foi instalado no lado cliente mantendo as opções padrão do instalador. 3.3.4.4 TurtleMine O TurtleMine26 é um plugin para integração do TortoiseGit com as tarefas existentes no sistema de gerenciamento de projetos Redmine, sendo que para este trabalho foi utilizado em sua versão 1.2.0.1 para 64 bits. De forma semelhante ao TortoiseGit, este aplicativo também foi instalado com suas configurações padrão. 3.3.5 Instalação do Redmine Para preparação do sistema Redmine, optou-se pela utilização do instalador Bitnami Redmine Stack disponibilizado no site oficial27 em sua versão v2.5.0. Este instalador é pré-configurado com todo conjunto de infraestrutura necessária para execução do Redmine, tais como servidor web Apache, linguagem de programação Ruby com framework Rails e banco de dados MySQL. 25 https://code.google.com/p/tortoisegit 26 https://code.google.com/p/turtlemine/ 27 http://bitnami.com/stack/redmine
  • 52. 51 O instalador Bitnami foi executado mantendo-se todas as opções padrão, de modo que apenas o diretório c:Server foi indicado como destino da instalação. Após a instalação foi acessada a interface da ferramenta por meio do endereço http://ip_do_servidor/redmine com as credenciais de administrador, que foram definidas no momento da instalação da mesma. Realizou- se então a configuração mecanismo de autenticação a partir do Microsoft Active Directory conforme Figura 13 Figura 13 - Configuração de para autenticação do Redmine Fonte: Autoria própria. Também foi realizada a configuração de uma conta de usuário a ser utilizada durante as atividades desenvolvidas neste trabalho. Conforme apresentado na Figura 14.
  • 53. 52 Figura 14 - Configuração de usuário para atividades de desenvolvimento Fonte: Autoria própria. 3.3.6 Instalação do Jenkins O servidor de Integração Contínua Jenkins28 foi instalado a partir da obtenção do pacote nativo para Windows, sendo que versão utilizada neste trabalho foi a 1.532.2 Long-Term Support (LTS), escolhida por ser uma versão de suporte estendido. Este pacote de instalação foi executado seguido suas opções padrão e informado apenas o diretório de instalação para C:ServerJenkins. Com a instalação desta ferramenta concluída, foi inicializado o serviço do Windows referente à mesma e acessado a interface desta através do endereço http://ip_do_servidor:8080. Como em todos os serviços anteriormente mencionados, foi realizada a configuração do mecanismo de autenticação para que o Jenkins utilize o mecanismo Microsoft Active Directory para validar senhas de usuário. A Figura 15 apresenta as configurações efetuadas na seção de “Configuração de Segurança Global” acessada pelo menu “Gerenciar o Jenkins”. 28 http://jenkins-ci.org/
  • 54. 53 Figura 15 - Configuração de autenticação do Jenkins Fonte: Autoria própria. De forma complementar, foi alterado o método de autorização para “Segurança baseado em matriz” e atribuído todas as permissões ao usuário “desenv” para que o mesmo opere com administrador da ferramenta. Para usuários não autenticados foi permitida apenas a visualização dos trabalhos já configurados, conforme Figura 16. Figura 16 - Configuração do método de autorização do Jenkins Fonte: Autoria própria.
  • 55. 54 Foram instalados alguns plugins no Jenkins para viabilizar este trabalho. A Tabela 2 apresenta a lista de plugins utilizados neste trabalho. Tabela 2 - Lista de plugins instalados no Jenkins Nome Descrição Git Client Plugin Integração com Git Git Plugin Integração com Git Downstream Buildview Plugin Permite a visualização de trabalhos dependentes Redmine Plugin Integração com o Redmine MSBuild Plugin Suporte para compilação de projetos .Net MSTest Plugin Execução de testes unitários em .Net Build Keeper Plugin Bloqueia a deleção de instância de trabalho. Copy Artifact Plugin Copia artefatos entre projetos Jenkins Sonar Plugin Integração com SonarQube Workspace Cleanup Plugin Realiza limpeza do workspace Fonte: Autoria própria. Para funcionamento do plugin MSBuild foi configurado na seção “MSBuild” do painel de gerenciamento de configurações do Jenkins, os parâmetros apresentados na Tabela 3. Tabela 3 - Parâmetros para o plugin MSBuild Parâmetro Valor MSBuild Name Net Framework 4.5 Path to MSBuild C:WindowsMicrosoft.NETFramework64v4.0.30319MSBuild.exe Fonte: Autoria própria. A configuração para utilização da plataforma Java foi feita por meio do item “JDK”, que está presenta na seção de gerenciamento de configurações do Jenkins. A Tabela 4 mostra os parâmetros informados.
  • 56. 55 Tabela 4 - Parâmetros para utilização da plataforma Java Parâmetro Valor Nome JDK 8 JAVA_HOME C:Serverjdk1.8.0_05_x64 Fonte: Autoria própria. Para que o Jenkins consiga fazer a integração com Redmine é necessário a configurações de alguns parâmetros na seção de gerenciamento do Jenkins, item “Redmine”. A Tabela 5 exibe os parâmetros a serem ajustados. Tabela 5 - Parâmetros para utilização do Redmine Parâmetro Valor Nome Intranet Base URL http://192.168.118.137/redmine/ Version Number 2.5 Fonte: Autoria própria. Também foi configurado o plugin do SonarQube. Para isso os parâmetros apresentados na Tabela 6 foram ajustados na seção de gerenciamento de configurações do Jenkins, item “Sonnar Runner”: Tabela 6 - Parâmetros para o plugin SonarQube Parâmetro Valor Nome Sonar-Runer-2.3 SONAR_RUNNER_HOME C:Serversonar-runner-2.3 Fonte: Autoria própria. Para utilização do Maven para compilação de aplicações Java se fez necessário a configuração referente plugin no item “Maven” na seção de gerenciamento do Jenkins. A Tabela 7 apresenta esta configuração.
  • 57. 56 Tabela 7 - Parâmetros para o plugin Maven Parâmetro Valor Nome Maven-3.2.1 MAVEN_HOME C:Serverapache-maven-3.2.1 Fonte: Autoria própria. 3.3.7 Instalação do SonarQube O software SonarQube29 foi instalado a partir da obtenção da versão 3.7.4, que é uma versão Long-Term Support (LTS), também escolhida por ser uma versão de suporte estendido. O arquivo obtido foi descompactado no diretório C:Serversonar-3.7.4. Após este procedimento foi editado o arquivo c:Serversonar- 3.7.4etcwrapper.conf e adicionado a configuração no inicio do arquivo para indicar o diretório temporário a ser utilizado pelo serviço, conforme Quadro 8. Caso esta alteração não seja realizada, ocorrerá um erro ao inicializar o serviço, pois o mesmo tentará criar um diretório temporário dentro de um diretório do sistema. Quadro 8 - Configuração de diretório temporário para o SonarQube Também foi instalado o serviço do Windows responsável pela execução do SonarQube e inicializado o mesmo posteriormente. O Quadro 9 apresenta os comandos executados para realizar esta atividade. 29 http://www.sonarqube.org/
  • 58. 57 Quadro 9 - Instalação do serviço para o SonarQube e inicialização. Após realização destes procedimentos a interface do SonarQube pode ser acessada pelo endereço http://ip_do_servidor:9000. Para melhor aderência da ferramenta a este trabalho foram utilizados alguns plugins, os quais estão definidos na Tabela 8. Tabela 8 - Lista de plugins instalados no SonarQube Nome Descrição C# Módulo para linguagem C# .NET Módulo para plataforma .Net Java Módulo para suportar linguagem Java LDAP Módulo para autenticação no Microsoft Active Directory SCM Activity Módulo para coletar estatísticas do controle de versões Fonte: Autoria própria. O Quadro 10 apresenta as configurações efetuadas para que o SonarQube faça autenticação contra o domínio Active Directory, como as demais ferramentas utilizadas neste trabalho. Nesta parametrização é indicando o endereço do servidor, configuração do domínio, usuário para leitura do servidor de domínio no momento da autenticação. O Quadro 10 mostra as configurações realizadas no arquivo sonar.properties que está no diretório conf sob o diretório de instalação do SonarQube.
  • 59. 58 Quadro 10 - Configuração do mecanismo de autenticação do SonarQube Com estas configurações foi necessário renomear os grupos de usuário padrão do SonarQube para que fosse possível também a sincronização destes com o Active Directory. O grupo sonar-administrators passou a se chamar administradores e o grupo sonar-users passou para usuários. Para realização da análise do código é necessário também o uso do utilitário Sonar Runner30 . Neste trabalho foi utilizada a versão 2.4 deste software. Sua instalação foi realizada por meio da descompactação do arquivo zip no diretório c:Serversonar-runner-2.4. Finalmente, a ferramenta está pronta para computar métricas do projeto a partir do Jenkins. 30 http://docs.codehaus.org/display/SONAR/Installing+and+Configuring+SonarQube+Runner
  • 60. 59 3.3.8 Instalação do Liquibase Para instalação do Liquibase31 foi necessário apenas obter o arquivo da versão 3.1.1 e descompactá-lo no diretório c:ServerLiquibase. Esta ferramenta precisa que haja uma biblioteca Java para conexão ao banco de dados (driver JDBC – Java Database Connectivity) no subdiretório lib dentro do diretório de instalação. Para este trabalho foi utilizado o driver MySQL Connector 5.1.3032 para conexão ao banco de dados MySQL SQL Server. Este serviço foi utilizado para manter compatibilidade da implementação dos protótipos em Java e C#. Qualquer banco de dados relacional suportado pela plataforma Java poderia ser utilizado. 3.4 CONFIGURAÇÃO DO PROJETO Esta seção descreve os procedimentos realizados em todas as ferramentas abordadas para configuração do projeto de sistema realizado neste trabalho. 3.4.1 Criação de Repositório de Código Fonte Foi acessada a interface do Gitblit, conforme descrito na seção anterior, foram criados dois repositórios de fontes, sendo um para realizar o controle de versões do protótipo na plataforma Java e outro para armazenar os códigos do protótipo na plataforma .Net. A Figura 17 apresenta os repositórios criados no Gitblit. 31 http://www.liquibase.org/download/index.html 32 http://dev.mysql.com/downloads/connector/j/
  • 61. 60 Figura 17 - Repositório para controle de versões dos protótipos Fonte: Autoria própria. Com a criação destes repositórios foi feito o clone do mesmo no ambiente utilizado para desenvolvimento. Sendo necessário acessar o repositório, copiar o endereço do mesmo conforme Figura 18. Figura 18 - Novo repositório Git a ser clonado Fonte: Autoria própria. Depois de efetuado a cópia do endereço, é necessário acessar a opção “Git clone” do menu de contexto do Windows a partir de um diretório vazio, conforme Figura 19.
  • 62. 61 Figura 19 - Opção Git Clone Fonte: Autoria própria. A partir da opção citada será apresentada a Figura 20 solicitando a confirmação para iniciar a execução da cópia do repositório. Neste momento não é necessário realizar nenhuma alteração das opções disponíveis. Também se pode observar que o endereço do repositório já foi preenchido automaticamente no devido campo. Figura 20 - Confirmação de clone para repositório Git Fonte: Autoria própria. Neste momento é necessário confirmar a operação de clone do repositório e aguardar sua conclusão, momento em que o repositório já estará pronto para receber os arquivos do projeto de software.
  • 63. 62 3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento Após a configuração inicial do sistema foram abertos dois projetos no Redmine, sendo uma para o protótipo na plataforma .Net e outro para o protótipo na plataforma Java. A Figura 21 apresenta tela de abertura de projeto nesta ferramenta, para o protótipo para a plataforma .Net. Figura 21 - Abertura do projeto para o protótipo no Redmine Fonte: Autoria própria. Tendo sido aberto o novo projeto, foi adicionado o usuário “desenv” com o papel de “gerente”. Também foram abertas versões do projeto a serem desenvolvidas, conforme Tabela 9.
  • 64. 63 Tabela 9 - Tabela de versões criadas para o projeto Nome Descrição Versão 1 - Cadastro Versão para entrega dos cadastros básicos Versão 2 - Lançamento Versão para entrega do lançamento de pedidos Fonte: Autoria própria. Para haver a possibilidade de visualização dos códigos fontes do sistema protótipo a partir do Redmine, foi adicionada ao projeto a parametrização necessária, nas configurações do projeto por meio da seção denominada “Repositórios” conforme Figura 22. Figura 22 - Parametrização de novo repositório de código fonte Fonte: Autoria própria. A partir da conclusão destas configurações, foram adicionadas, no Redmine, as tarefas de desenvolvimento do tipo “Funcionalidade”, que representam os requisitos, de acordo com Tabela 10. Tabela 10 - Listagem de tarefas de desenvolvimento Título Atribuído para Versão Cadastro de estado Desenvolvedor Versão 1 - Cadastro Cadastro de cidade Desenvolvedor Versão 1 - Cadastro Cadastro de produto Desenvolvedor Versão 1 - Cadastro Cadastro de produto Desenvolvedor Versão 1 - Cadastro Lançamento de pedidos Desenvolvedor Versão 2 - Lançamento Fonte: Autoria própria.
  • 65. 64 Após estes procedimentos terem sido concluídos, foi realizada uma cópia deste projeto, para que fosse possível ter o projeto idêntico para o protótipo a ser desenvolvido na plataforma Java. Neste procedimento foram necessárias alterações nos campos destinados à informação do nome do projeto e sua descrição, bem como na parametrização do repositório de códigos fontes. Estas alterações foram realizadas apenas para manter a correta referência para o projeto destinado ao protótipo na plataforma Java. 3.4.3 Configuração de Trabalhos no Jenkins Foram criados três trabalhos no Jenkins para cada protótipo desenvolvido sendo um em Java e outro em C#. As seções a seguir descrevem o conteúdo de cada trabalho. 3.4.3.1 Trabalho para o Ambiente de Desenvolvimento O primeiro trabalho é executado no ambiente de desenvolvimento quando o controle de versão notifica uma mudança no código fonte da aplicação e efetua os seguintes passos: a. Obtêm-se os códigos fontes do sistema; b. Realiza-se a compilação dos códigos fontes; c. Atualizam-se os objetos de banco de dados com o Liquibase; d. Implanta-se a nova versão do sistema no servidor de desenvolvimento; e. Coletam-se as métricas do código fonte pelo SonarQube; e f. Arquivam-se os artefatos para posterior implantação no ambiente de homologação e produto.
  • 66. 65 Além dos passos citados, o trabalho Jenkins de desenvolvimento também tem a configuração de uma seção de promoção, onde foi configurada a promoção para homologação e para produção. Os passos a serem executados neste caso são: a. Executa-se o trabalho apropriado para a promoção, no caso o segundo (de homologação) ou terceiro (de produção); b. Adiciona-se uma tag ou marcação no controle de versões registrando que a determinada versão do código fonte foi implantada no ambiente de homologação ou de produção; e c. Marca-se o build para ser arquivado de forma permanente. O Apêndice A apresenta a configuração do primeiro trabalho do Jenkins para o sistema em C# e o Apêndice B apresenta as referentes configurações para o sistema em Java. 3.4.3.2 Trabalho para o Ambiente de Homologação O segundo trabalho é executado a partir de uma promoção para homologação do primeiro trabalho. Neste momento as seguintes etapas são executadas: a. Obtém-se uma cópia do binário implantado no ambiente de desenvolvimento, bem como os arquivos Liquibase com o conjunto de alterações aplicado no banco de dados; b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de homologação; c. Implanta-se a aplicação no servidor de homologação; e d. Arquivam-se os artefatos utilizados para possível auditoria. O Apêndice C apresenta a configuração do segundo trabalho do Jenkins para o sistema em C# e o Apêndice C apresenta as referentes configurações para o sistema em Java.
  • 67. 66 3.4.3.3 Trabalho para o Ambiente de Produção O terceiro trabalho é executado a partir de uma promoção para produção do primeiro trabalho. Neste momento as seguintes etapas são executadas: a. Obtém-se uma cópia do binário implantado no ambiente de desenvolvimento, bem como os arquivos Liquibase com o conjunto de alterações aplicado no banco de dados; b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de produção; c. Implanta-se a aplicação no servidor de produção; e d. Arquivam-se os artefatos utilizados para possível auditoria. As configurações do terceiro trabalho do Jenkins não foram anexadas, pois são baseadas no segundo trabalho e tem os mesmos passos. As alterações realizadas para criação do terceiro trabalho são apenas no que se refere aos nomes de servidores, para que os artefatos tenham como destino o servidor de produção. 3.4.3.4 Preparação de Projetos .Net para a Integração Contínua Para possibilitar a compilação do projeto .Net é necessário ativar a opção “Enable NuGet Package Restore” na solução .Net, conforme Figura 23:
  • 68. 67 Figura 23 - Ativação da restauração de pacotes NuGet. Fonte: Autoria própria. De maneira complementar, é necessário alterar o arquivo “nuget.targets” que foi criado no diretório “.nuget” para que o parâmetro “DownloadNugetExe” fique conforme a linha apresentada no Quadro 11. Quadro 11 - Habilitação de download de executável NuGet. 3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE Esta seção aborda alguns procedimentos necessários para que as ferramentas permitam a automação de atividades necessárias para garantir a rastreabilidade e Integração Contínua. 3.5.1 Seleção de Tarefas do Redmine para Commit no Git Para a utilização do plugin TurtleMine juntamente com o Redmine, é necessário efetuar a configuração do mesmo para visualizar as tarefas cadastradas
  • 69. 68 para o projeto. É necessário acessar o Redmine, e copiar o link para visualização da listagem de tarefas em formato Atom, conforme Figura 24. Figura 24 - Link para visualização de lista de tarefas em formato Atom Fonte: Autoria própria. Tendo copiado o link, é necessário acessar as configurações do TortoiseGit para o projeto a partir do menu de contexto do Windows, conforme Figura 25. Figura 25 - Opção de acessar as configurações do TortoiseGit Fonte: Autoria própria.
  • 70. 69 É necessário selecionar a opção “Issue Tracker Integration”, e adicionar a integração com Redmine, indicando o diretório onde foi clonado o projeto no campo “Working Tree Path” o colar o link Atom que foi copiado anteriormente no campo “Parameters”. No campo “Provider” mantém-se a opção “TurtleMine – 64bit”. Figura 26 - Configuração do plugin TurtleMine Fonte: Autoria própria. A partir da conclusão destas alterações, será disponibilizado um botão na tela de commit do Tortoise, conforme apresentado na Figura 27, para que seja possível escolher a tarefa do Redmine que está associada ao mesmo.
  • 71. 70 Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit Fonte: Autoria própria. A partir desta opção podemos selecionar as tarefas que estão sendo atendidas por meio do commit. Figura 28 - Lista de tarefas apresentadas pelo TurtleMine Fonte: Autoria própria. A tarefa selecionada será vinculada ao commit realizado conforme Figura 29. Isto irá gerar o primeiro vinculo de rastreabilidade que poderá ser visualizado na tela do Gitblit, do Redmine e do Jenkins, conforme será apresentado no Capítulo 4 deste trabalho.
  • 72. 71 Figura 29 - Tarefa do Redmine associada ao commit no Git Fonte: Autoria própria. 3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do Gitblit Com o ajuste da configuração do Gitblit demonstrado no Quadro 12 é possível gerar um link para que na interface do Gitblit para acesso direto a tarefa do Redmine vinculada ao commit. Quadro 12 - Configuração de link entre o Gitblit e o Redmine Desta forma a tela de visualização de commits no Gitblit terá no cabeçalho um link para a tarefa do Redmine, que é apresentado na Figura 30
  • 73. 72 Figura 30 - Link do Gitblit para o Redmine Fonte: Autoria própria. 3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do Redmine Os procedimentos citados anteriormente garantem a manutenção de uma ligação entre uma confirmação de alteração de código fonte no controle de versão com uma atividade do Redmine. No entanto, também é possível gerar a associação de uma tarefa do Redmine com todos os commits relacionados à mesma. Para viabilizar isto é necessário configurar quais palavras chaves presentes na mensagem de commit deverão ser consideradas. Isto deve ser feito por meio do painel administrativo do sistema Redmine, na seção “Repositórios” no parâmetro “Palavras-chaves de referencia”, apresentado na Figura 31. Desta forma, todos os commits contendo qualquer uma destas palavras chaves serão vinculados a referente tarefa.
  • 74. 73 Figura 31 - Palavras-chaves de referência Fonte: Autoria própria. Após estas configurações, todos os envios de alterações realizados para o servidor terão associação dos commits a cada tarefa mencionada na descrição dos mesmos. A Figura 32 apresenta o quadro “Revisões associadas” do Redmine apresenta todas as relações de commit com tarefas do mesmo. Figura 32 - Revisões associadas a uma tarefa Fonte: Autoria própria.
  • 75. 74 Este é um dos principais elementos de rastreabilidade gerados neste trabalho, pois permitirá a rastreabilidade de cada artefato gerado a partir de um determinado requisito do sistema. 3.5.4 Hook Scripts no Gitblit O Gitblit permite a utilização de hook script para a execução de atividades quaisquer no momento em que é feito um envio de commits ao servidor (push). Neste trabalho foram configurados hook scripts para informar o Redmine que deve fazer nova leitura do repositório e para inicializar execução de um trabalho no Jenkins. Todos os scripts utilizados pelo Gitblit estão sob o diretório “datagroovy”, dentro do diretório de instalação da ferramenta. 3.5.4.1 Script para Comunicação de Commit ao Redmine A instalação do Gitblit disponibiliza um hook script com nome redmine- fetch.groovy , onde podem ser realizadas as configurações para comunicação com o serviço Redmine. O Quadro 13 mostra os ajustes realizados neste script para utilização neste trabalho. Quadro 13 - Configuração do hook script redmine-fetch O valor da chave de acesso ao Redmine (API-Key) utilizado nesta configuração precisa ser gerado por meio do painel administrativo do próprio sistema
  • 76. 75 Redmine, na seção “Repositórios” onde se deve marcar as opções apresentadas na Figura 33 e executar o comando “Gerar uma chave”, conforme a seguir. Figura 33 - Parâmetros de acesso aos serviços do Redmine Fonte: Autoria própria. Para ativar a execução do script é necessário editar o repositório no Gitblit e marcar o referente hook script como selecionado, de acordo com a Figura 34. Figura 34 - Seleção de hook script no Gitblit Fonte: Autoria própria. Feito estas configurações, as associações mencionadas na seção 3.5.3 estarão sendo concretizadas de forma automática.
  • 77. 76 3.5.4.2 Script para Execução de Trabalhos no Jenkins Outro hook script disponibilizado pelo Gitblit é o jenkins.groovy, onde podem ser realizadas as configurações necessárias para que o mesmo acione a execução de trabalhos do Jenkins. Este script ativará a execução de trabalhos que estão configurados para utilizar repositórios de código fonte que estão no Gitblit. O Quadro 14 mostra os ajustes realizados neste script para utilização neste trabalho. Quadro 14 - Configuração do hook script Jenkins Para ativar a execução deste script é necessário editar o repositório no Gitblit e marcar o referente hook script como selecionado, conforme mencionado anteriormente na Figura 34.
  • 78. 77 4 RESULTADOS E DISCUSSÕES A apresentação dos resultados obtidos neste trabalho foi organizada em algumas seções de análise, sendo elas para: Redmine, Gitblit, Jenkins, Liquibase e SonarQube. De forma complementar existem duas seções que apresentam a composição da rastreabilidade no processo e a matriz de rastreabilidade de artefatos e conclusão final. 4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE Para o objetivo desta pesquisa, a única informação provida pelo Redmine que foi utilizada para rastreabilidade é a listagem de revisões associadas a cada tarefa, conforme apresentado na Figura 35. A partir desta listagem é possível obter as revisões do controle de versão que foram originadas desta tarefa. Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine Fonte: Autoria própria.
  • 79. 78 Existe um plugin para o Jenkins, denominado Redmine Plugin33 , que permite a comunicação do Jenkins diretamente com o Redmine, o que possibilitaria a geração de informações para ligar estes dois softwares. Contudo, em testes realizados este recurso não se apresentou em condições de uso, pois após a realização de configurações o mesmo não realizou as atualizações das tarefas do Redmine (como esperado), desta forma foi descartado do escopo desta pesquisa. 4.2 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO GITBLIT A partir do acesso ao repositório de fontes no controle de versões pode-se ter algumas informações para a rastreabilidade do processo de desenvolvimento. Dentre elas estão, as etiquetas adicionadas pelo trabalho do Jenkins, as quais informam qual o dia e hora que foram realizadas promoções de trabalhos para o ambiente de homologação e produção (item “a” e “b” marcado na Figura 36). Também é possível visualizar qual tarefa do Redmine está relacionada a cada confirmação de alteração de código fonte (item “c” marcado na Figura 36). Figura 36 – Painel de principal do repositório de código fonte Fonte: Autoria própria. 33 https://wiki.jenkins-ci.org/display/JENKINS/Redmine+Plugin
  • 80. 79 Quando é selecionada uma determinada confirmação de alteração de fontes para visualização de detalhes, é possível obter outras informações relevantes para a rastreabilidade do desenvolvimento. A Figura 37 apresenta estas informações e na sequência são apresentados os significados de cada informação. Figura 37 - Detalhe de confirmação de alteração no código fonte Fonte: Autoria própria. As informações apresentadas na Figura 37 são as seguintes: a. Etiquetas que indicam data e hora, bem como qual instância de trabalho do Jenkins utilizou esta revisão do código fonte em uma promoção para homologação ou produção; b. Data e hora da confirmação de alteração no repositório de código fonte; c. Dados do desenvolvedor que confirmou a alteração no repositório; d. Descrição da mensagem de confirmação da alteração contendo um link diretor para a tarefa do Redmine mencionada; e e. Lista de artefatos alterados nesta revisão do controle versões.
  • 81. 80 4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS O acompanhamento da rastreabilidade do processo de software partindo-se do produto final entregue pode ser iniciado a partir do Jenkins. Ao acessar a tela principal deste, pode-se visualizar a listagem de todos os trabalhos configurados no sistema, conforme Figura 38. Figura 38 - Tela principal do Jenkins Fonte: Autoria própria. Acessando o trabalho principal (neste caso o trabalho “Prototipo”), pode-se verificar as informações conforme apresentado na Figura 39.
  • 82. 81 Figura 39 - Painel principal de um trabalho Jenkins Fonte: Autoria própria. Nesta tela é possível visualizar as seguintes informações: a. Lista com histórico das construções realizadas com seus referentes número de identificação, data da realização, e ainda alguns ícones, sendo que a estrela azul indica que aquela instância do trabalho foi promovida para homologação, a estrela verde indica que a instância do trabalho foi promovida para produção, o cadeado informa que os dados arquivados nesta instância do trabalho não será apagado, e o último ícone azul em
  • 83. 82 formato de meia lua indica que aquela instância do trabalho foi analisada pelo SonarQube. b. Conjunto de links para os artefatos arquivados na última construção. Tais artefatos podem ser resgatados novamente para fins de auditoria. c. Link para listagem de alterações de código fonte que estão contidas na última instância do trabalho Jenkins executado. d. Lista de projetos filhos que serão executados a partir do trabalho Jenkins atual. e. Link para o endereço do projeto Redmine relacionado ao trabalho Jenkins. f. Listagem de promoções do trabalho atual. Permite verificar data e hora que houve as promoções do trabalho Jenkins para os ambientes de homologação e produção. g. Link para acessar as métricas do software referenciado no trabalho Jenkins atual. Ao selecionar uma instância de trabalho do Jenkins será apresentada a tela, conforme Figura 40, com detalhes daquela construção. Figura 40 - Detalhe de uma construção do Jenkins Fonte: Autoria própria.
  • 84. 83 Na Figura 40 foram destacadas algumas áreas da tela, conforme segue: a. Artefatos gerados ou utilizados na construção que foram arquivados para gerar evidências e possibilitar auditoria; b. Lista de confirmações de alterações de fontes que foram enviadas ao controle de versões e que acionaram e execução do trabalho Jenkins, com links para visualização de detalhes das mesmas, tarefa do Redmine relacionada e visualização de detalhes diretamente no sistema de controle de versões Gitblit; c. Indicativo de que a instância do trabalho atual foi acionada a partir de uma alteração no controle de versões; d. Informação sobre qual foi a revisão do controle de versões utilizada para este instância do trabalho; e. Links para acessar a listagem de todas as confirmações de alterações no controle de versão, bem como seus detalhes; f. Apresentação das saídas de linha de comando que foram geradas a partir da execução da instância atual do trabalho do Jenkins; g. Link para acessar a relação de trabalhos dependentes (neste caso trabalho de Homologação e Produção). Também são apresentados seus status de execução e, caso já tenham sido executado, a data e hora de execução e seu referente status; e h. Lista de promoções executadas para a instância atual do trabalho Jenkins. 4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE Com a execução do conjunto de alterações configuradas para execução do Liquibase (Apêndices E, F, G, H, I e J), o trabalho configurado no Jenkins sincronizou os objetos de banco de dados e gerou algumas informações relevantes para a auditoria de alterações no banco de dados.
  • 85. 84 Todas as alterações realizadas pelo Liquibase são registradas em uma tabela do banco de dados nomeada DATABASECHANGELOG. Estas informações são apresentadas na Figura 41. Figura 41 - Registro de alterações do banco de dados Fonte: Autoria própria. Como informações relevantes para auditoria das alterações de banco de dados têm-se: a. Autor de cada alteração; b. Arquivo utilizado como base para realizar a alteração; c. Data e hora de execução de cada alteração; d. Ordem de execução de cada arquivo; e. Descrição resumida dos tipos de alterações realizadas; e f. O comentário inserido no arquivo de alterações do banco de dados. Tendo como base a data e hora da execução é possível saber qual foi o trabalho do Jenkins que acionou esta alteração, e posterior auditoria dos arquivos que originaram as mesmas. Com estas informações também é possível rastrear a versão do sistema que foi implantada gerando determinada alteração no banco de dados. 4.5 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO SONARQUBE As informações providas pelo SonarQube não colaboram diretamente para a obtenção da rastreabilidade de artefatos no processo de desenvolvimento de