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

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR

DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO

ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE

ADRIANO TEIXEIRA DE SOUZA

APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A

RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO

DE SOFTWARE

MONOGRAFIA DE ESPECIALIZAÇÃO

MEDIANEIRA

2014

ADRIANO TEIXEIRA DE SOUZA


RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE

SOFTWARE

Monografia apresentada como requisito parcial à obtenção do título de Especialista na Pós Graduação em Engenharia de Software, da Universidade Tecnológica Federal do Paraná – UTFPR – Câmpus Medianeira. Orientador: Prof. MSc. Wesley Klewerton Guez Assunção. Co-Orientador: Prof. MSc. Cristiano Marcos Lunkes

MEDIANEIRA

2014

Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Graduação e Educação Profissional

Especialização em Engenharia de Software

TERMO DE APROVAÇÃO


RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE

SOFTWARE

Por

Adriano Teixeira de Souza

Esta monografia foi apresentada às 10:10 h do dia 07 de Agosto de 2014 como

requisito parcial para a obtenção do título de Especialista no curso de Engenharia

de Software, da Universidade Tecnológica Federal do Paraná, Câmpus

Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos

professores abaixo assinados. Após deliberação, a Banca Examinadora

considerou o trabalho aprovado.

______________________________________ Prof. MSc. Wesley Klewerton Guez Assunção

UTFPR – Câmpus Toledo (orientador)

____________________________________ Prof. Esp. Márcio Angelo Matté UTFPR – Câmpus Medianeira

_________________________________________ Prof. Dr. Pedro Luiz de Paula Filho

UTFPR – Câmpus Medianeira

Dedico a todos que estiveram ao meu lado

nesta etapa de aprendizado.

AGRADECIMENTOS

Agradeço a Deus por estar concluindo mais este passo para a construção do

conhecimento e por ter me conduzido com segurança nas constantes viagens até a

cidade de Medianeira.

Agradeço a minha querida esposa Keila Couto dos Santos por estar sempre

junto a mim e pelo grande esforço também empenhado nesta caminhada.

Agradeço ao grande amigo e Mestre Wesley Klewerton Guez Assunção pela

orientação e apoio na elaboração deste material, bem como pelo tempo dispensado

para acompanhar de perto este trabalho.

Agradeço de forma muito singela ao ilustríssimo Mestre Cristiano Marcos

Lunkes, excelentíssima pessoa e de coração muito humilde, pela disposição em

acompanhar este trabalho e pelo esforço empenhado para estar na cidade de

Medianeira colaborando nesta jornada.

Agradeço ao Mestre Alan Gavioli por ter trabalhado pela oferta deste curso e

pelo grande zelo com o mesmo.

Agradeço a todos os professores que contribuíram para o aprendizado

durante o decorrer deste curso.

Agradeço aos colegas de turma pela prazerosa companhia e troca de

experiência nestes inúmeros sábados.

“A percepção do desconhecido é a mais fascinante das experiências. O homem que

não tem os olhos abertos para o misterioso passará pela vida sem ver nada”.

(ALBERT EINSTEIN)

RESUMO

SOUZA, Adriano Teixeira de. APLICAÇÃO DE INTEGRAÇÃO CONTÍNUA PARA VIABILIZAR A RASTREABILIDADE DE ARTEFATOS DURANTE A MANUTENÇÃO DE SOFTWARE. 2014. 103f. Monografia (Especialização em Engenharia de Software). Universidade Tecnológica Federal do Paraná, Medianeira, 2014.

Este trabalho tem por objetivo apresentar as contribuições que as técnicas de Integração Contínua podem agregar ao processo de gerenciamento de configuração de software. As técnicas avaliadas neste trabalho visam dar subsídios para rastreabilidade de relacionamentos entre requisitos, artefatos e produto final durante o ciclo de vida de um software. Para isso, é apresentada a revisão de literatura sobre temas relacionados, ferramentas que viabilizam a aplicação destas técnicas e elaborado um protótipo para demonstração da aplicação das mesmas. E finalmente, são analisadas as informações providas pelas ferramentas e elaborado uma matriz de rastreabilidade de artefatos de software.

Palavras-chave: Gerenciamento de Configuração, Controle de Versões,

Manutenção, Gerenciamento de Projetos.

ABSTRACT

SOUZA, Adriano Teixeira de. APPLICATION OF CONTINUOUS INTEGRATION TO ENABLE THE TRACEABILITY OF ARTIFACTS DURING SOFTWARE MAINTENANCE. 2014. 103f. Monograph (Lato Sensu Postgraduate on Software Engineering). Technological Federal University of Paraná, Medianeira-Brazil, 2014.

This work has a goal of presenting the contribution that the Continuous Integration technics can aggregate on the software configuration management process. The evaluated technics on this work aim give subsidies to relationship traceability between requirements, artifacts and end product during the software lifecycle. For this, is presented the literature revision about the related subjects, tools to make possible the application of this technics and prototype development to show the applying of them. Finally, are analyzed the information provided by the tools and elaborated one matrix of traceability of software artifacts. Keywords: Configuration Management, Version Control, Maintaining, Project Management.

LISTA DE FIGURAS

Figura 1 - Sistema de controle de versões distribuído .............................................. 28

Figura 2 - Intercomunicação entre serviços............................................................... 32

Figura 3 - Diagrama de classes do sistema de pedidos de venda ............................ 34

Figura 4 - Diagrama de caso de uso do sistema de pedidos de venda ..................... 35

Figura 5 - Diagrama de classes do sistema de pedidos de venda ............................ 35

Figura 6 - Domínio Microsoft Active Directory ........................................................... 37

Figura 7 - Variável de ambiente JAVA_HOME .......................................................... 38

Figura 8 - Variável de ambiente Path com JDK......................................................... 39

Figura 9 - Instalação do Microsoft Information Services ............................................ 44

Figura 10 - Configuração do application pool para o site padrão .............................. 45

Figura 11 - Variável de ambiente Path ...................................................................... 46

Figura 12 - Configuração da máquina virtual Java para o Gitblit ............................... 49

Figura 13 - Configuração de para autenticação do Redmine .................................... 51

Figura 14 - Configuração de usuário para atividades de desenvolvimento ............... 52

Figura 15 - Configuração de autenticação do Jenkins .............................................. 53

Figura 16 - Configuração do método de autorização do Jenkins .............................. 53

Figura 17 - Repositório para controle de versões dos protótipos .............................. 60

Figura 18 - Novo repositório Git a ser clonado .......................................................... 60

Figura 19 - Opção Git Clone ...................................................................................... 61

Figura 20 - Confirmação de clone para repositório Git .............................................. 61

Figura 21 - Abertura do projeto para o protótipo no Redmine ................................... 62

Figura 22 - Parametrização de novo repositório de código fonte .............................. 63

Figura 23 - Ativação da restauração de pacotes NuGet. ........................................... 67

Figura 24 - Link para visualização de lista de tarefas em formato Atom ................... 68

Figura 25 - Opção de acessar as configurações do TortoiseGit................................ 68

Figura 26 - Configuração do plugin TurtleMine ......................................................... 69

Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit ................................... 70

Figura 28 - Lista de tarefas apresentadas pelo TurtleMine ....................................... 70

Figura 29 - Tarefa do Redmine associada ao commit no Git .................................... 71

Figura 30 - Link do Gitblit para o Redmine ................................................................ 72

Figura 31 - Palavras-chaves de referência ................................................................ 73

Figura 32 - Revisões associadas a uma tarefa ......................................................... 73

Figura 33 - Parâmetros de acesso aos serviços do Redmine ................................... 75

Figura 34 - Seleção de hook script no Gitblit ............................................................. 75

Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine ... 77

Figura 36 – Painel de principal do repositório de código fonte .................................. 78

Figura 37 - Detalhe de confirmação de alteração no código fonte ............................ 79

Figura 38 - Tela principal do Jenkins ......................................................................... 80

Figura 39 - Painel principal de um trabalho Jenkins .................................................. 81

Figura 40 - Detalhe de uma construção do Jenkins .................................................. 82

Figura 41 - Registro de alterações do banco de dados ............................................. 84

Figura 42 - Tela principal de um projeto no SonarQube ............................................ 85

Figura 43 - Tela hotspot do SonarQube .................................................................... 86

Figura 44 - Visualização detalhada de violações no SonarQube .............................. 86

LISTA DE QUADROS

Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly ....................... 41

Quadro 2 - Configuração inicial do Wildfly................................................................. 41

Quadro 3 - Configuração de porta TCP para execução do serviço Gitblit ................. 47

Quadro 4 - Configuração de diretório base para repositórios .................................... 47

Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit ............... 48

Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory .................. 48

Quadro 7 - Instalação do serviço Windows para o Gitblit .......................................... 49

Quadro 8 - Configuração de diretório temporário para o SonarQube ........................ 56

Quadro 9 - Instalação do serviço para o SonarQube e inicialização. ........................ 57

Quadro 10 - Configuração do mecanismo de autenticação do SonarQube .............. 58

Quadro 11 - Habilitação de download de executável NuGet. .................................... 67

Quadro 12 - Configuração de link entre o Gitblit e o Redmine .................................. 71

Quadro 13 - Configuração do hook script redmine-fetch ........................................... 74

Quadro 14 - Configuração do hook script Jenkins ..................................................... 76

Quadro 15 - Matriz de rastreabilidade de artefatos ................................................... 87

LISTA DE TABELAS

Tabela 1 - Usuários cadastrados no Active Directory ................................................ 37

Tabela 2 - Lista de plugins instalados no Jenkins ..................................................... 54

Tabela 3 - Parâmetros para o plugin MSBuild ........................................................... 54

Tabela 4 - Parâmetros para utilização da plataforma Java ....................................... 55

Tabela 5 - Parâmetros para utilização do Redmine .................................................. 55

Tabela 6 - Parâmetros para o plugin SonarQube ...................................................... 55

Tabela 7 - Parâmetros para o plugin Maven ............................................................. 56

Tabela 8 - Lista de plugins instalados no SonarQube ............................................... 57

Tabela 9 - Tabela de versões criadas para o projeto ................................................ 63

Tabela 10 - Listagem de tarefas de desenvolvimento ............................................... 63

LISTA DE SIGLAS

API Application Programming Interface

CMMI Capability Maturity Model Integration

IDE Integrated Development Environment

JDBC Java Database Connectivity

JDK Java Development Kit

JRE Java Runtime Environment

LDAP Lightweight Directory Access Protocol

LTS Long Term Support

MPS.BR Melhoria de Processo do Software Brasileiro

SCM Software configuration management

SQL Structured Query Language

TCP/IP Transmission Control Protocol / Internet Protocol

XML eXtensible Markup Language

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 16

1.1 OBJETIVO GERAL ............................................................................................. 17

1.2 OBJETIVOS ESPECÍFICOS ............................................................................... 17

1.3 JUSTIFICATIVA .................................................................................................. 17

2 FUNDAMENTAÇÃO TEÓRICA .............................................................................. 20

2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE .... 20

2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE ............................. 21

