2. GERÊNCIA DE CONFIGURAÇÃO DE SOTWARE

1. INTRODUÇÃO Constata se, atualmente, que organizações voltadas ao desenvolvimento de software, buscam alavancar seus níveis de competitividade, uma vez que o mercado de desenvolvimento de software apresenta constantes mudanças. Muitos esforços foram realizados, por meio de estudos e pesquisas que visam contribuir para a evolução de Engenharia de Software e de suas áreas de conhecimento através da definição de processos de software. Dentre os processos de software pode se destacar o Gerenciamento de Configuração de Software (GCS), contribuindo para a qualidade do projeto de software através do suporte as suas atividades relacionadas tanto aos aspectos gerenciais quanto aos aspectos técnicos. [6] O desafio no desenvolvimento, reside na criação de vantagens competitivas e na utilização dos processos de controle aliados a adequação da cultura organizacional. Esse artigo apresenta uma abordagem conceitual para o processo de CVS, cujo objetivo é contribuir para a melhoria da qualidade dos processos de software. 2. GERÊNCIA DE CONFIGURAÇÃO DE SOTWARE A Gerência de Configuração de Software visa o estabelecimento e a manutenção da integridade dos componentes, que formam o projeto de software, no decorrer de seu ciclo de vida. De forma, a identificar os artefatos de software, controlar as alterações realizadas e registrar e gerenciar todas as mudanças decorrentes dos processos. De acordo com Bersoff, Não importa onde você esteja no ciclo de vida do sistema, o sistema mudará e o desejo de realizar alterações persistirá através de todo ciclo de vida. Desta forma, a GCS pode ser visualizada como uma ferramenta que favorece a qualidade do software em todas as suas etapas de desenvolvimento. [1] Esse processo tem em sua composição elementos importantes e relacionados entre si. Conforme Dart,... o processo de GCS é composto por elementos de componente, processo, construção e humanos.... Assim, entende se como elementos de componente, as ferramentas de desenvolvimento a serem empregadas, e como elementos de processo, as ações realizadas para uma abordagem eficaz na gestão de mudanças. E, como elementos de construção, as ferramentas empregadas à automatização de Itens de Configuração. E como elementos humanos, as abordagens de integração e favorecimento das relações humanas. [2]. Os artefatos controlados que fazem parte da configuração do software são tidos como Itens de Configuração (Configuration Itens - CIs). Segundo Pressman,... um item de configuração de software pode ser definido como informação criada como parte do processo de engenharia de software.... Ampliando essa abordagem inicial, um IC é todo ou parte de um artefato de software. [3] Um IC Item de Configuração, compreende a menor parte de um projeto de software, e sua integração ou não a outros ICs com caráter finalizador, caracteriza um artefato de software. 1

Todo o processo de controle das mudanças realizado no artefato, configuram as linhas de base que direcionam as atividades posteriores do projeto. Neste contexto, o GCS estabelece os princípios que favorecem a qualidade da atividade de desenvolvimento de software, tais como a Identificação de Configuração, que estabelece toda estrutura necessária à gestão da GCS, o Controle de Configuração favorece a definição das ações realizadas, a Administração de Estado responde pela entrega de documentação informativa de configuração e a Auditagem de Configuração permite a fiscalização das baselines, verificando minunciosamente se a documentação de requisitos foi obedecida. 2.1 CONTROLE DE VERSÃO O Controle de Versão atua de forma a preservar as versões de um artefato de modo sistemático e seguro, e não limitado em número de versões. Segundo Pressman,... o controle de versão combina procedimentos e ferramentas para gerenciar diferentes versões de objetos de configuração, criados durante o processo de software.. Desta forma o controle de versão oportuniza um melhor acompanhamento do histórico de desenvolvimento. O controle de versão visa especificamente definir o estado de determinado objeto em dado momento, gerenciando as alterações realizadas no artefato para o incremento em mais uma versão de software, identificando cada versão por meio de numeração específica, mantendo todo o histórico de alterações. Durante as últimas décadas foram propostas muitas abordagens automáticas diferentes para o controle de versão, sendo que a principal diferença reside na sofisticação dos métodos de versionamento e controle do mesmo. O controle de versionamento prioriza o controle das alterações devido a possibilidade e alterações mal gerenciadas conduzirem todo um projeto a uma situação de caos, e dependendo do tamanho do projeto, ao fracasso. Segundo Bach,... o controle de alterações é vital. Mas as forças que o tornam necessário também o tornam inconveniente. Temos medo das alterações, porque uma pequena perturbação no código pode criar uma enorme falha no produto. Mas elas podem também reparar uma grande falha ou habilitar novos e maravilhosos recursos. Temos medo das alterações porque um único desenvolvedor irresponsável poderia afundar todo o projeto; embora ideias brilhantes possam surgir das mentes desses brincalhões, um controle de versionamento pesado poderia efetivamente desencoraja los no seu trabalho criativo.... Verifica se que Bach reconhece a necessidade de um ponto de equilíbrio quando se fala na questão do controle de versão. O processo de controle de alteração está ilustrado conceitualmente na Figura 1.1. 2

