Mercado em Gráfico - MeG

Fonte: Wikiversidade

Introdução[editar | editar código-fonte]

Esta página descreve o Plano de Gerência de Configuração para o projeto de melhorias e refatorações do projeto MeG - Mercado em Gráficos desenvolvido no segundo semestre de 2014 na disciplina de Métodos de Desenvolvimento de Softwares ministrada no curso de Engenharia de Software na Universidade de Brasília, Campus Gama (FGA).

O Mercado em Gráficos é um software livre que tem como objetivo fornecer uma visão de diversos aspectos à respeito do mercado brasileiro. O sistema se concentra em exibir os dados abertos disponibilizados pelo SIDRA/IBGE sob a forma de gráficos e tabelas e proporciona ao usuário uma série de informações acerca do cenário industrial no Brasil, tais como: quantidade de pessoas assalariadas em um determinado setor, salário médio de uma determinada área, rankings de crescimento que demonstram a evolução de um estado em uma determinada área de trabalho, entre outros.

Objetivos[editar | editar código-fonte]

Como já dito, o presente relatório visa gerar uma elaboração de um Plano de Gerência de Configuração. Esse plano, consiste em oferecer uma visão geral do que será feito. Ele inclui a finalidade, o escopo, as definições das atividades envolvidas na gerência de configuração. Levando para o contexto do nosso projeto, nosso plano se restringirá em um primeiro momento à criação de uma política de branches para o repositório do projeto, planejar e implementar o uso da integração contínua para ganho em termos de produtividade dos envolvidos no processo e a formalização das mudanças que serão adotadas. Nesse último ponto, o controle de versão será responsável pelo melhor gerenciamento dessa questão.

Política de Branches[editar | editar código-fonte]

O uso de uma política de branches  é um dos fatores que determinarão a qualidade final do processo e do produto que será evoluído. Pelo fato do MEG ter sido desenvolvido sob o controle de versão do git e estar hospedado no github, optou-se por manter o repositório e seus sistema de controle de versão. Com isso elaborou-se uma política de branches auxiliaria a equipe de desenvolvimento a evoluir o projeto de uma forma organizada e bem definida, além de fornecer suporte ao segundo ponto que se refere à implementação da integração contínua. A política adotada, consiste na criação de branches onde refatorações de métodos serão realizadas e monitoradas visando evoluções e melhorias no código. O fato de funcionalidades serem desenvolvidas em branches separadas não significa que cada branch alocará uma funcionalidade, o ideal é que funcionalidades semelhantes, ou que forneçam edições nos mesmos arquivos de estudo. Nenhum dos desenvolvedores deve mandar commits diretamente para branch master, sendo essa, restrita para futuros merges que alocarão uma grande massa de código de forma que esses já estejam com suas funcionalidades concluídas. Com o merge realizado, as branchs devem ser deletadas para melhor organização do repositório.

Integração Contínua[editar | editar código-fonte]

A integração contínua é uma técnica que consiste em integrar quaisquer códigos produzidos e/ou alterados ao projeto principal com a mesma frequência que os mesmos são desenvolvidos. A intenção do trabalho é propor a implementação da integração contínua ao projeto de evolução do MeG e auxiliar o time a identificar quaisquer defeitos no código que as mudanças realizadas durante a refatoração tenham eventualmente gerado de forma rápida. Esta prática fornecerá um feedback instantâneo aos desenvolvedores em relação ao trabalho feito por eles e isso pode otimizar muito o processo, tendo em vista que grande parte dos problemas potenciais providos da integração entre o código desenvolvido e o projeto será eliminada com a aplicação da integração.

Existem diversas ferramentas para automatizar o processo de integração contínua, optou-se por utilizar o Jenkins após a realização de algumas pesquisas, além do conhecimento de colegas que já utilizaram a ferramenta, tendo assim maior auxílio na produção do projeto.

Algumas Considerações[editar | editar código-fonte]

Apesar da dupla não possuir experiência em integração contínua, há confiança no aprendizado que diz respeito a utilização do Jenkins e planeja-se construir um modelo de branches que apoiem a implementação da integração contínua.