2.3 A INTEGRAÇÃO CONTÍNUA .............................................................................. 22

2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO

SOFTWARE .............................................................................................................. 25

3 MATERIAL E MÉTODOS ....................................................................................... 26

3.1 FERRAMENTAS ................................................................................................. 26

3.1.1 Linguagem de Programação ............................................................................ 26

3.1.1.1 Java .............................................................................................................. 27

3.1.1.2 C# ................................................................................................................. 27

3.1.2 Git ..................................................................................................................... 28

3.1.3 Jenkins ............................................................................................................. 29

3.1.4 Redmine ........................................................................................................... 30

3.1.5 SonarQube ....................................................................................................... 30

3.1.6 Liquibase .......................................................................................................... 31

3.2 METODOLOGIA .................................................................................................. 31

3.2.1 Cenário de Integração Contínua ...................................................................... 31

3.2.2 Configuração do Ambiente para Desenvolvimento .......................................... 33

3.2.3 Construção do Protótipo ................................................................................... 34

3.3 INSTALAÇÃO DAS FERRAMENTAS ................................................................. 36

3.3.1 Sistema Operacional Windows ......................................................................... 36

3.3.2 Instalação da Plataforma Java ......................................................................... 37

3.3.2.1 Kit de Desenvolvimento Java ....................................................................... 38

3.3.2.2 Instalação da Ferramenta de Automação de Compilação ............................ 39

3.3.2.3 Servidor de Aplicações ................................................................................. 40

3.3.2.4 Ambiente de Desenvolvimento ..................................................................... 41

3.3.3 Instalação da Plataforma .Net .......................................................................... 42

3.3.3.1 Framework .Net ............................................................................................ 43

3.3.3.2 Ambiente de Desenvolvimento ..................................................................... 43

3.3.3.3 Preparação para a Integração Contínua ....................................................... 43

3.3.3.4 Servidor de Aplicações ................................................................................. 44

3.3.4 Instalação do Sistema Controle de Versões Git ............................................... 45

3.3.4.1 Git ................................................................................................................. 46

3.3.4.2 Gitblit ............................................................................................................ 47

3.3.4.3 TortoiseGit .................................................................................................... 50

3.3.4.4 TurtleMine ..................................................................................................... 50

3.3.5 Instalação do Redmine ..................................................................................... 50

3.3.6 Instalação do Jenkins ....................................................................................... 52

3.3.7 Instalação do SonarQube ................................................................................. 56

3.3.8 Instalação do Liquibase .................................................................................... 59

3.4 CONFIGURAÇÃO DO PROJETO ....................................................................... 59

3.4.1 Criação de Repositório de Código Fonte.......................................................... 59

3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento ................................. 62

3.4.3 Configuração de Trabalhos no Jenkins ............................................................ 64

3.4.3.1 Trabalho para o Ambiente de Desenvolvimento ........................................... 64

3.4.3.2 Trabalho para o Ambiente de Homologação ................................................ 65

3.4.3.3 Trabalho para o Ambiente de Produção ....................................................... 66

3.4.3.4 Preparação de Projetos .Net para a Integração Contínua ............................ 66

3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE .......................... 67

3.5.1 Seleção de Tarefas do Redmine para Commit no Git ...................................... 67

3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do

Gitblit ........................................................................................................................ 71

3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do

Redmine .................................................................................................................... 72

3.5.4 Hook Scripts no Gitblit ...................................................................................... 74

3.5.4.1 Script para Comunicação de Commit ao Redmine ....................................... 74

3.5.4.2 Script para Execução de Trabalhos no Jenkins ............................................ 76

4 RESULTADOS E DISCUSSÕES ........................................................................... 77

4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE .......................... 77

4.2 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO GITBLIT ............................. 78

4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS ........................... 80

4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE ....................... 83

4.5 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO SONARQUBE ................... 84

4.6 MATRIZ DE RASTREABILIDADE ....................................................................... 87

5 CONCLUSÃO ......................................................................................................... 89

5.1 CONSIDERAÇÕES FINAIS ................................................................................ 89

5.2 TRABALHOS FUTUROS .................................................................................... 90

REFERÊNCIAS ......................................................................................................... 91

APÊNDICE A - TRABALHO DO JENKINS (.NET DESENV) ..................................... 93

APÊNDICE B - TRABALHO DO JENKINS (JAVA DESENV) .................................... 94

APÊNDICE C – TRABALHO DO JENKINS (.NET HOMOLOGAÇÃO) ..................... 95

APÊNDICE D - TRABALHO DO JENKINS (JAVA HOMOLOGAÇÃO) ..................... 96

APÊNDICE E – ARQUIVO LIQUIBASE PARA TABELA DE ESTADO ..................... 97

APÊNDICE F – ARQUIVO LIQUIBASE PARA TABELA DE CIDADE ....................... 98

APÊNDICE G - ARQUIVO LIQUIBASE PARA TABELA DE PRODUTOS ................ 99

APÊNDICE H - ARQUIVO LIQUIBASE PARA TABELA DE PARCEIROS ............. 100

APÊNDICE I – ARQUIVO LIQUIBASE PARA TABELA DE PEDIDO ...................... 101

APÊNDICE J – ARQUIVO LIQUIBASE INICIALIZAÇÃO DA EXECUÇÃO ............. 102

16

1 INTRODUÇÃO

A manutenção e evolução dos produtos de software se fazem necessárias

para muitas organizações, pois estes elementos sustentam a base operacional e

estratégica das mesmas. Conforme SOMMERVILLE (2011), altos investimentos são

realizados e as organizações se tornam cada vez mais dependentes de sistemas

computacionais.

Mesmo havendo o reconhecimento da necessidade de uma abordagem

profissional para a condução de projetos de software, muitos profissionais o fazem

sem prévio conhecimento de métodos e técnicas apropriadas. De acordo com

PRESSMAN (2011), nestas condições gera-se um produto final de baixa qualidade e

fadado a um curto tempo de vida.

O mesmo autor (PRESSMAN, 2011) enfatiza que durante o ciclo de vida de

grandes projetos, alterações não controladas podem minar a reputação do software.

É necessário utilizar procedimentos humanos e ferramentas automatizadas a fim de

garantir o bom andamento do processo. Para FARLEY e HUMBLE (2014), todo

processo que puder ser automatizado deverá ser. A automatização possibilita

repetibilidade, testabilidade, garantia de execução de todas as etapas de um

procedimento.

Considerando o exposto, neste trabalho são exploradas ferramentas e

técnicas para gerenciamento de configuração de software aliadas a automatização

proporcionada pela Integração Contínua. Com isso obtém-se a rastreabilidade de

artefatos de software durante o ciclo de vida do produto. Desta forma, é possível

aferir quais tipos de artefatos podem ser relacionados com um requisito, uma

liberação de versão que está implantada, ou até mesmo quando e porque surgiu um

determinado artefato que se encontra no produto.

Os resultados obtidos são apresentados por meio de matriz de referência

cruzada informando qual o nível de rastreabilidade poderá se obter a partir de um

determinado artefato do processo de desenvolvimento e manutenção do software.

17

1.1 OBJETIVO GERAL

Aplicação da Integração Contínua para viabilizar a rastreabilidade de artefatos

durante a manutenção de software.

1.2 OBJETIVOS ESPECÍFICOS

Para atingir o objetivo geral os seguintes objetivos específicos são propostos:

a. Revisar de literatura sobre técnicas de Integração Contínua e

Gerenciamento de Configuração de Software;

b. Identificar técnicas que favorecem a obtenção da rastreabilidade de

artefatos.

c. Avaliar técnicas existentes para aplicação da Integração Contínua.

d. Verificar ferramentas de controle de versão, Integração Contínua,

gerenciamento de projetos, que possibilitem a aplicação das técnicas

avaliadas.

e. Elaborar uma aplicação experimental e configurar um ambiente integrado

para gerenciamento do ciclo de vida de aplicações, que serão utilizados

para verificação e aplicação das técnicas avaliadas.

1.3 JUSTIFICATIVA

Durante o ciclo de vida de um software há muitas mudanças de

funcionalidades, alterações de artefatos, adição de componentes, etc. Tais

manutenções provêm de mudanças nos requisitos de negócios, que serviram de

base para a concepção do produto, mudanças no ambiente onde o software está

sendo utilizado, adequações à legislação, ou até mesmo uma simples refatoração de

código. A manutenção do software é de suma importância para que o mesmo tenha

18

longo tempo de utilização. Entretanto, todos os eventos de desenvolvimento ou

manutenção do software devem ser registrados por meio de procedimento e técnicas

abordados pela Gerência de Configuração.

A Gerência de Configuração orienta o processo de desenvolvimento de

software para que seja possível identificar requisitos iniciais do sistema, registrar os

defeitos encontrados no produto bem como suas alterações ao longo de seu tempo

de vida. A Gerência de Configuração recomenda também o uso de ferramentas para

que seja possível ter o registro histórico de todas as alterações que ocorreram no

código fonte do software (SOMMERVILLE, 2011). As ferramentas comumente

utilizadas são sistemas de registro de bugs ou solicitações de desenvolvimento e

sistema de controle de versões de código fonte.

Estes tipos de ferramentas já estão difundidos no cenário de desenvolvimento

de software, contudo a abordagem da Gerência de Configuração vai além da

utilização destas. De acordo com SOMMERVILLE (2011), para a utilização eficiente

das técnicas de Gerência de Configuração é necessário:

a. Existir o registro de todas as requisições de mudanças em uma

ferramenta apropriada;

b. Ter a utilização de um mecanismo de controle de versões e não utilizá-lo

apenas como um repositório de arquivos, mas também registrar etiquetas

para marcar versões de produto, criar linhas de desenvolvimento

conhecidas com branch quando houver necessidade de implementações

ou correções em diferentes versões do software; e

c. Utilização de um sistema de compilação e construção automatizado que

consiga agregar código-fonte, bibliotecas e executar testes.

É importante ressaltar que PRESSMAN (2011) trás algumas características

importantes que o Gerenciamento de Configuração deve possibilitar, dentre elas

estão:

a. Controle de Requisitos – possibilita rastrear qual requisito gerou

determinado artefato do produto; e

b. Pistas de auditoria – trás informações que permite identificar quando,

por quem e por que alterações foram feitas no software.

19

Para que o Gerenciamento de Configuração aconteça com eficiência pode-se

utilizar técnicas de Integração Contínua. A Integração Contínua preza pela

automação do processo de construção do software, testes e implantação, durante a

confirmação de alteração do programa no sistema de controle de versões

(FOWLER, 2006).

A utilização de uma ferramenta para aplicação de técnicas de Integração

Contínua é de fundamental importância. Com a automação de procedimentos pode-

se montar um fluxo de trabalho para implantação do software que se inicia na

integração da manutenção dos diversos desenvolvedores até a implantação final em

ambiente produtivo. Sendo assim, não há intervenção manual na compilação ou

disponibilização do software em ambiente produtivo, o que dá a garantia de um nível

elevado de auditoria do processo de desenvolvimento ou até mesmo de repetições