Figura 1.1 Processo de Controle de Alteração Uma solicitação de alteração é apresentada e avaliada a sua viabilidade, efeitos colaterais e detalhes técnicos. Os resultados dessa avaliação compõem um relatório técnico de alterações que é analisado pela autoridade de controle de alterações (change control authority - CCA) que toma a decisão sobre o status e prioridade da alteração. Uma ordem de alteração de engenharia (engineering change order - ECO) é gerada para alteração aprovada. Os IC a serem alterados são colocados em um diretório e o sistema de controle de versão atualiza o arquivo original. Após as alterações serem concluídas os objetos são inseridos no repositório e o sistema de controle de versão se encarrega de criar a próxima versão de software. 2.2 SISTEMA DE CONTROLE DE VERSÃO São sistemas destinados a registrar alterações em grupos de arquivos durante um período de tempo, de forma que esses arquivos possam ser recuperados de acordo com as necessidades específicas do projeto. O sistemas de controle de versão possuem um grande histórico marcado pelas evoluções tecnológicas e pelas recorrentes necessidades da comunidade de desenvolvimento de software tais como: desenvolvimento paralelo, customização da versão e inclusão de requisitos. 2.2.1 HISTÓRICO Segundo Bolinger e Bronson [4], o primeiro sistema de controle de versão foi desenvolvido em 1972 e foi denominado Source Code Control System (SCCS), sendo a principal ferramenta de controle de versão até o surgimento do RCS (Revision Control System), que foi o pioneiro com o emprego de uma técnica 3

denominada interleaved deltas, sendo considerada essa técnica a precursora para o surgimento das atuais técnicas de junção. O CVS (Concurrent Versions System), foi desenvolvido com base no RCS, porém com a característica de gerenciar todos os arquivos de um projeto, sendo iniciado seu projeto em 1986 e aperfeiçoado em 1989. Ainda na busca por melhoramentos foi desenvolvido o Subversion pela empresa CollabNet com o foco em ser uma opção mais robusta ao CVS. Nessa época a empresa SUN trabalhava com o TeamWare, que tratava se de um sistema de controle de versão distribuído, que fora substituído pela equipe de desenvolvimento da SUN, por aplicações mais atuais como: Mercurial que fora criado por Matt MacKall e o Git, criado por Linus Torvalds. 2.2.2 CONCEITOS As diversas ferramentas de controle de versionamento compartilham conceitos particulares que são inerentes a todas, pois são características de qualquer SCV. Sendo os principais termos técnicos empregados pelos SCV s. item de configuração: é representado até pela menor parte que compõe o processo de desenvolvimento, sendo identificados unicamente. repositório: local de armazenamento dos arquivos. versão: representa o estado de um item de configuração e deve possuir um identificador único. ramo: versão paralela ou alternativa, usada em configurações alternativas. check out: é o ato de criar uma cópia de trabalho update: é o ato de enviar modificações contidas no repositório para a área de trabalho. commit: é o ato de criar o artefato no repositório pela primeira vez ou criar uma nova versão do artefato quando este passar por alguma modificação. merge: é a mescla entre versões diferentes, objetivando gerar uma única versão que agregue todas as alterações realizadas. changeset: que é uma coleção atômica das alterações realizadas no repositório. No Sistema de Controle de Versão o repositório armazena todo o histórico do projeto e cabe ao desenvolvedor fazer uma cópia e dos arquivos para sua área de trabalho, onde ele pode realizar as modificações e enfim salvar os arquivos no repositório. Figura 1.2 Comunicação entre o repositório e a área de trabalho (DIAS, 2009). 4

