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

1.356 visualizações

Publicada em

TCC de Pós Graduação em Engenharia de Software

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.356
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
50
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 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. 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. 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. 4. Dedico a todos que estiveram ao meu lado nesta etapa de aprendizado.
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×