ou testes do mesmo (SMART, 2011).

20

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem como objetivo apresentar os principais conceitos e técnicas

básicas para o entendimento do trabalho desenvolvido. São abordados aspectos

relacionados ao processo de desenvolvimento de software, gerenciamento da

configuração, Integração Contínua, e finalmente a rastreabilidade de artefatos de

software.

2.1 PROCESSO DE DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE

Durante o ciclo de vida de um software, diversas atividades são executadas

para que seja possível efetuar a construção do produto. São elencados e

especificados os requisitos, é elaborado projeto de banco de dados, arquitetura e

interface, posteriormente é desenvolvido o produto, os testes são efetuados e

finalmente ocorre a homologação do mesmo. Ao final destas atividades são

realizados os ajustes necessários a partir do feedback obtido e liberado o produto

para uso (SOMMERVILLE, 2011).

Uma vez concluído o processo de desenvolvimento do software e o produto

liberado para uso surgem necessidade de mudanças. As mudanças pode ser em

requisitos, novas tecnologias, necessidade de novos recursos ou mesmo para

correção de defeitos (PRESSMAN, 2011). De modo complementar, SOMMERVILE

(2011) apresenta a evolução do software como fator importante, pois as empresas

despendem grandes volumes financeiros nestes e existe grande dependência dos

mesmos para realização de suas atividades.

Fatores internos à equipe de desenvolvimento também podem gerar

manutenção do software. O processo de refatoração apresentado por FOWLER

(2004) propõe alterações do sistema sem que haja alteração do comportamento do

mesmo. Estas modificações podem ser efetuadas visando eliminar redundância ou

elementos não utilizados, melhorar a eficiência de algoritmos, adequar estrutura de

dados, reduzir o acoplamento e aumentar a coesão.

21

2.2 GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE

De acordo com PRESSMAN (2011) os processos de gerência de

configuração visam identificar e controlar alterações do software, garantir que

trabalhos de manutenção do produto sejam implementados corretamente, e prover

informações sobre as alterações a quem houver interesse. A gestão da configuração

se baseia em um conjunto de atividades que visam dar rastreabilidade e controle dos

trabalhos realizados durante o ciclo de vida do software.

SOMMERVILE (2011) apresenta quatro grandes atividades que resumem o

processo de gerenciamento de configuração, as quais são:

a. Gerenciamento de mudanças – diz respeito ao acompanhamento de

requisições de mudanças e avaliação de custo, impacto, como e quando

efetuar tal mudança;

b. Gerenciamento de versões – garantir a manutenção das diversas

revisões dos componentes para que haja o histórico de mudanças e

trabalho de diferentes desenvolvedores de forma distribuída e paralela

sem interferência mutua;

c. Construção do sistema – diz respeito à resolução de dependências1 de

artefatos e componentes externos a fim de gerar o sistema executável; e

d. Gerenciamento de releases – Preparar o software para disponibilizá-lo

ao cliente e manter o histórico de versões liberadas anteriormente.

Para haver um bom processo de Gerenciamento de Configuração é

necessário validar três itens básicos. Primeiramente, permitir identificar rapidamente

qual a versão exata dos artefatos que são implantados em produção.

Consequentemente deve ser possível recuperar facilmente a versão exata dos

artefatos que estão em produção. De forma complementar também é necessário que

haja possiblidades de se efetuar pequenas correções na versão dos artefatos que

estão em produção, compilar novamente esta versão corrigida e implantar a mesma

(AIELLO e SACHS, 2011).

1 Agregar artefatos necessários para a construção do software, tais como biblioteca de código.

22

Além disso, um processo de gerenciamento de configuração bem definido e

aplicado é requisito para obtenção de certificações de qualidade, tais como CMMI e

MPS.BR.

Segundo SOFTEX (2013), o processo gerenciamento de configuração é

importante para o desenvolvimento de software, pois permite que haja o controle

sobre o que é desenvolvido e alterado. A necessidade deste processo é definida em

seu Guia de Fundamentação para Implementação do Nível F, o segundo nível em

sua escala de níveis de maturidade, que se inicia com o nível G com o tema de

Gerenciamento de Processos e Requisitos e segue até o nível A, que possui foco na

otimização do processo.

Para CMMI (2014), o Gerenciamento da Configuração deve:

a. Garantir a seleção de item de trabalho para cada versão do software a ser

desenvolvida;

b. Controlar as alterações nos documentos que guiam o desenvolvimento; e

c. Prover status e dados sobre a configuração do software para

desenvolvedores, usuários finais e clientes.

O guia CMMI for Development em sua versão 1.3 também apresenta que um

dos propósitos fundamentais do Gerenciamento da Configuração é a auditoria da

configuração.

2.3 A INTEGRAÇÃO CONTÍNUA

Conforme FOWLER (2006), o processo de Integração Contínua é baseado

em um conjunto de práticas que visam agilizar o processo de implantação, diminuir a

quantidade de defeitos no sistema ou o mesmo diminuir o tempo de permanência de

um defeito no sistema. Dentre estas práticas podem ser destacadas:

a. Automatização de build – envolve a automatização do agrupamento de

artefatos, resolução de dependência, atualização de banco de dados e

compilação do software. Esta automatização previne a ocorrência de

23

erros neste processo, proporciona um processo testável e que pode ser

repetido.

b. Build auto testável - apresenta a inclusão de testes automatizados como

elemento fundamental para validação e verificação do software, indo além

da compilação e chegando a verificar se cada funcionalidade foi

desenvolvida conforme especificado. Com isso é possível obter maior

segurança na implantação.

c. Commits frequentes – é de fundamental importância que os membros da

equipe de desenvolvimento enviem suas alterações para o sistema de

controle de versões em um curto intervalo de tempo. É recomendável que

isso seja feito em um período máximo de um dia. Esta prática favorece a

localização rápida de defeitos decorrente da integração do trabalho de

diversos desenvolvedores.

d. Cada commit deve atualizar o repositório em um servidor de

integração – o serviço de Integração Contínua monitora o repositório do

software e inicia a construção automatizada sempre que uma alteração do

código fonte for enviada ao repositório e emite notificação em caso de

falha na construção.

e. Todos devem ver o que está acontecendo – em um processo de

Integração Contínua é importante que toda a equipe possa obter

facilmente o estado do build e as mudanças que foram realizadas no

sistema. É recomentado que o servidor de Integração Contínua possa

apresentar tais informações por meio de um site que possa ser

visualizado de forma facilitada.

f. Automatização da implantação do sistema – para maior efetividade do

processo é necessário que os procedimentos de implantação do software

sejam automatizados de forma que permita sua execução em diversos

servidores, tais como ambiente de teste, homologação ou produção. Com

isso é minimizado o tempo de implantação e a incidência de erros.

De acordo com DUVALL, MATYAS e MATYAS (2007), a Integração Contínua

tem como alguns dos principais fundamentos: redução de riscos, redução de

processos manuais repetitivos e permitir melhor visibilidade do projeto.

24

A redução de riscos pode ser obtida devido à integração frequente do código,

o que possibilita a detecção prévia de defeitos mediante a inspeção automatizada do

código, pode-se obter informações de complexidade deste código a cada alteração,

também é possível coletar dados referentes à aderência a padrões de codificação,

cobertura de testes e duplicação de código. Devido à execução da construção do

software no servidor de Integração Contínua é possível prevenir que o sistema

mantenha referencias para elementos como artefatos e variáveis de ambiente

exclusivas do contexto do desenvolvedor.

Com a automatização de processos repetitivos como recuperação de código a

partir de um sistema de controle de versões, compilação, atualização de base de

dados, teste, inspeção, implantação e criação de uma etiqueta (tag) no sistema de

controle de versões, é possível que o processo seja executado toda vez que o

código for alterado e sempre com os mesmos passos e da mesma forma. Deste

modo as pessoas podem manter o foco em trabalhos de alto valor agregado. Outro

ponto importante é que o processo de build seja construído de tal forma que possa

ser executado a partir de um único comando.

Um serviço para Integração Contínua pode prover informações em tempo real

sobre status da construção, métricas de qualidade e defeitos. Também é possível

manter informações de tendências bem como outras informações por meio de

plugins.

De forma complementar FARLEY e HUMBLE (2014) observam que não é

necessário somente ter um processo de construção e implantação automatizado,

mas é importante que o mesmo abra a possibilidade de reverter uma implantação

sem sucesso. Caso contrário o ambiente produtivo será penalizado caso haja algum

imprevisto, seja por motivo de depuração de uma aplicação no ambiente ou mesmo

pela permanência do defeito. No entanto, é de suma importância observar relações

de dependência entre sistemas integrados, ou mesmo os impactos da implantação

no banco de dados, pois procedimentos de reversão da implantação podem ter

limitações relevantes.

25

2.4 RASTREABILIDADE DE ARTEFATOS NO PROCESSO DE MANUTENÇÃO DO

SOFTWARE

Conforme EDWARDS e HOWELL (1991), uma lista de requisitos corretos e

consistentes não garantem que o produto de software final estará de acordo com as

expectativas dos stakeholders. É necessário que o projeto do produto esteja

alinhado aos requisitos e posteriormente à implementação esteja coerente com o

que se espera. Com um processo provido de rastreabilidade é possível identificar

incoerências entre estas fases do desenvolvimento de software ou até mesmo

evidenciar a mudança de um requisito após o mesmo ter sido desenvolvimento no

produto.

A rastreabilidade de artefatos dá condições de auditoria de todas as

características de um sistema e saber que alterações foram efetuadas a partir de

uma requisição de mudança do produto. Ter um processo com rastreabilidade

possibilita saber qual requisito gerou uma determinada característica do sistema,

qual a origem de tal requisito, verificar se o projeto e a implementação foram

executados corretamente (HAMILTON e BEEBY, 1991).

Podem-se obter recursos de rastreabilidade no processo de desenvolvimento

de software de duas formas. Uma é a geração de links diretos na aplicação de

gerenciamento de configuração, de forma que seja possível, a partir de cliques,

navegar de um requisito para um registro de alteração no controle de versões, saber

qual foi o requisito que está associado a um conjunto de alterações de artefatos, ou

mesmo a partir do registro de uma construção do software visualizar as alterações

de código que estão contidas no mesmo. Outra forma é a obtenção de tais

informações por meio de relatórios e matrizes de relacionamento, dentre outros

(EDWARDS e HOWELL, 1991).

FARLEY e HUMBLE (2014) ressaltam ainda, a importância fundamental de

que o processo de Gerenciamento de Configuração possibilite que se consiga saber,

a partir de um binário em execução, qual a revisão no controle de versões deu

origem ao mesmo, de forma que, havendo a necessidade de correção de um

software que esteja em produção, seja possível fazê-la sem dispêndio de grande

esforço para obter o código fonte correspondente.

26

3 MATERIAL E MÉTODOS

Este capítulo apresenta as ferramentas que são utilizadas para aplicação dos

conceitos e técnicas, bem como a metodologia abordada neste trabalho. O capítulo