2.2.3 MODELO CENTRALIZADO E DISTRIBUIDO Atualmente os SCV são classificados em dois tipos principais, que diferenciam se por suas particularidades no que tange a forma como os desenvolvedores interagem com o SCV, denominados: Centralizado e Distribuído. Ambos os modelos serão objetos de nossa verificação. O modelo Centralizado opera com um servidor central e diversas áreas de trabalho, baseando se na arquitetura clássica cliente-servidor. Essa infraestrutura de Controle de Versão atende perfeitamente a equipes de variados tamanhos e que desenvolvam seus trabalhos em um mesmo ambiente. Dentre suas características principais destacam se o bom tempo de resposta do servidor e a necessidade de todas as comunicações se darem exclusivamente pelo servidor. Sendo o sistema Subversion uma das principais ferramentas de controle centralizado. [5] A Figura 1.3, demonstra o fluxo de arquivos no sistema de controle de versão centralizado. Figura 1.3 Fluxo SCV Centralizado (DIAS, 2009). O modelo Distribuído é aplica se melhor a equipes que trabalhem em grandes distancias, como cidades distintas. Onde cada área de trabalho possui um servidor próprio, sendo realizadas as operações de check-in e check-out na própria máquina do desenvolvedor, sendo que cada máquina pode comunicar se entre si sem a necessidade de comunicação com o servidor central. Assim faz se necessário a escolha de um servidor central com acesso remoto por meio de duas operações denominadas: pull (puxar): operação responsável por mesclar a versão de uma máquina externa com a versão da máquina nativa de um desenvolvedor da equipe. push (empurrar): é o envio de para outra máquina a versão nativa na máquina de determinado desenvolvedor. lock: bloqueia o arquivo para modificações enquanto determinado desenvolvedor estiver o alterando para evitar a sobreposição de código. 5

Um dos sistemas de controle de versão distribuído mais utilizado é denominado Git. [5] A Tabela 1.1, apresenta alguns SCV s distribuídos e centralizados de utilização livre e comercial. A figura 1.4, apresenta o fluxo de arquivos com o emprego de ferramentas de software desatualizada. Tabela 1.1 Sistemas de Controle de Versão Figura 1.4 Fluxo SCV Distribuído (DIAS, 2009). 6

3. SUBVERSION Neste capítulo é a presentada a ferramenta de controle de versão centralizada Subversion, estando disponível em http://subversion.apache.org. Neste capítulo apresenta se seu ciclo de trabalho, principais comandos, características da interface bem como a visão geral da ferramenta, com o objetivo de fornecer informações precisas para a realização de comparações com as demais ferramentas SCV. 3.1 CICLO DE TRABALHO Os principais comandos da ferramenta Subversion estão relacionados com seu ciclo de trabalho, fazendo parte das seguintes operações: Atualizar cópia de trabalho: o comando svn update, traz alterações do repositório para sua paste de trabalho. Realizar alterações: o comando svn add adiciona arquivos, svn delete, exclui um item ou cópia de trabalho, svn copy copia um arquivo ou diretório, svn move, move um arquivo ou diretório. Verificar alterações: svn status, exibe informações sobre o status do arquivo, svn diff, demonstra as diferenças entre duas revisões. Desfazer alterações: svn revert, desfaz todas as edições locais. Resolver conflitos: svn update, atualiza a cópia de trabalho, svn resolved, remove arquivos ou diretórios da cópia de trabalho em estado de conflito. Submeter alterações: svn commit, envia as alterações de sua cópia para o repositório. 7

A Figura 1.5 apresenta o fluxo de processos empregado no Subversion. Figura 1.5 Fluxo de trabalho do Subversion 8

