Estudo de caso sobre a implantação de um mecanismo de controle de versão de software na Diretoria de Gestão de TI da Universidade Federal de Lavras Bruno Carvalho Silva Luz, Nelton Matioli, Ramon Abílio, Cassia Nobre, Erasmo de Oliveira Diretoria de Gestão de Tecnologia da Informação (DGTI) - Universidade Federal de Lavras (UFLA) Campus Universitário, Caixa Postal 3037, CEP 37200-000 – Lavras/MG
[email protected], {nelton.santos, ramon.abilio, cassia, erasmo}@dgti.ufla.br RESUMO Algumas falhas são comuns na adoção da gerência de configuração como não avaliar o impacto das mudanças ou utilizar ferramentas para controle de versão de forma incorreta. Buscando melhorar a gerência de configuração realizada na Diretoria de Gestão de TI da Universidade Federal de Lavras, foram realizadas uma revisão bibliográfica sobre o tema e entrevistas com a equipe. A partir disso, foi diagnosticada a situação e realizada uma proposta de mudança. Como resultado da implantação dessa proposta, percebeu-se que o processo de geração de novas versões do sistema foi facilitado. O tempo de preparação e a possibilidade de erros foram reduzidos, visto que a mesclagem de códigos passou a ser realizada automaticamente. Palavras Chaves: SVN, Branch, Controle de Versão, Gerência de Configuração ABSTRACT Misconceptions are common in adoption of configuration management, such as underestimate the impact of system changes or the wrong use of source control systems. Seeking to improve configuration management held in the IT Department of Federal University of Lavras (UFLA), we performed a research on the theme and interviews with the team. After that, we diagnosed the situation and proposed changes in the configuration management process. As a result of the implementation of these changes, we noted that the process of releasing new versions of the system was improved. The preparation time and errors were reduced due to automated code merges. Key words: SVN, Branch, Source Control, Configuration Management
1. INTRODUÇÃO Para manter a infraestrutura de redes de computadores, hardware e software, a Universidade Federal de Lavras (UFLA) possui a Diretoria de Gestão de Tecnologia da Informação (DGTI). A missão da DGTI é “fornecer serviços e produtos de software ou hardware com qualidade e efetividade, suportando as atividades de ensino, pesquisa e extensão da Universidade Federal de Lavras, no âmbito de Tecnologia da Informação e Comunicações” [1]. Ela tem como visão “ser excelência na prestação de serviços de TI e aumentar o nível de maturidade de governança de TI da UFLA, alinhando a Tecnologia da Informação aos objetivos de negócio (ensino, pesquisa e extensão) das unidades organizacionais (Pró-Reitorias, diretorias, setores administrativos e departamentos didático-científicos)” [1]. A DGTI está subdividida em cinco coordenadorias [1]. Uma delas é a Coordenadoria de Sistemas de Informação – CSI. A CSI é responsável pela “definição, análise, programação, implantação, manutenção e documentação de sistemas de informação dos órgãos administrativos da Instituição” [1]. Dentre os objetivos estratégicos da DGTI alinhados à responsabilidade da CSI estão [1]: i) Melhorar o gerenciamento de projetos na DGTI; ii) Integrar os sistemas de informação utilizados na Instituição; e iii) Melhorar a qualidade de desenvolvimento e aquisição de software. A equipe da CSI é composta por Analistas de TI, Técnicos em TI e estagiários dos cursos de Ciência da Computação e Sistemas de Informação. Essa equipe está alocada prioritariamente no atendimento a solicitações de desenvolvimento e manutenção dos sistemas de informação da graduação (SIG-UFLA) e pós-graduação (Posgrad), e na implantação de um novo sistema integrado de gestão com módulos administrativos e acadêmicos. No contexto do desenvolvimento e manutenção de software, uma forma de controlar mudanças
durante o ciclo de vida de um software, é através da Gerência de Configuração de Software, que é definida como o desenvolvimento e aplicação de padrões e procedimentos para gerenciar um produto de sistema em desenvolvimento [2]. Algumas falhas são comuns na adoção da gerência de configuração em uma organização. Não avaliar o impacto das mudanças, e utilizar ferramentas para controle de versão de software de forma errada são exemplos de falhas que podem tornar o processo de desenvolvimento de um software confuso ou até mesmo caótico [3]. Buscando melhorar o controle de versões realizado na CSI, resolveu-se verificar se a ferramenta de controle de versão (Subversion - SVN) utilizada para o desenvolvimento do SIG-UFLA e a aplicação dos conceitos da gerência de configuração dentro da CSI estavam adequados. Para isto, foi realizado um diagnóstico da situação, uma proposta de mudança na utilização do SVN e a implantação desta. Neste trabalho, os passos e a análise dos resultados obtidos são detalhados. Na Seção 2, é descrito como foi conduzido o processo para realizar as mudanças. A revisão bibliográfica (Seção 3) aborda o tema de gerência de configuração, mais especificamente o controle de versão. Na Seção 4, está descrito como foram realizadas as entrevistas, a situação diagnosticada e a proposta de melhoria. Implantação é detalhada na Seção 5. Após, são apresentados os resultados (Seção 6) e por fim são apresentadas as considerações com relação aos benefícios da mudança e os trabalhos futuros (Seção 7). 2. METODOLOGIA O trabalho foi realizado de Janeiro a Maio de 2014 e compreendeu as seguintes fases: Revisão Bibliográfica, Diagnóstico, Implantação e Análise dos Resultados. A Revisão Bibliográfica sobre gerência de configuração foi realizada com o intuito de construir uma base teórica, utilizada para diagnosticar a situação atual da coordenadoria de sistemas e propor melhorias no processo. No Diagnóstico, foram realizadas entrevistas com os desenvolvedores e com o gerente de configuração com o objetivo de verificar o conhecimento, as práticas e as ferramentas de software relacionados à gerência de configuração e controle de versões. Foram entrevistadas nove pessoas, graduadas em Ciência da Computação ou Sistemas de Informação, com média de idade de 29 anos. Dessas nove pessoas: i) três possuíam mestrado; ii) dois eram alunos de mestrado; iii) cinco eram terceirizados; e iv) quatro eram do quadro efetivo da instituição. Diagnosticada a situação, uma sugestão de melhoria foi proposta considerando as falhas identificadas e também o que diferentes autores consideram o ideal para que estas não ocorram. O próximo passo foi a implantação da proposta e a avaliação dos resultados. Para a implantação, foi realizada uma apresentação do diagnóstico e da proposta. Foi necessária uma padronização das ferramentas utilizadas e um treinamento para uso das mesmas. Nesse processo de implantação, foi fornecido suporte aos desenvolvedores. A avaliação dos resultados ocorreu durante todo o período de implantação, analisando-se as construções das versões e opiniões dos desenvolvedores e gerente de configuração. 3. REVISÃO BIBLIOGRÁFICA Nesta seção, são apresentados conceitos sobre gerência de configuração de software, controle de versões e estratégias de branches. Tais conceitos constituem uma base teórica para o entendimento do trabalho. 3.1. Gerência de Configuração de Software A Gerência de Configuração de Software (GCS) é definida como o desenvolvimento e aplicação de padrões e procedimentos para gerenciar um produto de sistema em desenvolvimento [2]. A mesma também pode ser definida como a disciplina que permite manter produtos de software em evolução sob controle, e, portanto, contribuindo para satisfazer restrições de qualidade e de cronograma [4].
A GCS é composta por quatro funções: Identificação, Documentação, Controle e Auditoria [5]. Essas funções relacionam-se definindo a GCS como um conjunto de atividades projetadas para gerir modificações, identificando os produtos de trabalho que podem ser modificados, estabelecendo relacionamentos entre eles, definindo mecanismos para administrar as diferentes versões desses produtos de trabalho, controlando as modificações impostas e fazendo auditoria, e preparando relatórios sobre as modificações efetuadas [6]. A GCS tem como objetivo responder [6]: 1. Quais mudanças ocorreram no sistema? 2. Por que essas mudanças ocorreram? 3. O sistema continua íntegro após as mudanças? Essas questões correspondem a cada um dos sistemas desenvolvidos pela Gerência de Configuração de Software. Tais sistemas são: Sistema de Controle de Versão, Sistema de Controle de Mudanças e Sistema de Gerenciamento de Construção [7]. 3.2. Controle de versão Grande parte dos problemas de desenvolvimento que ocorrem são causados pela ausência de controle de versão. Sobrescrever um código de outra pessoa por acidente ou ter dificuldades em saber quais alterações foram feitas em um software, quem fez e quando foram feitas são exemplos típicos da falta de controle de versão [2]. Esta atividade de controlar a versão, utiliza uma combinação de procedimentos e ferramentas que têm como objetivo apoiar o desenvolvimento. Um sistema de controle de versão implementa ou está diretamente integrado com quatro capacidades principais [6]: 1.Um banco de dados de projeto (repositório) que guarda todos os objetos de configuração relevantes; 2.Uma capacidade de gestão de versão que guarda todas as versões de um objeto de configuração (ou permite que qualquer versão seja construída usando diferenças de versões anteriores); 3. Uma facilidade de construir que permite ao engenheiro de software coletar todos os objetos de configuração relevantes e construir uma versão específica do software. 4. Acompanhamento de tópicos (ou acompanhamento de bugs) que permite à equipe registrar e acompanhar o estado de todos os tópicos importantes associados a cada objeto de configuração. O controle de versão é composto de duas partes: o repositório e a área de trabalho. O repositório é responsável por armazenar o histórico de evolução do projeto, registrando todas as alterações feitas no projeto. Por meio do histórico, é possível saber quem fez alterações, onde e quando. A área de trabalho possui uma cópia dos arquivos do projeto. O desenvolvedor trabalha com esses arquivos em vez de usar o repositório diretamente. Tal cópia é monitorada para que seja possível identificar eventuais mudanças. Uma área de trabalho deve ser individual e isolada de outras. A comunicação entre o repositório e esta é feita através dos comandos commit e update. O commit é responsável por enviar modificações da área de trabalho para o repositório. Já o update é responsável por realizar o caminho inverso. 3.3. Estratégias de Branch O uso de branches dentro do software de controle de versão oferece um melhor isolamento e controle de ativos de software individuais. Entretanto, os riscos também aumentam, pois há um aumento nas atividades de mesclagem (merge). Ao decidir usar uma estratégia de GCS, primeiramente é necessário identificar o que um branch representa. Branches frequentemente estão alinhados a arquiteturas de sistemas, unidades organizacionais ou estruturas de divisão de trabalho. Ao escolher a melhor estratégia de branches é
necessário estabelecer um equilíbrio entre os ganhos em produtividade e o aumento de risco. Escolher uma estratégia errada pode causar overheads em processos, longas integrações e ciclos de release frustrantes para toda a equipe [8]. Existem diversas estratégias de branches. Algumas delas são [8]: Branch por release: Uma branch possui todos os ativos de desenvolvimento de software para uma única release, como demonstrado na Figura 1. Ocasionalmente, deve-se mesclar as atualizações de uma versão para a outra, mas geralmente elas nunca se fundem. Quando uma release é descontinuada, a branch também deve ser descontinuada.
Figura 1 Branch por release [8]
Branch por promoção de código: Uma versão específica de desenvolvimento é ramificada em um branch de teste, em que todos os testes de integração e do sistema são realizados. De acordo com a Figura 2, quando o teste é completado, os ativos de desenvolvimento de software são ramificados no branch de produção, e finalmente são implantados.
Figura 2 Branch por promoção de código [8]
Branch por tarefa: Esse tipo de branch isola as tarefas em uma branch separado para evitar sobreposição de tarefas e perda de produtividade, como demonstrado na Figura 3. Essas branches devem ser de curto prazo e se fundem assim que a tarefa é completada.
Figura 3 Branch por tarefa [8]
4. DIAGNÓSTICO Nesta seção, é apresentado o diagnóstico realizado na Coordenadoria de Sistemas de Informação (CSI) quanto ao uso do controle de versões. 4.1. Entrevistas
Antes de elaborar uma proposta de melhoria foi necessário diagnosticar a situação da gerência de configuração naquele momento. Para isso, foram realizadas entrevistas com os desenvolvedores e gerentes. Tais entrevistas foram realizadas obedecendo a um conjunto de perguntas específicas que tinham como objetivo principal verificar como estava a aplicação dos conceitos de gerência de configuração na organização. Nove pessoas foram entrevistadas, sendo que uma delas era o gerente de configuração e o restante eram desenvolvedores. Como o software utilizado para controle de versão atualmente na DGTI é o Subversion (SVN) as perguntas foram direcionadas para ele. As perguntas feitas ao gerente foram as seguintes: 1) Quais ferramentas você utiliza para gerenciamento do SVN? 2) Há apenas 1 repositório central? O repositório costuma ficar indisponível? 3) Como é feita a organização de pastas no SVN? Qual o objetivo de cada pasta? 4) Há dificuldades em saber quais alterações foram feitas no software, quem fez, e quando foram feitas? 5) No processo de desenvolvimento atual é utilizada alguma estratégia de branch? 6) Já ocorreram problemas de um desenvolvedor sobrescrever o código de outro? 7) Já foram enviados para a produção códigos que não deveriam ser enviados? 8) Em relação as releases, elas são planejadas? Possuem escopo e prazo de disponibilidade? 9) Mudanças são solicitadas com qual frequência? 10) Quando ocorre uma mudança, ela é registrada formalmente? 11) Há o costume de avaliar o impacto de uma mudança (cenário otimista, realista, pessimista)? 12) Quando uma mudança é recusada, ela é eliminada ou arquivada? 13) Liste os principais problemas/dificuldades encontrados em relação ao controle de versão e de mudanças. 14) O que você acha que pode melhorar em relação ao controle de versões e controle de mudanças? As perguntas feitas aos desenvolvedores foram: 1) Quais ferramentas você utiliza? 2) Quais ferramentas você utiliza para acessar o SVN? 3) Você enfrenta problemas com as ferramentas utilizadas? Quais? 4) Como você faz para desenvolver uma tarefa atribuída a você? 5) Você já sobrescreveu o código de outra pessoa por acidente? E o seu código, já foi sobrescrito? 6) Em relação ao processo de desenvolvimento de software, parece confuso? É satisfatório? Por quê? 7) O que você acha que pode melhorar em relação ao controle de versões e ao controle de mudanças? Por meio das respostas de cada pergunta, foi possível identificar como era o processo de desenvolvimento de software na organização, bem como as ferramentas utilizadas nesse processo e também diagnosticar a situação da gerência de configuração praticada na CSI/DGTI. Considerando as questões relacionadas às ferramentas utilizadas pelo gerente de configuração e pelos desenvolvedores, percebe-se um ambiente de desenvolvimento bem heterogêneo (1). Por exemplo, os desenvolvedores utilizam cinco ferramentas para desenvolvimento e cinco clientes SVN diferentes. Tabela 1 Ferramentas Utilizadas Ferramentas
Categoria Desenvolvimento
Eclipse, Geanny, Kate, NetBeans e NotePad++
Comparação de Código Merge e Meld
Controle de Versões
Subversion (SVN)
Controle de Mudanças
Redmine
Clientes do SVN
Plug-in Netbeans, Subversive e Subclipse (Plug-ins Eclipse), RapidSVN e TortoiseSVN
Gerenciamento do SVN SVNAdmin
Com relação ao desenvolvimento de tarefas, foi identificado que as mudanças não são planejadas. Quando uma mudança é solicitada, são analisadas apenas as possíveis consequências de sua implantação e tais análises não são documentadas. O SVN era a ferramenta utilizada para controlar as versões de desenvolvimento. Nele, existia um repositório central e a organização de pastas era feita de acordo com a 2. Pasta
Tabela 2 Organização das Pastas no SVN Descrição
Trunk
Local onde os desenvolvedores criavam ou modificavam os códigos
RC
Era usada para testes. Armazenava o que havia sido desenvolvido na Trunk
Tag
Armazenava as releases enviadas para produção
Homologação
Armazenava módulos grandes
Documentos
Armazenava o que foi feito nas releases e diagramas
Os desenvolvedores faziam uma cópia da pasta Trunk e começavam a desenvolver a tarefa atribuída a eles. Durante o desenvolvimento eram realizados updates e commits para atualizar o código local com as mudanças realizadas por outros e salvar o que havia feito. Nenhuma estratégia de branch era utilizada. Terminado o desenvolvimento, os códigos criados ou modificados eram mesclados de forma manual com os códigos existentes na RC para liberar para teste. O tester atualizava seu sistema e fazia um teste funcional informal. Caso encontrasse algum problema, ele retornava a tarefa para o desenvolvedor para que o mesmo realizasse as correções. Com o problema corrigido, o desenvolvedor precisava realizar novamente a mesclagem manual para a RC para que o tester prosseguisse o trabalho. Se nenhum problema fosse encontrado, a tarefa ganhava o status de liberada para release e era atribuída ao gerente de configuração. O gerente realizava, de forma manual, a junção dos códigos desenvolvidos ou modificados. Inclusive foram relatados, na entrevista, casos nos quais foram enviados, para produção, códigos que não deveriam constar em determinada release. A publicação de uma nova versão em produção deveria ser a cada quinze dias, mas isso não ocorria, pois o gerente aguardava acumular solicitações para liberar uma release devido ao grande trabalho envolvido para a preparação da mesma. 4.2. Análise A gerência de configuração de software procura garantir que todos os itens de um produto sejam rigorosamente mantidos sob controle e todas as alterações devem ser registradas [6]. Nesses registros, são encontradas as razões das modificações solicitadas, quem solicitou e quem realizou a modificação. Entretanto, não havia uma descrição formal da solicitação e da solução das mudanças. As mudanças não eram planejadas e não havia rastreabilidade das mesmas. Apesar de serem analisadas as possíveis consequências de sua implantação, não eram criados cenários otimistas, realistas e pessimistas para avaliar o impacto de uma mudança. O gerenciamento da RC e da Trunk era confusa. Nenhuma estratégia de branch era utilizada pelos desenvolvedores e a Trunk não era utilizada como a versão mais estável. Códigos incompletos ou que não eram necessários eram enviados para a mesma e quando os desenvolvedores faziam atualizações, esses códigos eram recebidos por todos. Era difícil verificar quem havia enviado/modificado os arquivos. Ao enviar uma tarefa para teste, frequentemente o tester alegava que não havia recebido o trabalho devido às falhas no processo manual de envio dos códigos para a
RC. Além disso, como poderiam existir códigos na RC que não deveriam ir para produção, o gerente precisava retirá-los manualmente. Por esta razão, ocorreram casos nos quais foram enviados para a produção códigos que não deveriam ter sido enviados. Para esse caso, em que uma implementação possui o risco de afetar a integridade da Trunk, o ideal é que o SVN utilize três diretórios com funções bem definidas [9]: Trunk: armazena a versão funcional mais recente de desenvolvimento. Branches: armazena versões de desenvolvimento paralelo oriundas da Trunk, porém isoladas desta. Tag: armazena etiquetas para facilitar a localização de revisões. Cada etiqueta possui um nome único que a identifica, sendo criada sempre a partir da Trunk. O SVN estava sendo utilizado de forma insatisfatória, pois não mesclava automaticamente os códigos desenvolvidos ou modificados. Eram utilizadas exclusivamente ferramentas de comparação de arquivos para indicar onde haviam diferenças entre os códigos, tornando o processo de mesclagem extremamente manual, trabalhoso e propenso a erros. Problemas com códigos sobrescritos não ocorriam frequentemente, mas já haviam acontecido. Em uma delas, um código instável estava atrapalhando outra ferramenta em desenvolvimento. Então, ele foi comentado e quando foi realizado um update, o restante da ferramenta parou de funcionar. O processo para gerar uma release era muito trabalhoso e demorado, pois tudo era validado de forma manual. As releases não eram bem planejadas. Existiam solicitações que eram atendidas em uma semana, mas disponibilizadas em produção apenas depois de um mês ou mais. 4.3. Proposta de Uso do Controle de Versão O SVN é capaz de mesclar automaticamente arquivos com código, tornando o processo mais simples e rápido [9]. Apenas quando ocorrem conflitos, isto é, quando dois ou mais desenvolvedores modificam as mesmas linhas de um arquivo, a mesclagem deve ser feita de forma manual. Deste modo, foi proposta a adoção do uso de branches no SVN. Conforme diagnosticado, a Trunk recebia códigos incompletos ou desnecessários. Isto também contribuía para que uma release demorasse a ser gerada. O uso de branches permitiria que o SVN fosse utilizado de forma mais correta, e consequentemente agilizaria a mesclagem dos códigos e a identificação de quem os havia desenvolvido. A Trunk deveria ser utilizada como a versão funcional mais recente. Sugeriu-se, o uso da estratégia de branch por tarefa, ou seja, para cada solicitação atribuída a um desenvolvedor, o mesmo deveria criar uma branch para essa solicitação e desenvolver dentro dela. Terminado o desenvolvimento, o código deveria ser enviado para teste, e caso não tivesse problemas, deveria ser enviado ao gerente para que ele realizasse a mesclagem do código desenvolvido com o da Trunk. A cada atualização da Trunk, sugeriu-se disparar um e-mail a toda equipe de desenvolvimento informando que a mesma foi atualizada. Através desse e-mail, o desenvolvedor ficaria ciente que era preciso atualizar sua branch para que não ocorresse um overhead no processo de mesclagem quando uma solicitação demandasse uma maior tempo de desenvolvimento. Se bem executada, a estratégia de branch tornaria o processo de desenvolvimento menos confuso e facilitaria o processo de geração de uma release, pois as mesclagens seriam feitas de forma automática pelo próprio SVN, tornando possível a liberação de uma nova versão dentro do prazo estipulado. O planejamento de releases é importante pois ajuda a equipe a definir o quanto de funcionalidade será criada para a próxima versão [10]. Além disso, o planejamento de releases define o escopo e também quando a mesma estará disponível. Outra mudança proposta foi a padronização das ferramentas de desenvolvimento pois os desenvolvedores utilizavam ferramentas diferentes. O trabalho padronizado reduz desperdícios, diminui a carga de trabalho e riscos de acidentes, e aumenta a produtividade e a satisfação dos
trabalhadores [11]. Dessa forma, a utilização das mesmas ferramentas para o desenvolvimento contribuiria para que a equipe trabalhasse de forma mais produtiva e também para que eventuais problemas com essas ferramentas fossem resolvidos de forma mais rápida. 5. IMPLANTAÇÃO A partir da elaboração da proposta, foi realizada uma apresentação da mesma a toda a equipe de desenvolvimento para que todos pudessem opinar e se inteirar sobre os problemas encontrados. Esta apresentação foi muito importante para nivelar o conhecimento da equipe sobre os temas de Gerência de Configuração, Controle de Versão e a utilização de branch no SVN. Após a apresentação e o consenso de que deveriam ser realizadas as mudanças propostas, foi elaborado um plano detalhado com os passos a serem realizados para a migração dos códigos do SVN e os planos de contenção caso ocorresse algum problema. A primeira ação foi a mudança no modo como o SVN estava sendo utilizado. Como isto envolvia uma troca de onde o código estava sendo desenvolvido (Trunk) para uma nova abordagem (Branch), foi necessária uma ação conjunta com todos desenvolvedores. Primeiramente foi feita uma reunião com a equipe solicitando a todos que realizassem o commit na Trunk das atividades em andamento e fizessem um backup na própria máquina do que não podia ser realizado o commit por motivos de ainda não estar estável. Foi, então, criada uma branch para armazenar os códigos que estavam na Trunk para que os desenvolvedores pudessem utilizar para realização da migração dos códigos das tarefas em desenvolvimento para as respectivas branches. O próximo passo foi retirar a permissão de commit de todos os desenvolvedores na Trunk. Foi feita uma comparação entre a Trunk e a Tag que continha a versão do sistema que estava em produção para retirar da Trunk tudo que não estava na aplicação em produção. Outra preocupação, foi deixar na Trunk configurações próprias para o ambiente de desenvolvimento para que sempre que for criada uma nova branch o desenvolvedor já possa começar a trabalhar sem precisar se preocupar sempre com as mesmas configurações. Além disso, foi feita uma organização geral no SVN retirando diretórios de testes e temporários que existiam na Trunk e criando pastas para guardar scripts antigos e códigos de exemplo. Após o termino da comparação entre os arquivos, foi feito um teste para garantir que a Trunk estava correta e realizado o commit. Foram atualizadas as permissões nas pastas do SVN de acordo com a 3. Tabela 3 Grupos de Permissões e seus Membros Descrição
Grupo Admin
Permissão total em todo o repositório
Develop
Permissão de leitura em todo o repositório e escrita na pasta branches
Leitura
Permissão de leitura em todo o repositório
Membros Gerente de Configuração Desenvolvedores Tester e Coordenadores
Os desenvolvedores receberam treinamento sobre como ficou o processo de desenvolvimento e como são realizadas, no Subversive – plug-in para o Eclipse –, as funções básicas do SVN que seriam utilizadas. Além disso, foi elaborado um documento com um passo a passo da realização destas atividades no Eclipse/Subversive e disponibilizado para eles. Depois deste treinamento, foi solicitado para que cada desenvolvedor criasse as branches para as tarefas que estavam em desenvolvimento e adicionassem os códigos já desenvolvidos para a tarefa até aquele momento, na branch criada. Outra melhoria realizada, foi a padronização dos softwares utilizados pela equipe de desenvolvimento. O ambiente foi padronizado para que todos utilizassem o Eclipse como ferramenta para o desenvolvimento. O Meld como ferramenta para realizar comparações de código e o Subversive como cliente SVN. 6. RESULTADOS
No início, os desenvolvedores tiveram algumas dificuldades para se adequarem ao novo processo de desenvolvimento. Inclusive, alguns ainda utilizaram os métodos manuais para mesclagem de código por esquecimento. Estes casos foram mitigados por meio do acompanhamento das atividades e esclarecimento das dúvidas. No primeiro processo de geração de uma release, após a migração para o processo de branches, haviam 12 tarefas para serem enviadas para produção. Foi, então, criada uma branch a partir da Trunk para servir de base para a realização da mesclagem. Deu-se início ao processo utilizando a ferramenta do próprio SVN para mesclar as tarefas. Apenas três ramos apresentaram problemas. Nestes, o SVN indicou muitos conflitos que na verdade não deveriam existir. Isto ocorreu pois os ramos foram criados a partir da Trunk antes do processo de migração. Estas branches estavam sendo utilizadas em carácter experimental para testar como funcionaria o desenvolvimento por branches. Para estes casos ainda foi necessário realizar o processo manual de mesclagem utilizando a ferramenta Meld. Para a próxima release foi necessário realizar a mesclagem de oito tarefas desenvolvidas cada uma em seu respectivo branch. Nesta, não houve problemas e o processo foi muito fácil e rápido segundo o gerente de configuração. Após quinze dias, houve outra release com cinco tarefas e não ocorreu problemas na realização da mesclagem. A próxima versão continha três casos, porém foi identificado um erro de desenvolvimento pouco antes da mesma ser enviada. Esta situação explicitou o quanto a nova abordagem facilitou a construção das releases, pois o gerente apenas não enviou o código com o resultado das mesclagens para produção e excluiu do SVN a branch que ele havia criado para montar a release. O desenvolvedor iniciou a correção do caso problemático na sua branch. Como essa correção seria demorada, as outras tarefas foram enviadas para produção sem maiores problemas no dia seguinte pois realizou-se a mesclagem rapidamente. Esta foi a última release enviada para produção até a data de escrita deste artigo. Segundo avaliação do Gerente de Configuração, a mudança foi muito positiva visto que o processo de preparação destas releases, mesmo envolvendo diversas tarefas, foi muito fácil. Outro detalhe, foi o tempo levado para prepará-las. No processo anterior, cada lançamento de uma nova versão demorava cerca de oito horas visto que era feita de forma manual. Com a utilização das branches e da funcionalidade do próprio SVN para realizar as mesclagens, a preparação demorou menos de uma hora. Fato que nunca havia ocorrido anteriormente. Além disso, o processo ficou menos propenso a erros já que a mesclagem passou a ser realizado automaticamente, precisando de intervenção manual apenas na resolução de conflitos. Segundo o tester, as mudanças representaram uma melhoria significativa nas suas atividades pois uma tarefa não interfere mais na outra e, portanto, não ocorrem mais casos nos quais o erro em uma tarefa influencia os testes de outra, visto que antes todas ficavam juntas na pasta RC. Além disso, ficou mais fácil realizar testes específicos para determinada tarefa tendo certeza que estão sendo realizados como se fosse o sistema que está em produção apenas acrescido das novas funcionalidades desenvolvidas para a tarefa. Outro ganho observado, foi com relação ao tempo de retorno dos desenvolvedores na correção de erros. Antes, mesmo a correção de erros simples demorava visto que o desenvolvedor precisava corrigir na Trunk e depois replicar a correção manualmente na RC. Segundo os desenvolvedores, a mudança ajudou nas tarefas diárias, pois não precisam mais realizarem o desenvolvimento e depois mesclar o código desenvolvido com a RC para liberar para testes. Isso sem contar todas as implicações que esta atividade causava quando eram identificados erros durante os testes. Além disso, eles podem realizar commits com maior frequência visto que os códigos envolvem apenas as tarefas que estão trabalhando e não afetam outros desenvolvedores alocados em outras tarefas. Outro ponto observado, foi que a padronização do ambiente ajudou na mudança, pois todos passaram a utilizar as mesmas ferramentas e isto facilitou o treinamento das pessoas e possibilitando que os próprios desenvolvedores se ajudassem em dúvidas.
Uma questão importante foi que, à exceção do intervalo da primeira para a segunda release no qual houve uma demora maior devido a fatores externos ao ambiente de desenvolvimento, a liberação de releases passou a respeitar o intervalo de quinze dias desejado. Inclusive com a possibilidade de realização de publicações em prazos menores em caso de necessidade. 7. CONSIDERAÇÕES FINAIS Desde a mudança até o fim de maio de 2014, foram realizadas quatro novas releases de produção contendo vinte e sete tarefas ao todo. Como pode ser observado, estas releases foram bem sucedidas no sentido de que foram várias tarefas e o processo foi bem prático, rápido e menos propenso a erros. Como pode ser verificado com a opinião dos envolvidos, a migração e a padronização do ambiente apresentou uma boa aceitação por toda a equipe e teve um impacto muito positivo. Infelizmente não há uma medida quantitativa da produtividade anterior e posterior para poder comparar porém, apesar de ser uma avaliação apenas qualitativa, baseada nos relatos dos envolvidos, acredita-se que houve um ganho na produtividade visto que o processo passou a ser mais eficiente. Além disso, esta utilização trouxe uma segurança maior para a implantação de novas versões visto que as comparações de códigos passaram a ser realizadas de forma automática pelo próprio SVN. Como trabalhos futuros, espera-se fortalecer os conceitos da gerência de configuração na Coordenadoria de Sistemas do DGTI e passar a ter uma gestão maior das mudanças, avaliando impactos, utilizando baselines e mantendo uma rastreabilidade entre os requisitos. Estas mudanças dependem também de uma amadurecimento maior nas áreas de Gerência de Requisitos e Gerência de Projetos. Além disso, será mantido o acompanhamento do novo processo para identificar pontos que podem ser otimizados. 8. REFERÊNCIAS BIBLIOGRÁFICAS [1] DIRETORIA DE GESTÃO DE TECNOLOGIA DA INFORMAÇÃO – DGTI. Plano Diretor de Tecnologia da Informação 2011-2012 – PDTI (2011). Disponível em: . Acessado em 23/04/2014. [2] SOMMERVILLE, I. Engenharia de Software. 8ed. São Paulo: Pearson, 2007. [3] GALIN, D. Software Quality Assurance: From Theory to Implementation. 1ed. Pearson, 2004. [4] ESTUBLIER, J. Software Configuration Management: A Roadmap. In: Conference on the Future of Software Engineering, p. 279-289, June 4-11, Limerick, Ireland, 2000. [5] BROWN, W. J. et al. Antipatterns and Patterns in Software Configuration Management. New York: Wiley Computer Publishing, 1999. [6] PRESSMAN, R. Engenharia de Software. 2ed. São Paulo: McGraw-Hill, 2006. [7] MURTA, L. G. P. Gerência de Configuração no Desenvolvimento Baseado em Componentes. 213p. Tese de Doutorado, COPPE, UFRJ, Rio de Janeiro, Brasil, 2006. [8] BIRMELE, C. Branching and Merging Primer, 2006. Disponível em http://msdn.microsoft.com/en-us/library/aa730834%28VS.80%29.aspx. Acessado em 23/04/2014. [9] COLLINS-SUSSMAN, B. et al. Version Control with Subversion, 2013. Disponível em http://svnbook.red-bean.com/en/1.7/svn-book.pdf. Acessado em 23/04/2014. [10] COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006. [11] KISHIDA, M. et al. Benefícios da Implementação do Trabalho Padronizado na Thyssenkrupp. Lean Institute Brasil, 2006.