está dividido em cinco seções, sendo que a primeira expõe as ferramentas e a

segunda a metodologia utilizada, na terceira parte é apresentada a instalação destas

ferramentas, posteriormente a configuração inicial da mesma e finaliza com algumas

configurações adicionais para prover a rastreabilidade.

3.1 FERRAMENTAS

As ferramentas empregadas na abordagem prática deste trabalho são:

linguagens de programação Java e C#, sistema de controle de versão Git, servidor

de Integração Contínua Jenkins, gerenciador de projetos Redmine, plataforma para

gerenciamento de qualidade do código SonarQube, e Liquibase para controle de

versão de elementos de banco de dados. Tais ferramentas são apresentadas a

seguir.

3.1.1 Linguagem de Programação

A pesquisa realizada neste trabalho tem como base as linguagens de

programação Java2 e C#3. São duas das linguagens de programação mais utilizadas

profissionalmente, segundo o Índice TIOBE4 de 2014. De forma complementar

MOMBREA (2014), salienta que tais linguagens de programação são as mais

relevantes para desenvolvimento de sistemas em ambiente corporativo, e também

proporciona maior facilidade para o aprendizado de outras linguagens.

2 http://www.oracle.com/br/technologies/java/overview/index.html

3 http://msdn.microsoft.com/pt-br/library/67ef8sbd.aspx

4 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

27

3.1.1.1 Java

Conforme FLANAGAN (2005), Java é uma linguagem orientada a objeto com

sintaxe similar a C. É uma linguagem de implementação híbrida, ou seja, quando um

código fonte é compilado, ele é convertido em byte codes que são códigos binários

portáveis para qualquer arquitetura de hardware que possua uma máquina virtual

Java para interpretá-los.

Quando o Java é instalado para desenvolvimento de aplicações, o mesmo

disponibiliza um conjunto básico de classes APIs (Application Programming

Interface) para entrada/saída de dados, comunicação em rede, componentes de

interface gráfica, dentre outros que juntos formam a plataforma Java (FLANAGAN,

2005).

Como linguagem de programação, Java foi projetada para que

desenvolvedores escrevam programas robustos com facilidade (FLANAGAN, 2005).

3.1.1.2 C#

A linguagem de programação C# é orientada a objetos, possui sintaxe

simples, é considerada moderna e é semelhante a C++ ou Java. Esta linguagem

também tem por objetivo fornecer base para construção de aplicações robustas e

com longo tempo de vida (HEJLSBERG et al, 2011).

De acordo com HEJLSBERG et al (2011), C# também trabalha pelo modo de

implementação híbrido, ou seja, sua compilação gera um código intermediário

denominado .NET Common Language Interface, que é interpretado pelo .NET

Common Language Runtime.

28

3.1.2 Git

Como ferramenta open source para controle de versão, optou-se pelo Git5,

conforme recomendado por FOWLER (2010). Devido a sua característica de ser

distribuído permite uma utilização mais eficiente no acesso a logs históricos. Não é

necessário requisição ao repositório principal para toda consulta de log, pois todos

tem uma cópia completa do repositório consigo. O Git também favorece a

segurança, pois um novo membro que se junta à equipe pode trabalhar a partir de

um repositório de um desenvolvedor sênior da equipe de modo que este valide seus

desenvolvimentos e envia ao repositório central.

Git é um sistema de controle de versões distribuído, ou seja, todo check out

do repositório se torna uma cópia completa do repositório principal e pode ser

compartilhada com outros desenvolvedores. Conforme CHACON (2009), este

modelo de trabalho permite que diversas equipes possam trabalhar simultaneamente

no mesmo projeto.

A Figura 1 possibilita o melhor entendimento do modelo.

Figura 1 - Sistema de controle de versões distribuído

Fonte: CHACON (2009)

5 http://git-scm.com/

29

De acordo com CHACON (2009) o Git também possui uma forma de

execução de eventos que são disparados em alguns momentos quando são

realizados procedimentos nesta ferramenta. Estes eventos executam scripts que

podem ser customizados e são denominados hook scripts. Existem scripts que

podem ser executados quando ocorrem eventos no ambiente cliente, tais como

checar se uma mensagem de confirmação de alteração no código fonte foi escrita de

acordo com o padrão definido para o repositório. Também existem scripts que

podem ser executados no lado do servidor, antes ou depois do mesmo processar um

recebimento de alterações do código fonte.

Estes scripts do lado do servidor podem ser utilizados para acionar atividades

de Integração Contínua a cada alteração no repositório principal.

3.1.3 Jenkins

Para aplicação da Integração Contínua, foi escolhido o Jenkins6, que é uma

ferramenta open source, derivada do Hudson e escrita em Java. É uma ferramenta

utilizada por equipes de vários tamanhos e em projeto que fazem uso de diversas

tecnologias e linguagens de programação (SMART, 2011).

O Jenkins se propõe a ser fácil de usar, tem uma interface simples e intuitiva.

Esta ferramenta possui uma ampla comunidade, que desenvolve, adiciona novas

características e corrige bugs rapidamente, gerando novas versões constantemente.

No entanto para usuários e empresas que não são afetos a ciclos curtos de

atualizações, o Jenkins mantem um versão Long-Term Support (LTS) que garante

um tempo maior de vida para uma determinada versão, para a qual é disponibilizada

correções por um tempo diferenciado da versão padrão (SMART, 2011).

6 http://jenkins-ci.org/

30

3.1.4 Redmine

Para gerenciamento de projetos optou-se pelo Redmine7, que é uma

ferramenta open source escrita em Ruby on Rails. Esta ferramenta possui uma

variedade de recursos para auxiliar na condução de projetos, tais como: controle de

perfis de acesso, gráfico de Gantt, calendário, planejamento de versões e tarefas

necessárias para liberação destas, integração com sistema de controle de versões,

gerenciamento de documentos e notícias (LESYUK, 2013). O Redmine também

possui uma API de integração que permite à outras ferramentas desenvolver plugins

de integração para registrar suas atividades.

3.1.5 SonarQube

SonarQube8 é uma ferramenta open source que foi escolhido para apresentar

relatórios da qualidade do código. Trabalhando em conjunto com uma ferramenta de

Integração Contínua, pode-se conseguir grande melhora na qualidade do código.

Esta ferramenta aponta problemas de aderência a padrões de codificação

inseridos pelos desenvolvedores, cobertura de testes, duplicações de código,

documentação no código (como Javadoc), complexidade ciclomática, provendo

análises de evolução destas métricas (CAMPBELL e PAPAPETROU, 2014).

As informações registradas possibilitam um acompanhamento temporal da

evolução da qualidade do software e auditar quem e quando realizou alterações que

interferiram na qualidade da codificação.

7 http://www.redmine.org/

8 http://www.sonarqube.org/

31

3.1.6 Liquibase

Finalmente, foi utilizada a ferramenta open source Liquibase9 para dar suporte

ao versionamento de elementos do banco de dados. Esta ferramenta permite

armazenar todas as alterações em arquivo XML (eXtensible Markup Language),

fazer atualização de itens de banco de dados, bem como retroceder a um estado

anterior dos mesmos. O Liquibase possibilita a geração de arquivo com a diferença

de objetos entre dois bancos de dados, gerar um arquivo com objetos de um banco

de dados existente para ser transportado para outro ambiente, ou simplesmente

para gerar uma posição inicial de versionamento. Com o Liquibase é possível

realizar a alteração do banco de dados a partir da utilização de Ant, Maven, Servlet

ou mesmo linha de comando. Esta ferramenta trabalha com mais de dez sistemas

gerenciadores de banco de dados, dentre os quais estão: Oracle, Microsoft SQL

Server e MySQL.

3.2 METODOLOGIA

A apresentação da metodologia utilizada está dividida em três seções, sendo

que a primeira trata do cenário de integração continua utilizada, a configuração do

ambiente para validação e finalmente a construção do protótipo.

3.2.1 Cenário de Integração Contínua

Além do sistema utilizado como protótipo foi montado um cenário de

Integração Contínua com um servidor para gerenciamento do ciclo de vida de

aplicações. Neste servidor foram instaladas as ferramentas a serem avaliadas: Git,

9 http://www.liquibase.org/

32

Liquibase, Jenkins, Redmine, SonarQube, Java e .Net. A Figura 2 ilustra as

comunicações entre os sistemas para Integração Contínua.

Figura 2 - Intercomunicação entre serviços

Fonte: Autoria própria.

A Figura 2 apresenta as seguintes atividades de processo de

desenvolvimento:

a. Inicialmente ocorre à construção do software na máquina do

desenvolvedor e o este utiliza um conjunto de bibliotecas de código

disponibilizadas para desenvolvimento;

b. Cada biblioteca utilizada na construção do software é obtida a partir de

um repositório, e é utilizado um recurso de resolução de dependências

apropriado para a tecnologia, que pode ser Maven10 para o ambiente Java

ou NuGet11 para .Net;

10

http://maven.apache.org/ 11

https://www.nuget.org/

33

c. Após ter desenvolvido os requisitos e realizado uma construção com

sucesso, o desenvolvedor confirma as alterações no serviço repositório de

fontes, onde é realizado o controle de versões;

d. O repositório de fontes notifica o servidor de Integração Contínua de que

houve uma mudança no código fonte;

e. É iniciado um trabalho no servidor de Integração Contínua que obtém os

códigos do programa, efetua a construção com resolução de

dependências no mesmo mecanismo utilizado pelo desenvolvedor

anteriormente;

f. Na sequência é feito atualização dos objetos do banco de dados para a

última versão por meio do Liquibase;

g. Depois é processada a análise para coleta de métricas pelo SonarQube,

onde se obtém dados como: cumprimento de padrões de codificação,

comentários e documentação de código, complexidade ciclomática, dentre

outros; e

h. Finalmente, caso seja necessário, é realizada a implantação do software

no devido servidor de aplicação que lhe for conveniente.

3.2.2 Configuração do Ambiente para Desenvolvimento

Após a configuração das ferramentas, foram realizados os seguintes

procedimentos:

a. Abertura de projeto no sistema de gerenciamento de projetos Redmine;

b. Registro de requisitos e atividades de desenvolvimento no sistema de

gerenciamento de projetos;

c. Associação de tarefas de desenvolvimento aos membros da equipe;

d. Abertura de um projeto no sistema de controle de versões Git;

e. Criação do fluxo de trabalho para implantação do software, no Jenkins,

com atividades a serem realizadas no momento da disponibilização do

software em ambiente de desenvolvimento, ambiente de qualificação

(homologação) e ambiente produtivo;

34

f. Desenvolvimento do software protótipo (apresentado na seção 3.2.3) e

utilização do sistema de versionamento de software;

g. Realização de alterações no software e confirmação das alterações no

controle de versão;

Os resultados destas etapas contribuirão para rastreabilidade do processo de

desenvolvimento, conforme apresentado no Capítulo 4 deste trabalho.

3.2.3 Construção do Protótipo

Para demonstrar a metodologia deste trabalho, é utilizado um exemplo