3.2 VISÃO GERAL 3.2.1 OPERAÇÕES No Subversion a operação de commit é atômica, ou seja, se a operação for interrompida pelo meio ela é desconsiderada. Isso permite, por exemplo, que em uma ocasião de queda de energia no exato momento em que era realizada uma operação de commit, o repositório não fique um estado inconsistente. O Subversion é uma ferramenta de controle de versões que trabalha de forma centralizada, por isso não possui a funcionalidade de propagar as mudanças de um repositório para outro. O histórico do Subversion além das revisões, quem realizou as alterações e quando elas foram realizadas em um arquivo ou diretório. Através do comando svn blame é possível também obter informações de autor e revisões por linha de um arquivo ou URL especificados. A cada commit realizado no Subversion é criado um changeset diferente com informações como a lista de arquivos alterados, quem realizou as alterações, mensagem de log e quando foi realizado. Porém, o Subversion não permite que o próprio usuário crie um changeset da maneira que desejar, como em outras ferramentas de controle de versões. No caso de um merge com um arquivo renomeado, o Subversion não consegue reconhecer o arquivo e copia o arquivo de origem para o local destinado, deletando o arquivo de destino. Movimentar e renomear arquivos ou diretórios no Subversion são operações possíveis e simples. As cópias de arquivos e diretórios também são suportadas. Apesar de parecer uma operação simples, muitas ferramentas de controle de versão não suportam a operação de cópia. Muitos usuários também utilizam a possibilidade de cópia de arquivos e diretórios para criarem ramos manualmente no Subversion. 3.2.2 CARACTERÍSTICAS E INTERFACE Uma importante característica do Subversion é que ele consegue controlar as alterações realizadas na cópia de trabalho que ainda não foram enviadas ao repositório. Isso é feito através do comando svn diff, assim o usuário pode analisar suas alterações antes de enviá-las ao repositório. Todo commit no Subversion pode ser acompanhado de uma mensagem de log, ou seja, o usuário pode descrever todas as alterações relativas àquele commit em uma mensagem, que fica gravada no repositório. O Subversion permite apenas uma mensagem de log para todo o conjunto de mudanças, não permitindo que cada arquivo possua uma mensagem de log particular. O Subversion é uma das ferramentas de controle de versões com o maior número de clientes baseados em interface Web. A Figura 1.6 demonstra a interface web Trac Subversion. Figura 1.6 Trac Subversion interface web 9

4. GIT Neste capítulo é a presentada a ferramenta de controle de versão distribuído GIT, estando disponível em http://git-scm.com/download. Neste capítulo serão apresentados seu ciclo de trabalho, principais comandos, características da interface bem como a visão geral da ferramenta, com o objetivo de fornecer informações precisas para a realização de comparações com as demais ferramentas SCV. 4.1 CICLO DE TRABALHO Os principais comandos do GIT estão ligados ao seu ciclo básico de trabalho. O ciclo básico de trabalho pode ser definido como as operações comuns realizadas por um desenvolvedor em seu dia a dia de trabalho. Fazem parte do ciclo básico do GIT as seguintes operações: Atualizar e cópia de trabalho: git fetch, que faz o download de alterações do repositório desejado, git merge, para mesclar as alterações baixadas com o seu repositório, git pull, que atualiza seu repositório e sua área de trabalho com as alterações de outro repositório, Fazer alterações: git add, que adiciona arquivos ao index, git rm, que exclui um item de uma cópia de trabalho ou do repositório e git mv, que move ou renomeia um arquivo ou diretório, Verificar suas alterações: git status, que exibe informações sobre o estado de arquivos e diretórios na cópia de trabalho e git diff, que exibe as diferenças entre duas revisões ou caminhos, Desfazer algumas alterações: git revert, que desfaz todas as edições locais, Resolver conflitos: git mergetool, que executa ferramentas de resolução de conflitos para resolver conflitos de junção, Submeter alterações: através do comando git commit, que envia as alterações de sua cópia de trabalho para o repositório. Propagar suas alterações para outro repositório: git push, que envia as alterações do repositório local (origem) para outro repositório (destino). A Figura 1.7 apresenta o fluxo de processos empregado no GIT. 10

Figura 1.7 Fluxo de trabalho no GIT. 11