ilustrativo de um sistema simples de pedidos. O sistema possui apenas uma tela de

pedidos de venda e seus cadastros correlatos, conforme especificação apresentada

a seguir.

A Figura 3 apresenta o diagrama das classes de entidades a utilizadas no

desenvolvimento do protótipo. A representação dos métodos foi omitida para

possibilitar o melhor entendimento do modelo.

Figura 3 - Diagrama de classes do sistema de pedidos de venda


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


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


36

3.3 INSTALAÇÃO DAS FERRAMENTAS

O conteúdo desta seção mostra informações relevantes sobre a instalação e

configuração do conjunto de ferramentas, sendo elas: o sistema operacional

Windows, plataforma de desenvolvimento, sistema de controle de versões Git,

sistema para gerenciamento de projetos Redmine, sistema para métricas de

software SonarQube, e sistema para Integração Contínua Jenkins.

3.3.1 Sistema Operacional Windows

A instalação das ferramentas é realizada em servidor com sistema

operacional Microsoft Windows 2008 R2 com arquitetura de 64 bits executando em

uma máquina virtual na plataforma VMware Workstation. Esta máquina virtual possui

dois núcleos de processamento, contém 1,5 gigabytes de memória e executa sob o

endereço IP 192.168.118.137.

O sistema operacional Windows foi utilizado para possibilitar a demonstração

das ferramentas tanto para plataforma Java quando para Microsoft .Net. Para

equipes dedicadas exclusivamente a plataforma Java, todas as ferramentas de base

poderiam ser instaladas em sistema operacional Linux.

Neste servidor, foi configurado o Microsoft Active Directory para gerenciar

autenticações de forma centralizada para todas as ferramentas utilizadas neste

trabalho, favorecendo desta forma a rastreabilidade.

O domínio configurado é apresentado na Figura 6, conforme a seguir:

37

Figura 6 - Domínio Microsoft Active Directory


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


3.3.2 Instalação da Plataforma Java

A preparação do ambiente para execução da plataforma Java foi segmentado

em três etapas, sendo elas:

a. Instalação do kit de desenvolvimento;

b. Instalação da ferramenta para automação de compilação

c. Instalação do servidor de aplicações; e

d. Instalação da ferramenta de desenvolvimento.

38

As três primeiras foram executadas no ambiente de desenvolvimento e no

servidor, a quarta etapa foi executada apenas no ambiente de desenvolvimento. Tais

etapas são descritas a seguir.

3.3.2.1 Kit de Desenvolvimento Java

Para execução dos procedimentos deste trabalho optou-se pela última versão

estável, para arquitetura de 64 bits, do ambiente de desenvolvimento Java também

conhecida com Java Development Kit (JDK) que é a JDK 7u5112.

O instalador foi executado seguindo as configurações padrão, tendo apenas o

diretório de instalação modificado para C:\Server\jdk1.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


12

http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html

39

De forma complementar também foi adicionado o endereço

%JAVA_HOME%\bin à variável de ambiente Path, conforme Figura 8.

Figura 8 - Variável de ambiente Path com JDK


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:\Server\apache-maven-3.2.1.

De forma complementar também foi necessário a criação de uma variável de

ambiente denominada M2_HOME, cujo valor é o caminho do diretório de instalação da

ferramenta. Para finalizar a instalação do Maven foi adicionado o valor

%M2_HOME%\bin à variável de ambiente PATH. Os procedimentos para a criação

destas variáveis foram omitidos, pois são similares aos apresentados na seção

3.3.2.1.

13

http://maven.apache.org/download.cgi

40

3.3.2.3 Servidor de Aplicações

Também foi instalado o software Wildfly para ser utilizado como servidor de

aplicações Java Enterprise Edition. Este software é o sucessor do JBoss14, que

assim era chamado até a versão 7. O mesmo foi obtido através do site do

desenvolvedor15 e sua instalação foi realizada por meio da descompactação do

arquivo no diretório C:\Server\wildfly-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 “standalone\condiguration\standalone.xml”, sob o diretório de

instalação do Wildfly.

14

http://jbossas.jboss.org/ 15

http://wildfly.org/downloads/

41

Quadro 1 - Configuração de endereço e porta TCP/IP para o Wildfly

O Quadro 2 apresenta a execução dos comandos necessários para a

realização destas configurações.

Quadro 2 - Configuração inicial do Wildfly

3.3.2.4 Ambiente de Desenvolvimento

Para ambiente de desenvolvimento na plataforma Java optou-se pela

ferramenta open source Eclipse IDE for Java EE Developers, sendo que foi utilizada

42

a versão 4.3.2 obtida no endereço oficial16. Para instalação da mesma foi apenas

descompactado o arquivo obtido em uma pasta local denominada

c:\java\eclipse. Qualquer outra ferramenta poderia ter sido utilizada sem

impactar o resultado do processo de desenvolvimento.

Foi necessária também a instalação do plugin JBoss Tools17 para integração

do ambiente de desenvolvimento com o servidor de aplicações Wildfly. Para

instalação deste plugin foi acessado o menu “Help” do Eclipse e acessado a opção

“Eclipse Market Place”. Nesta tela foi realizado a busca pelas palavras “JBoss Tools”

e selecionado a opção de instalação para o item “JBoss Tools (Kepler) 4.1.2 Final”.

3.3.3 Instalação da Plataforma .Net

A preparação do ambiente para execução de aplicações .Net foi divida em

quatro etapas, sendo elas:

a. Instalação framework .Net;

b. Instalação do ambiente de desenvolvimento;

c. Preparação para integração contínua; e

d. Instalação do servidor de aplicações.

As etapas “a” e “b” foram no ambiente de desenvolvimento e no lado do

servidor foram executadas todas as etapas, com exceção do item “b”.

16

https://www.eclipse.org/downloads/ 17

http://tools.jboss.org/

43

3.3.3.1 Framework .Net

Para esta plataforma que é base para a linguagem C#, foi obtido o instalador

do Microsoft .Net Framework 4.518. Os procedimentos de instalação seguiram

configurações padrão sugeridas pelo próprio instalador.

3.3.3.2 Ambiente de Desenvolvimento

A instalação do ambiente de desenvolvimento foi realizada a partir da mídia

da versão Visual Studio Professional 2012 obtida a partir do site Microsoft

DreamSpark for Academic Institutions. Sua instalação seguiu com todas as

configurações padrão.

3.3.3.3 Preparação para a Integração Contínua

Para realizar a compilação do projeto no servidor foi necessário instalar o

Windows Software Development Kit for Windows 819 e o Microsoft Visual Studio

Express 2012 for Web20. O processo de compilação necessita de algumas

bibliotecas e referências que são próprias da ferramenta de desenvolvimento e não

são instaladas com o framework .Net. Ambas as ferramentas foram instaladas a

partir de suas opções padrão.

No ambiente do servidor também foi necessário realizar a instalação do

Microsoft Web Deploy v3.521 para possibilitar a automação de implantação de

aplicações no servidor web Internet Information Services. Este utilitário foi instalado

com uso de suas configurações padrão.

18

http://www.microsoft.com/pt-br/download/details.aspx?id=40779 19

http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx 20

http://www.microsoft.com/en-us/download/details.aspx?id=30669

44

3.3.3.4 Servidor de Aplicações

Para possibilitar a execução da aplicação em ASP.Net no servidor, também

foi preciso instalar o servidor Internet Information Services. Para isso foi necessário

acessar a opção “Server Manager” (Gerenciador do Servidor) a partir do menu de

ferramentas administrativas do Windows e adicionar o papel (role) de Web Server ao

servidor Windows, marcando as opções apropriadas para ASP.Net, de acordo com a

Figura 9.

Figura 9 - Instalação do Microsoft Information Services


Também foi necessário alterar a configuração do site padrão do Internet

Information Services para executar na porta TCP/IP 8888, pois a porta padrão 80

seria utilizada pelo servidor web Apache para a execução do Redmine. De forma

complementar também foi alterado o site padrão para utilizar o Application Pool

baseado no Framewok .Net 4, conforme Figura 10.

21

http://www.microsoft.com/en-us/download/details.aspx?id=39277

45

Figura 10 - Configuração do application pool para o site padrão


Finalmente, para conexão com banco de dados MySQL utilizado no

desenvolvimento do protótipo, se fez necessário a instalação do driver apropriado, o

qual foi obtido no site oficial22 e instalado utilizando suas configurações padrão.

3.3.4 Instalação do Sistema Controle de Versões Git

Foram utilizadas quatro ferramentas para possibilizar a geração de

rastreabilidade a partir do controle de versões. Sendo elas apresentadas a seguir.

22

http://dev.mysql.com/downloads/connector/net/

46

3.3.4.1 Git

Este é o mecanismo de controle de versões propriamente dito, o qual teve

sua versão 1.9.0 para sistema operacional Microsoft Windows obtida a partir do

site do Git23.

No servidor, este software foi instalado seguindo suas opções padrão, com

exceção do diretório de instalação, que foi modificado para c:\Server\Git e

adicionado o caminho C:\Server\Git\cmd à variável de ambiente Path no

Windows conforme Figura 11.

Figura 11 - Variável de ambiente Path


No ambiente cliente todas as opções padrão foram mantidas.

23

http://git-scm.com/download

47

3.3.4.2 Gitblit

Este software disponibiliza uma interface web para visualização e

gerenciamento dos repositórios de fontes no servidor, sendo utilizada a versão

1.4.0 Gitblit GO 24 para Microsoft Windows.

A instalação do Gitblit foi realizada a partir da descompactação do arquivo

obtido para o diretório c:\Server\gitblit-1.4.0, e configuração da porta de

execução do serviço no arquivo data\gitblit.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:\Server\Repositórios e parametrizado no arquivo de configuração do serviço, de

acordo com Quadro 4.

Quadro 4 - Configuração de diretório base para repositórios

24

http://gitblit.com

48

Para configuração do mecanismo de autenticação do Gitblit com Microsoft

Active Directory, foi configurado o provedor de autenticação para o protocolo

Lightweight Directory Access Protocol (LDAP) de acordo com Quadro 5.

Quadro 5 - Configuração do mecanismo de autenticação LDAP no Gitblit

De forma complementar também foram configurados os parâmetros para

acesso ao do Gitblit ao domínio do Active Directory, indicando o endereço do

servidor, configuração do domínio, usuário para leitura do servidor de domínio no

momento da autenticação, e grupo de usuários administradores da ferramenta

Gitblit. O Quadro 6 mostra as configurações realizadas no arquivo

gitiblit.properties.

Quadro 6 - Parâmetros para autenticação no Microsoft Active Directory

Após estas configurações, foi necessário instalar o serviço do Windows

responsável pela execução do Gitblit, por meio do comando instalService. Este

comando é disponibilizado no diretório de instalação do mesmo, conforme Quadro 7.

49

Quadro 7 - Instalação do serviço Windows para o Gitblit

Posteriormente foi necessário configurar o Gitblit para execução por meio de

serviço do Windows, onde foi necessário executar o aplicativo gitblitw.exe

contido no diretório de instalação do software (neste caso c:\Server\gitblit-

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


50

Após estas configurações foi possível iniciar o serviço do Windows e acessar

a interface da ferramenta por meio do endereço http://ip_do_servidor:8181.

3.3.4.3 TortoiseGit

Este é um aplicativo utilizado para cliente do servidor Git, permitindo a

realização de todas as operações necessárias, relacionadas ao controle de versões

no ambiente de desenvolvimento. Para este aplicativo foi utilizada a versão 1.8.7

para 64 bits25. Este programa foi instalado no lado cliente mantendo as opções

padrão do instalador.

3.3.4.4 TurtleMine

O TurtleMine26 é um plugin para integração do TortoiseGit com as tarefas

existentes no sistema de gerenciamento de projetos Redmine, sendo que para este

trabalho foi utilizado em sua versão 1.2.0.1 para 64 bits. De forma semelhante ao

TortoiseGit, este aplicativo também foi instalado com suas configurações padrão.

3.3.5 Instalação do Redmine

Para preparação do sistema Redmine, optou-se pela utilização do instalador

Bitnami Redmine Stack disponibilizado no site oficial27 em sua versão v2.5.0. Este

instalador é pré-configurado com todo conjunto de infraestrutura necessária para

execução do Redmine, tais como servidor web Apache, linguagem de programação

Ruby com framework Rails e banco de dados MySQL.

25

https://code.google.com/p/tortoisegit 26

https://code.google.com/p/turtlemine/ 27

http://bitnami.com/stack/redmine

51

O instalador Bitnami foi executado mantendo-se todas as opções padrão, de

modo que apenas o diretório c:\Server foi indicado como destino da instalação.

Após a instalação foi acessada a interface da ferramenta por meio do

endereço http://ip_do_servidor/redmine com as credenciais de

administrador, que foram definidas no momento da instalação da mesma. Realizou-

se então a configuração mecanismo de autenticação a partir do Microsoft Active

Directory conforme Figura 13

Figura 13 - Configuração de para autenticação do Redmine


Também foi realizada a configuração de uma conta de usuário a ser utilizada

durante as atividades desenvolvidas neste trabalho. Conforme apresentado na

Figura 14.

52

Figura 14 - Configuração de usuário para atividades de desenvolvimento


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:\Server\Jenkins.

Com a instalação desta ferramenta concluída, foi inicializado o serviço do

Windows referente à mesma e acessado a interface desta através do endereço

http://ip_do_servidor:8080.

Como em todos os serviços anteriormente mencionados, foi realizada a

configuração do mecanismo de autenticação para que o Jenkins utilize o mecanismo

Microsoft Active Directory para validar senhas de usuário. A Figura 15 apresenta as

configurações efetuadas na seção de “Configuração de Segurança Global” acessada

pelo menu “Gerenciar o Jenkins”.

28

http://jenkins-ci.org/

53

Figura 15 - Configuração de autenticação do Jenkins


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


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


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:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe


A configuração para utilização da plataforma Java foi feita por meio do item

“JDK”, que está presenta na seção de gerenciamento de configurações do Jenkins.

A Tabela 4 mostra os parâmetros informados.

55

Tabela 4 - Parâmetros para utilização da plataforma Java

Parâmetro Valor

Nome JDK 8

JAVA_HOME C:\Server\jdk1.8.0_05_x64


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


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:\Server\sonar-runner-2.3


Para utilização do Maven para compilação de aplicações Java se fez

necessário a configuração referente plugin no item “Maven” na seção de

gerenciamento do Jenkins. A Tabela 7 apresenta esta configuração.

56

Tabela 7 - Parâmetros para o plugin Maven

Parâmetro Valor

Nome Maven-3.2.1

MAVEN_HOME C:\Server\apache-maven-3.2.1


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:\Server\sonar-3.7.4.

Após este procedimento foi editado o arquivo c:\Server\sonar-

3.7.4\etc\wrapper.conf e adicionado a configuração no inicio do arquivo para

indicar o diretório temporário a ser utilizado pelo serviço, conforme Quadro 8. Caso

esta alteração não seja realizada, ocorrerá um erro ao inicializar o serviço, pois o

mesmo tentará criar um diretório temporário dentro de um diretório do sistema.

Quadro 8 - Configuração de diretório temporário para o SonarQube

Também foi instalado o serviço do Windows responsável pela execução do

SonarQube e inicializado o mesmo posteriormente. O Quadro 9 apresenta os

comandos executados para realizar esta atividade.

29

http://www.sonarqube.org/

57

Quadro 9 - Instalação do serviço para o SonarQube e inicialização.

Após realização destes procedimentos a interface do SonarQube pode ser

acessada pelo endereço http://ip_do_servidor:9000.

Para melhor aderência da ferramenta a este trabalho foram utilizados alguns

plugins, os quais estão definidos na Tabela 8.

Tabela 8 - Lista de plugins instalados no SonarQube

Nome Descrição

C# Módulo para linguagem C#

.NET Módulo para plataforma .Net

Java Módulo para suportar linguagem Java

LDAP Módulo para autenticação no Microsoft Active Directory

SCM Activity Módulo para coletar estatísticas do controle de versões


O Quadro 10 apresenta as configurações efetuadas para que o SonarQube

faça autenticação contra o domínio Active Directory, como as demais ferramentas

utilizadas neste trabalho. Nesta parametrização é indicando o endereço do servidor,

configuração do domínio, usuário para leitura do servidor de domínio no momento da

autenticação. O Quadro 10 mostra as configurações realizadas no arquivo

sonar.properties que está no diretório conf sob o diretório de instalação do

SonarQube.

58

Quadro 10 - Configuração do mecanismo de autenticação do SonarQube

Com estas configurações foi necessário renomear os grupos de usuário

padrão do SonarQube para que fosse possível também a sincronização destes com

o Active Directory. O grupo sonar-administrators passou a se chamar

administradores e o grupo sonar-users passou para usuários.

Para realização da análise do código é necessário também o uso do utilitário

Sonar Runner30. Neste trabalho foi utilizada a versão 2.4 deste software. Sua

instalação foi realizada por meio da descompactação do arquivo zip no diretório

c:\Server\sonar-runner-2.4.

Finalmente, a ferramenta está pronta para computar métricas do projeto a

partir do Jenkins.

30

http://docs.codehaus.org/display/SONAR/Installing+and+Configuring+SonarQube+Runner

59

3.3.8 Instalação do Liquibase

Para instalação do Liquibase31 foi necessário apenas obter o arquivo da

versão 3.1.1 e descompactá-lo no diretório c:\Server\Liquibase. Esta

ferramenta precisa que haja uma biblioteca Java para conexão ao banco de dados

(driver JDBC – Java Database Connectivity) no subdiretório lib dentro do diretório

de instalação. Para este trabalho foi utilizado o driver MySQL Connector 5.1.3032

para conexão ao banco de dados MySQL SQL Server. Este serviço foi utilizado para

manter compatibilidade da implementação dos protótipos em Java e C#. Qualquer

banco de dados relacional suportado pela plataforma Java poderia ser utilizado.

3.4 CONFIGURAÇÃO DO PROJETO

Esta seção descreve os procedimentos realizados em todas as ferramentas

abordadas para configuração do projeto de sistema realizado neste trabalho.

3.4.1 Criação de Repositório de Código Fonte

Foi acessada a interface do Gitblit, conforme descrito na seção anterior, foram

criados dois repositórios de fontes, sendo um para realizar o controle de versões do

protótipo na plataforma Java e outro para armazenar os códigos do protótipo na

plataforma .Net. A Figura 17 apresenta os repositórios criados no Gitblit.

31

http://www.liquibase.org/download/index.html 32

http://dev.mysql.com/downloads/connector/j/

60

Figura 17 - Repositório para controle de versões dos protótipos


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


Depois de efetuado a cópia do endereço, é necessário acessar a opção “Git

clone” do menu de contexto do Windows a partir de um diretório vazio, conforme

Figura 19.

61

Figura 19 - Opção Git Clone


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


Neste momento é necessário confirmar a operação de clone do repositório e

aguardar sua conclusão, momento em que o repositório já estará pronto para

receber os arquivos do projeto de software.

62

3.4.2 Configuração do Projeto e Tarefas de Desenvolvimento

Após a configuração inicial do sistema foram abertos dois projetos no

Redmine, sendo uma para o protótipo na plataforma .Net e outro para o protótipo na

plataforma Java. A Figura 21 apresenta tela de abertura de projeto nesta ferramenta,

para o protótipo para a plataforma .Net.

Figura 21 - Abertura do projeto para o protótipo no Redmine


Tendo sido aberto o novo projeto, foi adicionado o usuário “desenv” com o

papel de “gerente”. Também foram abertas versões do projeto a serem

desenvolvidas, conforme Tabela 9.

63

Tabela 9 - Tabela de versões criadas para o projeto

Nome Descrição

Versão 1 - Cadastro Versão para entrega dos cadastros básicos

Versão 2 - Lançamento Versão para entrega do lançamento de pedidos


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


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


64

Após estes procedimentos terem sido concluídos, foi realizada uma cópia

deste projeto, para que fosse possível ter o projeto idêntico para o protótipo a ser

desenvolvido na plataforma Java. Neste procedimento foram necessárias alterações

nos campos destinados à informação do nome do projeto e sua descrição, bem

como na parametrização do repositório de códigos fontes. Estas alterações foram

realizadas apenas para manter a correta referência para o projeto destinado ao

protótipo na plataforma Java.

3.4.3 Configuração de Trabalhos no Jenkins

Foram criados três trabalhos no Jenkins para cada protótipo desenvolvido

sendo um em Java e outro em C#. As seções a seguir descrevem o conteúdo de

cada trabalho.

3.4.3.1 Trabalho para o Ambiente de Desenvolvimento

O primeiro trabalho é executado no ambiente de desenvolvimento quando o

controle de versão notifica uma mudança no código fonte da aplicação e efetua os

seguintes passos:

a. Obtêm-se os códigos fontes do sistema;

b. Realiza-se a compilação dos códigos fontes;

c. Atualizam-se os objetos de banco de dados com o Liquibase;

d. Implanta-se a nova versão do sistema no servidor de desenvolvimento;

e. Coletam-se as métricas do código fonte pelo SonarQube; e

f. Arquivam-se os artefatos para posterior implantação no ambiente de

homologação e produto.

65

Além dos passos citados, o trabalho Jenkins de desenvolvimento também tem

a configuração de uma seção de promoção, onde foi configurada a promoção para

homologação e para produção. Os passos a serem executados neste caso são:

a. Executa-se o trabalho apropriado para a promoção, no caso o segundo

(de homologação) ou terceiro (de produção);

b. Adiciona-se uma tag ou marcação no controle de versões registrando que

a determinada versão do código fonte foi implantada no ambiente de

homologação ou de produção; e

c. Marca-se o build para ser arquivado de forma permanente.

O Apêndice A apresenta a configuração do primeiro trabalho do Jenkins para

o sistema em C# e o Apêndice B apresenta as referentes configurações para o

sistema em Java.

3.4.3.2 Trabalho para o Ambiente de Homologação

O segundo trabalho é executado a partir de uma promoção para homologação

do primeiro trabalho. Neste momento as seguintes etapas são executadas:

a. Obtém-se uma cópia do binário implantado no ambiente de

desenvolvimento, bem como os arquivos Liquibase com o conjunto de

alterações aplicado no banco de dados;

b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de

homologação;

c. Implanta-se a aplicação no servidor de homologação; e

d. Arquivam-se os artefatos utilizados para possível auditoria.

O Apêndice C apresenta a configuração do segundo trabalho do Jenkins para

o sistema em C# e o Apêndice C apresenta as referentes configurações para o

sistema em Java.

66

3.4.3.3 Trabalho para o Ambiente de Produção

O terceiro trabalho é executado a partir de uma promoção para produção do

primeiro trabalho. Neste momento as seguintes etapas são executadas:

a. Obtém-se uma cópia do binário implantado no ambiente de

desenvolvimento, bem como os arquivos Liquibase com o conjunto de

alterações aplicado no banco de dados;

b. Realiza-se a atualização do banco de dados utilizado pelo ambiente de

produção;

c. Implanta-se a aplicação no servidor de produção; e

d. Arquivam-se os artefatos utilizados para possível auditoria.

As configurações do terceiro trabalho do Jenkins não foram anexadas, pois

são baseadas no segundo trabalho e tem os mesmos passos. As alterações

realizadas para criação do terceiro trabalho são apenas no que se refere aos nomes

de servidores, para que os artefatos tenham como destino o servidor de produção.

3.4.3.4 Preparação de Projetos .Net para a Integração Contínua

Para possibilitar a compilação do projeto .Net é necessário ativar a opção

“Enable NuGet Package Restore” na solução .Net, conforme Figura 23:

67

Figura 23 - Ativação da restauração de pacotes NuGet.


De maneira complementar, é necessário alterar o arquivo “nuget.targets”

que foi criado no diretório “.nuget” para que o parâmetro “DownloadNugetExe”

fique conforme a linha apresentada no Quadro 11.

Quadro 11 - Habilitação de download de executável NuGet.

3.5 CONFIGURAÇÕES ADICIONAIS PARA RASTREABILIDADE

Esta seção aborda alguns procedimentos necessários para que as

ferramentas permitam a automação de atividades necessárias para garantir a

rastreabilidade e Integração Contínua.

3.5.1 Seleção de Tarefas do Redmine para Commit no Git

Para a utilização do plugin TurtleMine juntamente com o Redmine, é

necessário efetuar a configuração do mesmo para visualizar as tarefas cadastradas

68

para o projeto. É necessário acessar o Redmine, e copiar o link para visualização da

listagem de tarefas em formato Atom, conforme Figura 24.

Figura 24 - Link para visualização de lista de tarefas em formato Atom


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


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


A partir da conclusão destas alterações, será disponibilizado um botão na tela

de commit do Tortoise, conforme apresentado na Figura 27, para que seja possível

escolher a tarefa do Redmine que está associada ao mesmo.

70

Figura 27 - Botão de acesso à lista de tarefas no TortoiseGit


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


A tarefa selecionada será vinculada ao commit realizado conforme Figura 29.

Isto irá gerar o primeiro vinculo de rastreabilidade que poderá ser visualizado na tela

do Gitblit, do Redmine e do Jenkins, conforme será apresentado no Capítulo 4 deste

trabalho.

71

Figura 29 - Tarefa do Redmine associada ao commit no Git


3.5.2 Associação de Mensagens de Commit com Tarefas do Redmine a partir do

Gitblit

Com o ajuste da configuração do Gitblit demonstrado no Quadro 12 é possível

gerar um link para que na interface do Gitblit para acesso direto a tarefa do Redmine

vinculada ao commit.

Quadro 12 - Configuração de link entre o Gitblit e o Redmine

Desta forma a tela de visualização de commits no Gitblit terá no cabeçalho um

link para a tarefa do Redmine, que é apresentado na Figura 30

72

Figura 30 - Link do Gitblit para o Redmine


3.5.3 Associação de Mensagem de Commit com Tarefas do Redmine a partir do

Redmine

Os procedimentos citados anteriormente garantem a manutenção de uma

ligação entre uma confirmação de alteração de código fonte no controle de versão

com uma atividade do Redmine. No entanto, também é possível gerar a associação

de uma tarefa do Redmine com todos os commits relacionados à mesma. Para

viabilizar isto é necessário configurar quais palavras chaves presentes na

mensagem de commit deverão ser consideradas. Isto deve ser feito por meio do

painel administrativo do sistema Redmine, na seção “Repositórios” no parâmetro

“Palavras-chaves de referencia”, apresentado na Figura 31. Desta forma, todos os

commits contendo qualquer uma destas palavras chaves serão vinculados a

referente tarefa.

73

Figura 31 - Palavras-chaves de referência


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


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 “data\groovy”,

dentro do diretório de instalação da ferramenta.

3.5.4.1 Script para Comunicação de Commit ao Redmine

A instalação do Gitblit disponibiliza um hook script com nome redmine-

fetch.groovy , onde podem ser realizadas as configurações para comunicação

com o serviço Redmine. O Quadro 13 mostra os ajustes realizados neste script para

utilização neste trabalho.

Quadro 13 - Configuração do hook script redmine-fetch

O valor da chave de acesso ao Redmine (API-Key) utilizado nesta

configuração precisa ser gerado por meio do painel administrativo do próprio sistema

75

Redmine, na seção “Repositórios” onde se deve marcar as opções apresentadas na

Figura 33 e executar o comando “Gerar uma chave”, conforme a seguir.

Figura 33 - Parâmetros de acesso aos serviços do Redmine


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


Feito estas configurações, as associações mencionadas na seção 3.5.3

estarão sendo concretizadas de forma automática.

76

3.5.4.2 Script para Execução de Trabalhos no Jenkins

Outro hook script disponibilizado pelo Gitblit é o jenkins.groovy, onde

podem ser realizadas as configurações necessárias para que o mesmo acione a

execução de trabalhos do Jenkins. Este script ativará a execução de trabalhos que

estão configurados para utilizar repositórios de código fonte que estão no Gitblit. O

Quadro 14 mostra os ajustes realizados neste script para utilização neste trabalho.

Quadro 14 - Configuração do hook script Jenkins

Para ativar a execução deste script é necessário editar o repositório no Gitblit

e marcar o referente hook script como selecionado, conforme mencionado

anteriormente na Figura 34.

77

4 RESULTADOS E DISCUSSÕES

A apresentação dos resultados obtidos neste trabalho foi organizada em

algumas seções de análise, sendo elas para: Redmine, Gitblit, Jenkins, Liquibase e

SonarQube. De forma complementar existem duas seções que apresentam a

composição da rastreabilidade no processo e a matriz de rastreabilidade de artefatos

e conclusão final.

4.1 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO REDMINE

Para o objetivo desta pesquisa, a única informação provida pelo Redmine que

foi utilizada para rastreabilidade é a listagem de revisões associadas a cada tarefa,

conforme apresentado na Figura 35. A partir desta listagem é possível obter as

revisões do controle de versão que foram originadas desta tarefa.

Figura 35 - Relação de revisões do repositório de fontes com tarefa do Redmine


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


33

https://wiki.jenkins-ci.org/display/JENKINS/Redmine+Plugin

79

Quando é selecionada uma determinada confirmação de alteração de fontes

para visualização de detalhes, é possível obter outras informações relevantes para a

rastreabilidade do desenvolvimento. A Figura 37 apresenta estas informações e na

sequência são apresentados os significados de cada informação.

Figura 37 - Detalhe de confirmação de alteração no código fonte


As informações apresentadas na Figura 37 são as seguintes:

a. Etiquetas que indicam data e hora, bem como qual instância de trabalho

do Jenkins utilizou esta revisão do código fonte em uma promoção para

homologação ou produção;

b. Data e hora da confirmação de alteração no repositório de código fonte;

c. Dados do desenvolvedor que confirmou a alteração no repositório;

d. Descrição da mensagem de confirmação da alteração contendo um link

diretor para a tarefa do Redmine mencionada; e

e. Lista de artefatos alterados nesta revisão do controle versões.

80

4.3 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO JENKINS

O acompanhamento da rastreabilidade do processo de software partindo-se

do produto final entregue pode ser iniciado a partir do Jenkins. Ao acessar a tela

principal deste, pode-se visualizar a listagem de todos os trabalhos configurados no

sistema, conforme Figura 38.

Figura 38 - Tela principal do Jenkins


Acessando o trabalho principal (neste caso o trabalho “Prototipo”), pode-se

verificar as informações conforme apresentado na Figura 39.

81

Figura 39 - Painel principal de um trabalho Jenkins


Nesta tela é possível visualizar as seguintes informações:

a. Lista com histórico das construções realizadas com seus referentes

número de identificação, data da realização, e ainda alguns ícones, sendo

que a estrela azul indica que aquela instância do trabalho foi promovida

para homologação, a estrela verde indica que a instância do trabalho foi

promovida para produção, o cadeado informa que os dados arquivados

nesta instância do trabalho não será apagado, e o último ícone azul em

82

formato de meia lua indica que aquela instância do trabalho foi analisada

pelo SonarQube.

b. Conjunto de links para os artefatos arquivados na última construção. Tais

artefatos podem ser resgatados novamente para fins de auditoria.

c. Link para listagem de alterações de código fonte que estão contidas na

última instância do trabalho Jenkins executado.

d. Lista de projetos filhos que serão executados a partir do trabalho Jenkins

atual.

e. Link para o endereço do projeto Redmine relacionado ao trabalho

Jenkins.

f. Listagem de promoções do trabalho atual. Permite verificar data e hora

que houve as promoções do trabalho Jenkins para os ambientes de

homologação e produção.

g. Link para acessar as métricas do software referenciado no trabalho

Jenkins atual.

Ao selecionar uma instância de trabalho do Jenkins será apresentada a tela,

conforme Figura 40, com detalhes daquela construção.

Figura 40 - Detalhe de uma construção do Jenkins


83

Na Figura 40 foram destacadas algumas áreas da tela, conforme segue:

a. Artefatos gerados ou utilizados na construção que foram arquivados para

gerar evidências e possibilitar auditoria;

b. Lista de confirmações de alterações de fontes que foram enviadas ao

controle de versões e que acionaram e execução do trabalho Jenkins,

com links para visualização de detalhes das mesmas, tarefa do Redmine

relacionada e visualização de detalhes diretamente no sistema de

controle de versões Gitblit;

c. Indicativo de que a instância do trabalho atual foi acionada a partir de uma

alteração no controle de versões;

d. Informação sobre qual foi a revisão do controle de versões utilizada para

este instância do trabalho;

e. Links para acessar a listagem de todas as confirmações de alterações no

controle de versão, bem como seus detalhes;

f. Apresentação das saídas de linha de comando que foram geradas a partir

da execução da instância atual do trabalho do Jenkins;

g. Link para acessar a relação de trabalhos dependentes (neste caso

trabalho de Homologação e Produção). Também são apresentados seus

status de execução e, caso já tenham sido executado, a data e hora de

execução e seu referente status; e

h. Lista de promoções executadas para a instância atual do trabalho

Jenkins.

4.4 ANÁLISE DAS INFORMAÇÕES PROVIDAS PELO LIQUIBASE

Com a execução do conjunto de alterações configuradas para execução do

Liquibase (Apêndices E, F, G, H, I e J), o trabalho configurado no Jenkins

sincronizou os objetos de banco de dados e gerou algumas informações relevantes

para a auditoria de alterações no banco de dados.

84

Todas as alterações realizadas pelo Liquibase são registradas em uma tabela

do banco de dados nomeada DATABASECHANGELOG. Estas informações são

apresentadas na Figura 41.

Figura 41 - Registro de alterações do banco de dados


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

85

software, contudo suas informações podem ser utilizadas para fins de auditoria da

qualidade dos artefatos desenvolvidos.

O primeiro quadro de informações providas pelo SonarQube é a tela principal

do projeto, a qual é apresentada na Figura 42.

Figura 42 - Tela principal de um projeto no SonarQube


Nesta tela é possível verificar o resumo dos índices que interferem na

qualidade dos artefatos de software. Dentre eles pode se destacar o quadro “Issues”

e o quadro “Complexity” que apresentam o numero de violações aos padrões de

codificação da plataforma utilizada e a complexidade do software respectivamente.

Toda variação do índice pode ser verificada in loco, pois a ferramenta permite

a localização do artefato que gerou tal variação.

No menu “Hotspot” na barra lateral esquerda é possível acessar outra tela

que detalha todos os pontos de maior impacto em cada índice e sua variação, de

acordo com a Figura 43.

86

Figura 43 - Tela hotspot do SonarQube


Selecionando um determinado artefato é possível verificar detalhadamente as

violações existentes no mesmo bem como o autor das mesmas, conforme Figura 44.

Figura 44 - Visualização detalhada de violações no SonarQube


87

Na Figura 44 é possível acompanhar cada item de violação dos padrões

encontrados pelo SonarQube e no painel lateral esquerdo é apresentado o autor do

código e a data de inserção do mesmo.

As informações oferecidas por esta ferramenta podem ser disponibilizadas

publicamente no local onde se encontra a equipe de desenvolvimento, desta forma

cada membro pode verificar a qualidade do seu código e fazer as devidas correções.

Desta forma a qualidade e o nível de codificação da equipe podem ser melhorados.

4.6 MATRIZ DE RASTREABILIDADE

Nesta seção é apresentada uma matriz informando que tipo de artefato pode

ser rastreado a partir de outro, considerando os procedimento e técnicas abordadas

neste trabalho. Foram avaliados artefatos que vão destes requisitos de software à

versão de software entregue.

Obteve-se então a seguinte matriz de rastreabilidade, apresentada no Quadro

15. Tem-se a rastreabilidade entre os elementos assinalados com “X”.

Artefato

Req

uis

ito

Caso

de

uso

Dia

gra

ma

s

Arq

uiv

o d

e c

ód

igo

fon

te

Tab

ela

de

ban

co

de

da

do

s

Ve

rsão

de

so

ftw

are

en

treg

ue

Requisito - - X X X

Caso de uso X* - X* X* X*

Diagramas X* - X* X* X*

Arquivo de código fonte X - - X X

Tabela de banco de dados X - - X X

Versão de software entregue X - - X X

Quadro 15 - Matriz de rastreabilidade de artefatos

88

Para os itens marcados com “X*”, considera-se a possibilidade de existência

de rastreabilidade deste que sejam inseridos como documentos no Redmine e

tenham uma tarefa referenciada ao mesmo por meio de uma hashtag (cerquilha). Tal

procedimento não é passível de ser validado ou obrigado a sua execução por meio

de configuração no sistema.

89

5 CONCLUSÃO

Neste capítulo serão apresentadas as conclusões obtidas durante o

desenvolvimento desse trabalho. Também neste capítulo são apresentadas as

sugestões para trabalhos futuros para trabalhos com este mesmo tema.

5.1 CONSIDERAÇÕES FINAIS

A partir das análises apresentadas anteriormente é possível verificar os laços

de rastreabilidade que podem ser obtidos por meio das configurações da integração

entre as ferramentas utilizadas e a configuração dos trabalhos configurados no

Jenkins.

Os relacionamentos entre trabalhos configurados por meio do mecanismo de

promoções permitem gerar informações de quando determinada versão foi

implantada em um determinado servidor.

A marcação de etiquetas nas revisões do repositório de controle de versões

de código fonte permite identificar quais revisões publicadas em um dado momento

na linha de tempo.

A data de geração das alterações gravadas pelo Liquibase permite relacionar

uma determinada alteração do banco de dados com a data de uma instância de

trabalho do Jenkins, garantindo que esta é uma pista de rastreabilidade confiável.

A partir da informação do número de tarefa no momento de confirmar uma

alteração no controle de versões é possível fazer o relacionamento entre estes. Com

este elemento de ligação é possível retornar ao requisito que originou cada alteração

de código fonte.

Com esta mesma relação também é possível partir de um determinado

requisito de software ou tarefa do Redmine e chegar aos artefatos gerados e

consequentemente identificar em qual momento este artefato foi implantado em um

determinado ambiente.

Considerando estes aspectos é possível afirmar que o cenário configurado

para o desenvolvimento do protótipo utilizado neste trabalho permite obter-se a

90

rastreabilidade de artefatos no sentido do inicio do processo para o final, bem como

do fim do processo para o inicio.

No entanto é necessário ressaltar a deficiência destes procedimentos e

técnicas no que diz respeito à rastreabilidade de elementos de diagramas utilizados

no projeto por meio de outras ferramentas, tais como: Astah, Enterprise Architect e

Power Designer.

5.2 TRABALHOS FUTUROS

Propõe-se como trabalho futuro a realização de análise detalhada sobre os

procedimentos de rollback (desfazer) em uma implantação realizada com falha,

desta forma também poder-se-ia aferir eficácia dos procedimentos estudados neste

trabalho para o contorno erros.

Outra proposta de trabalho futuro é a análise de registros dos procedimentos

de Integração Contínua para determinar um universo de código fonte a ser verificado

em caso de erro em uma versão de sistema, de forma que seja possível diminuir o

trabalho necessário para buscar um erro de sistema.

91

REFERÊNCIAS

AIELLO, B.; SACHS, L. Configuration Management: Best Pratices. Boston:

Pearson, 2011.

CAMPBELL, G. ; PAPAPETROU, P. SonarQube in Action. Nova York: Manning

Publications, 2014.

CHACON, S. Pro Git. Nova York: Apress, 2009.

CMMI. CMMI for Development, Version 1.3. Software Engineering Institute, 2014.

Disponivel em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em: 1

Fevereiro 2014.

DUVALL, P. M.; MATYAS, S.; GLOVER, A. Continuous Integration: Improving

Software Quality and Reducing Risk. Boston: Pearson, 2007.

EDWARDS, M.; HOWELL, S. L. A methodology for system requirements

specification and traceability for large realtime complex systems. The Defense

Technical Information Center, 1991. Disponivel em:

<http://www.dtic.mil/dtic/tr/fulltext/u2/a254738.pdf>. Acesso em: 12 Fevereiro 2014.

FARLEY, D.; HUMBLE, J. Entrega Contínua: Como Entregar Software de Forma

Rápida e Confiável. Porto Alegre: Bookman, 2014.

FLANAGAN, D. Java in a Nutshell. 5ª. ed. Sebastopol: O’Reilly Media, 2005.

FOWLER, M. Refatoração: Aperfeiçoando o Projeto do Código Existente. Porto

Alegre: Bookman, 2004.

FOWLER, M. Continuous Integration, 2006. Disponivel em:

<http://www.martinfowler.com/articles/continuousIntegration.html>. Acesso em: 4

Fevereiro 2014.

FOWLER, M. Version Control Tools, 2010. Disponivel em:

<http://martinfowler.com/bliki/VersionControlTools.html>. Acesso em: 16 Fevereiro

2014.

HAMILTON, V. L.; BEEBY, M. L. Issues of traceability in integrating tools.

Colloquium IEE Professional Group C1. Londres: [s.n.]. 1991. p. 4/1 - 4/3.

HEJLSBERG, A.; TORGERSEN, M.; WILTAMUTH, S.; GOLDE, P. The C#

Programming Language. 4ª. ed. Boston: Addison-Wesley, 2011.

LESYUK, A. Mastering Redmine. Birmingham: Packt Publishing, 2013.

92

LIQUIBASE. Liquibase, 2014. Disponivel em: <http://www.liquibase.org/>. Acesso

em: 17 Fevereiro 2014.

MOMBREA, M. What's the best programming language to learn first? IT World,

2014. Disponivel em: <http://www.itworld.com/development/398363/whats-best-first-

programming-language-learn>. Acesso em: 11 Fevereiro 2014.

PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissonal. 7ª. ed.

Porto Alegre: Bookman, 2011.

SMART, F. J. Jenkins: The Definitive Guide. Sebastopol: O'Reilly Media, 2011.

SOFTEX. Guia de Implementação – Parte 2: Fundamentação para Implementação

do Nível F do MR-MPS-SW:2012. SOFTEX, 2013. Disponivel em:

<http://www.softex.br/wp-

content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_Parte_2_2013.pdf>.

Acesso em: 1 Fevereiro 2014.

SOMMERVILLE, I. Engenharia de Software. 9ª. ed. São Paulo: Pearson, 2011.

TIOBE. TIOBE Index for February 2014. TIOBE Software, 2014. Disponivel em:

<http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. Acesso em: 16

Fevereiro 2014.

93

APÊNDICE A - TRABALHO DO JENKINS (.NET DESENV)

94

APÊNDICE B - TRABALHO DO JENKINS (JAVA DESENV)

95

APÊNDICE C – TRABALHO DO JENKINS (.NET HOMOLOGAÇÃO)

96

APÊNDICE D - TRABALHO DO JENKINS (JAVA HOMOLOGAÇÃO)

97

APÊNDICE E – ARQUIVO LIQUIBASE PARA TABELA DE ESTADO

98

APÊNDICE F – ARQUIVO LIQUIBASE PARA TABELA DE CIDADE

99

APÊNDICE G - ARQUIVO LIQUIBASE PARA TABELA DE PRODUTOS

100

APÊNDICE H - ARQUIVO LIQUIBASE PARA TABELA DE PARCEIROS

101

APÊNDICE I – ARQUIVO LIQUIBASE PARA TABELA DE PEDIDO

102

APÊNDICE J – ARQUIVO LIQUIBASE INICIALIZAÇÃO DA EXECUÇÃO

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

Technology

Transcript of Aplicação de Integração Contínua para viabilizar a rastreabilidade de artefatos durante a...