4.2 VISÃO GERAL 4.2.1 OPERAÇÕES Assim como no Subversion, no GIT a operação de commit é atômica, ou seja, se uma operação é interrompida, ela é desconsiderada e o repositório não fica em um estado inconsistente. Pelo fato de ser um sistema de controle de versões descentralizado, clonar um repositório no GIT é uma operação comum. Isso é feito através do comando git clone. Este comando clona um repositório em um novo diretório, cria ramos remotos para cada ramo do repositório clonado e cria um ramo inicial já realizando um check out no mesmo. No GIT a propagação de mudanças de um repositório para outro é oferecida através dos comandos git push, git fetch e git pull. O comando git fetch atualiza o repositório sem atualizar a cópia de trabalho, o comando git push envia as alterações de um repositório local para um repositório remoto e o comando git pull atualiza o repositório local com alterações de um repositório remoto. O comando git pull já atualiza também a cópia de trabalho do usuário, portanto, ele nada mais é do que um git fetch seguido de um merge. 4.2.2 CARACTERÍSTICAS E INTERFACE Com o GIT é possível controlar as alterações realizadas na cópia de trabalho que ainda não foram enviadas ao repositório. Isso é feito através do comando git diff, assim o usuário pode analisar suas alterações com cautela antes de enviá-las ao repositório. É possível também ignorar alterações indesejadas, alocando-as em um diretório isolado, através do comando git stash. O GIT não possui tantos clientes baseados em interface Web como o Subversion, porém sua distribuição já possui um cliente, o Gitweb. O Gitweb foi desenvolvido na linguagem Perl e permite navegar pelos diretórios através de revisões desejadas, ver o conteúdo dos arquivos, verificar o log de diferentes ramos e examinar os commits, visualizando a mensagem de log e as alterações relativas ao commit. A Tabela 1.2 Subversion X GIT, apresenta o comparativo de funcionalidades de ambas as ferramentas. SUBVERSION Licença Apache/BSD GNU GPL v2 GIT Portabilidade Excelente Boa Interoperabilidade Excelente Boa Documentação Excelente Boa Implantação Regular Boa Integração de Rede Excelente Excelente Replicação Remota de Repositório Indiretamente Sim 12

Propagação de alterações de repositórios Indiretamente Sim Commits atômicos Sim Sim Permissões de acesso ao repositório Repositório, Diretórios, Arquivos Repositório, Diretório, Arquivos Histórico com informações linha a linha Sim Sim Suporte a Changeset Sim Sim Renomear/Movimentar arquivos ou diretórios Sim Sim Cópias de arquivos ou Sim Não Merge inteligente após Renomear/Movimentar arquivos Monitoramento de alterações não enviadas ao repositório Não Sim Não Sim Mensagens de log para cada arquivo do commit Não Não Trabalhar com apenas um diretório do repositório (Check out parcial) Sim Não Interface Web Sim Sim Interface Gráfica de Usuário Sim Sim Tabela 1.2 Subversion X GIT 5. CONSIDERAÇÕES FINAIS O presente trabalho contribuiu na revisitação de conceitos relativos a Gerência de Configuração de Software, sobre o prisma do Controle de Versionamento de Software tomando como base de pesquisa as modernas ferramentas de CVS: Subversion e GIT. Verificando as particularidades de cada uma bem como os benefícios de suas aplicações no contexto da GCS. 13

Referências 1. PRESSMAN, Roger S. Engenharia de Software, p 515. São Paulo: AMGH, 2011. 2. PRESSMAN, Roger S. Engenharia de Software, p 516. São Paulo: AMGH, 2011. 3. CUNHA, João R. D. et al. Uma Abordagem para o Processo de Gerenciamento de Configuração de Software, p 02. 2011. Disponível em: www.spell.org.br/documentos/download/26414. Acesso em 27 mai. 2015 4. BOLINGER, D., BRONSON, T. Applying RCS and SCCS: From Source Control to Project Control, p 526, O'Reilly Media,1995. 5. Lacerda, Eduardo C. Sistemas de Controle de Versão, p 3. 2014. Disponível em: http://www.devmedia.com.br/sistemas-de-controle-deversao/24574. Acesso em 26 de mai. 2015 6. PÁDUA F. et al. Engenharia de Software: Fundamentos Métodos e Padrões. LTC 2003. 7. DIAS, A. F. Conceitos Básicos de Controle de Versão de Software - Centralizado e Distribuído. 2009. Disponível em http://www.pronus.eng.br/artigos_tutoriais/ gerencia_configuracao/conceitos_basicos_controle_versao_centraliz ado_e_distribuido.php?pagnum=0. Acesso em 28 de mai. 205 14