SVN: conceitos, boas práticas e dicas de utilização
Em Programação | 11/04/2010 03:20Introdução
Como grande apreciador e usuário há anos do SVN, não poderia deixar de dedicar um pequeno artigo sobre esta fantástica ferramenta de controle de versão, principalmente pela escassez de materais na Internet discutindo seus conceitos de forma pragmática.
Assim, resolvi aproveitar alguns materiais que eu havia escrito para utilização pelos times de desenvolvimento nos quais atuo, incrementei alguma coisinha aqui e acolá e preparei este estrambolicamente dupper master quase infinito artigo.
Para facilitar a leitura, dividi o artigo em 7 partes:
- Público alvo: comentários sobre a quem se destina a leitura deste artigo;
- Controle de versão e SVN: o que é controle de versão e como o SVN se encaixa nesse paradigma;
- Termos e conceitos básicos: conceitos básicos para entendimento do funcionamento e organização do SVN;
- Boas práticas: breve manual de boas práticas na utilização do SVN;
- Dicas de utilização: dicas diversas de utilização do SVN;
- Ferramentas de apoio: algumas ferramentas interessantes para tornar o uso do SVN mais prático.
- Ao infinito e além: costumeira lista de links interessantes.
Público alvo
O cerne deste artigo não é a discussão da utilização do SVN a partir de comandos ou questões técnicas da ferramenta. Para tal, há documentações, livros e artigos na rede muito completos sobre o tema. O público alvo deste artigo são utilizadores do SVN que já tenham familiaridade com suas idiossincrasias e que desejam um melhor entendimento do modelo organizacional da ferramenta e de como estruturar um processo em torno do SVN para tornar mais eficaz o gerenciamento do código-fonte de suas aplicações.
Controle de versão e SVN
Controle de versão é a arte de gerenciar mudanças em informações. Para programadores, é um paradigma obrigatório a ser seguido para assegurar a saúde do código-fonte, ainda mais em grandes equipes atuando cada qual em partes distintas de um projeto.
Você, desenvolvedor, também precisa de umamáquina do tempo para seu código.
O Subversion, ou simplesmente SVN, é uma ferramenta de controle de versão muito poderosa que permite, além do desenvolvimento colaborativo a partir de um repositório único, merge de conteúdo, armazenamento de logs e geração de estatísticas diversas.
Atuando como a máquina do tempo do desenvolvedor, ferramentas com o SVN permitem retornar o código a um estado anterior, facilitando a análise implementações realizadas e a mesclagem de implementações distintas de períodos diferentes para a criação de uma única versão.
(Embora eu seja fãzaço e ávido partidário do SVN, tenho flertado nos últimos tempos com os ótimos Mercurial e GIT, os quais têm realmente me surpreendido e me feito repensar o uso do meu amado idolatrado salve salve SVN. Todavia, isso fica para outro artigo...)
Termos e conceitos básicos
- Repositório
- É o local aonde estão contidos todos os arquivos do projeto. É armazenado no banco de dados do SVN.
- Working Copy
- Literalmente, uma cópia de trabalho local na qual o desenvolvedor atua. É criada sempre que é feito checkout de algum projeto.
- Checkout
- Ato de fazer download de um projeto para a máquina local, de modo que seus arquivos estejam vinculados ao SVN e passíveis de manipulação. O projeto para o qual será feito o checkout deve existir no repositório.
- Import
- Ato de envio dos arquivos de um novo projeto para o repositório. Após o import, obrigatoriamente um checkout deve ser realizado para que a working copy seja vinculada ao SVN.
- Export
- Ato de obtenção de um projeto do repositório sem vinculação ao SVN.
- Commit
- Ato de envio das modificações realizadas localmente para o servidor SVN.
- Update
- Ato de obtenção das atualizações presentes do servidor SVN, atualizando a cópia local
- Revision
- Número que identifica cada uma das alterações ou conjunto de alterações realizadas em um repositório. Tal número é obtido a partir de uma sequência a qual é compartilhada por todos os diretórios do repositório.
- HEAD
- É a revisão mais recente do repositório
- Diretórios especiais
- Existem no SVN três diretórios especiais com funções bem definidas:
- trunk: armazena a versão funcional mais recente de desenvolvimento.
- branches: armazena versões de desenvolvimento paralelo oriundas do trunk, porém isoladas deste. Deve ser utilizado quando uma implementação trazer o risco de afetar a integridade do trunk.
- tags: armazena etiquetas para facilitar a localização de revisões. Cada etiqueta possui um nome único que a identifica, sendo criada como um diretório, sempre através do trunk.
- Branch/Tag
- Refere-se à geração de branches ou tags a partir de um trunk ou geração de um branch a partir de uma tag ou outro branch.
- Merge
- Refere-se à mesclagem de revisões entre os diretórios especiais. Sempre deve ser realizada com a working copy apontando para o destino do merge.
- Switch
- Alteração do repositório utilizado por uma working copy. É realizada uma atualização ou mesclagem dos arquivos para assegurar que a working copy contenha exatamente o conteúdo do novo repositório mais quaisquer alterações locais.
- Relocate
- Realocação do endereço de um repositório. Apenas atualiza o endereço, sem realizar nenhum tipo de atualização nos arquivos.
Boas práticas
- Toda revisão deve ser comentada para facilitar o entendimento das alterações realizadas.
- O código no trunk deve sempre estar pronto para ser compilado e colocado em produção se necessário. Nesse sentido, uma ferramenta de Integração Contínua, como o CruiseControl, deve ser utilizada para a geração de builds de teste a cada commit e todas as noites ao longo da semana.
- É dever de cada programador assegurar que seus commits não causem a quebra do build. Novamente uma ferramenta de Integração Contínua pode auxiliar nesta tarefa.
- As alterações em um código-fonte devem ser submetidas ao repositório o mais rápido possível. Para tal, é recomendável a divisão das implementações em pequenos pacotes compiláveis e funcionais ou, ao menos, que não causem a quebra do build. Quanto mais tempo um arquivo mantém-se na máquina de um desenvolvedor em edição, mais difícil será sua mesclagem e maior será o risco de quebra de build.
- Toda a quebra de build deve ser tratada com máxima prioridade no sentido de sua correção. Mais uma vez uma ferramenta de Integração Contínua pode auxiliar nesta tarefa.
- Caso um build esteja quebrado, não se deve submeter alterações ao repositório até que o build seja novamente compilável. Isso assegura que todos os que realizarem updates terão sempre uma versão compilável e funcional oriunda do repositório.
- O projeto no repositório deve conter quaisquer componentes e ferramentas necessárias para o funcionamento da aplicação na máquina do desenvolvedor.
- Evitar o envio de alterações próximo do fim do expediente. Caso haja algum problema com o commit realizado, poderá não haver tempo para corrigi-lo naquele dia e o build poderá ficar quebrado por um longo período.
- Todo e qualquer backup de versões deve ser mantido no repositório, preferencialmente como uma tag.
Dicas de utilização
Uso do trunk
O trunk sempre representa a última versão de desenvolvimento disponível. Nesse sentido, é aqui que ocorre a integração do projeto a partir de builds automatizados e é aqui que a versão funcional mais recente deve estar presente.
É do trunk também que os branches e tags devem ser gerados (embora branches possam ser gerados de tags e outros branches sem restrições técnicas). A ferramenta de revisão gráfica do TortoiseSVN (Revision Graph) permite visualizar os relacionamentos entre as pastas especiais a partir de diagramas.
Fluxo básico de atividades
O fluxo básico de atividades no repositório consiste na utilização do trunk como ponto principal de checkout para o desenvolvimento. Entretanto, quaisquer tarefas que possam causar grande impacto no trunk devem ser realizadas em um branch separado, o qual receberá as alterações do trunk ao longo do dia ou ao fim do dia para que este seja mantido atualizado.
Tags são utilizadas como backups e marcação de releases diversos do projeto.
Segue abaixo explanação da utilização do fluxo:
- Geração de backup da versão do trunk para marcação de um ponto de restauro rápido antes do início dos branches a partir da opção Branch/Tag (opcional);
- Criação de branch para realização de nova implementação que pode impactar no trunk a partir da opção Branch/Tag;
- Integração de alterações realizadas no trunk ao branch a partir da ferramenta de mesclagem Merge a Range of Revisions;
- Criação de nova branch para realização de nova implementação que pode impactar no trunk a partir da opção Branch/Tag;
- Conclusão do primeiro branch criado, ocorrendo a reintegração deste no trunk a partir da ferramenta de mesclagem Reintegrate a Branch e sua deleção;
- Atualização da segunda branch criada com as atualizações recém realizadas no trunk a partir da ferramenta de mesclagem Merge a Range of Revisions;
- Conclusão da segunda branch criada, ocorrendo a reintegração desta no trunk a partir da ferramenta de mesclagem Reintegrate a Branch e sua deleção;
- Geração de etiqueta de release da versão do trunk a partir da opção Branch/Tag.
Fluxo básico de atuação em projeto fechado
Quando em atuação em projetos fechados de customização a um cliente, tem-se comumente uma única versão da aplicação em produção, além de outras em ambientes diversos, como por exemplo homologação e testes.
Neste caso, o fluxo básico de atividades também é utilizado. Entretanto, a cada release gerado, além da tag é criado um branch que representa a versão criada. Assim, tem-se no trunk a última versão de desenvolvimento e, em branches separados, cada uma das versões implantadas em ambientes diversos.
Dessa forma, pode-se prestar manutenção às versões presentes em cada um dos ambientes da aplicação de forma simples. Toda vez que uma nova versão de um determinado ambiente é gerado, o branch anterior para tal ambiente é excluído.
Neste fluxo, sempre se espera que todas as revisões do trunk anteriores ao release façam parte deste, não havendo seleção de revisões na concepção de releases.
Segue abaixo explanação da utilização do fluxo:
- Geração de backup da versão do trunk para marcação de um ponto de restauro rápido antes do início dos branches a partir da opção Branch/Tag/ (opcional);
- Criação de branch para realização de nova implementação que pode impactar no trunk a partir da opção Branch/Tag;
- Integração de alterações realizadas no trunk ao branch a partir da ferramenta de mesclagem Merge a Range of Revisions;
- Conclusão do primeiro branch criada, ocorrendo a reintegração deste no trunk a partir da ferramenta de mesclagem Reintegrate a Branch e sua deleção;
- Geração de etiqueta de release da versão do trunk a partir da opção Branch/Tag;
- Criação de branch para o release recém gerado a partir da opção Branch/Tag;
- Mesclagem das alterações realizadas no branch do release ao trunk a partir da ferramenta de mesclagem Reintegrate a Branch. Tal branch se manterá ativo enquanto a versão que o representa estiver em utilização.
Fluxo de atuação em projeto fechado com mesclagem de revisões
A exemplo do Fluxo básico de atuação em projeto fechado, neste fluxo também se considera que há apenas uma única versão da aplicação em produção, além de outras em ambientes diversos, como por exemplo homologação e testes.
Nesta técnica, o fluxo básico de atividades também é utilizado. Entretanto, a cada release gerado, é criado primeiramente um branch baseado em uma tag anterior de ambiente, no qual ocorre mesclagem de revisões do trunk, para que somente após o commit de tal branch seja criada uma nova tag de release que aponte para tal branch (o qual, por sua vez, aponta para o trunk).
Assim, tem-se no trunk a última versão de desenvolvimento e, em branches separados, cada uma das versões implantadas em ambientes diversos, sendo que tais versões, embora venham do trunk, são geradas sempre a partir de tags de versões ante
rios, mantendo dessa forma a seleção de revisões realizada.Dessa forma, pode-se prestar manutenção às versões presentes em cada um dos ambientes da aplicação de forma simples, além da geração de releases baseados em determinadas revisões do trunk.
Toda vez que uma nova versão de um determinado ambiente é gerado, o branch anterior para tal ambiente é excluído.
Segue abaixo explanação da utilização do fluxo:
- Considerando-se importação inicial do repositório, deve-se inicialmente criar-se uma tag de release para algum dos ambientes, a qual servirá de base para geração do branch do ambiente com o qual a tag se relaciona a partir da opção Branch/Tag;
- Criação de branch para a tag do release recém criado a partir da opção Branch/Tag. Tal branch se mantém ativo enquanto a versão que o representa estiver em utilização.
- Criação de feature branch para realização de nova implementação que pode impactar no trunk a partir da opção Branch/Tag. O uso desse tipo de branch deve ser avaliado com cautela. O trunk deve sempre ser a versão mais recente de desenvolvimento;
- Integração de alterações realizadas no trunk ao feature branch a partir da ferramenta de mesclagem Merge a Range of Revisions;
- Conclusão do feature branch criado, ocorrendo a reintegração deste no trunk a partir da ferramenta de mesclagem Reintegrate a Branch e sua deleção;
- Reintegração de correções de bugs realizadas no branch do release atual de algum dos ambientes ao trunk a partir da ferramenta de mesclagem Reintegrate a Branch;
- Exclusão do branch de algum dos ambientes por conta de nova versão a ser criada para tal ambiente;
- Criação de nova branch para o ambiente a ter a nova versão disponibilizada a partir da tag do último release do ambiente desejado utilizando-se da opção Branch/Tag;
- Mesclagem de revisões do trunk na nova branch de release a partir da ferramenta de mesclagem Merge a Range of Revisions e posterior commit destas alterações na própria branch;
- Geração de etiqueta de release da versão criada a partir do novo branch utilizando-se da opção Branch/Tag;
- Mesclagem das alterações realizadas no branch do release ao trunk a partir da ferramenta de mesclagem Reintegrate a Branch. Tal branch se manterá ativo enquanto a versão que o representa estiver em utilização.
Fluxo de atuação em projeto fechado com múltiplos branches
Tal fluxo é uma derivação do Fluxo básico de atuação em projeto fechado. Diferente daquele, neste todas as alterações sempre são realizadas em branches que posteriormente são reintegrados ao trunk. Quaisquer versões a serem geradas (produção, homologação, teste, etc.) são criadas a partir de merge de revisões a partir do trunk sobre o próprio trunk ou de branches sobre o trunk, com posterior geração de novas branches e tag para tal versão.
Neste fluxo, o trunk é utilizado como a versão mais completa da aplicação, contendo todas as implementações já realizadas em branches separados.
O uso dos branches se dá para facilitar a divisão de tarefas e organização das alterações, de modo que solicitações descartadas sejam facilmente ignoradas e não reintegradas ao trunk.
Segue abaixo explanação da utilização do fluxo:
- Geração de backup da versão do trunk para marcação de um ponto de restauro rápido antes do início dos branches a partir da opção Branch/Tag (opcional);
- Criação de branches para realização de novas implementaões a partir da opção Branch/Tag. Como o trunk possui todas as implementações já realizadas, tais branches devem ser criados com base em revisões específicas do trunk que contenham apenas as implementações desejadas;
- Integração de alterações realizadas no trunk aos branches a partir da ferramenta de mesclagem Merge a Range of Revisions (opcional – diferente dos fluxos anteriores, a obtenção das últimas alterações pode não ser necessária, uma vez que um branch pode referir-se a uma revisão específica e não necessariamente à última versão presente no trunk);
- Conclusão dos branches criados, ocorrendo a reintegração destes no trunk a partir da ferramenta de mesclagem Reintegrate a Branch e posterior deleção;
- Geração de release a partir do trunk. Neste fluxo, a geração de release ocorre mesclando-se revisões do trunk em uma working copy de uma revisão específica (não necessariamente a mais recente) do próprio trunk ou dos branches. Assim, pode-se escolher exatamente quais revisões entrarão em uma release, assegurando pleno gerenciamento da montagem de uma versão. A criação do branch é feita a partir da opção Branch/Tag;
- Geração de etiqueta de release a partir do branch recém gerado através da opção Branch/Tag;
- Mesclagem das alterações realizadas no branch do release ao trunk a partir da ferramenta de mesclagem Reintegrate a Branch. Tal branch sempre estará disponível, não sendo excluído do repositório.
Ferramentas de apoio
- Apache Subversion: versão oficial do Subversion.
- VisualSVN Server: implementação em Windows prática e fácil de instalar do servidor SVN oficial. Possui ambiente gráfico de gerenciamento e permite visualização do conteúdo dos repositórios diretamente pelo navegador.
- TortoiseSVN: a melhor ferramenta gráfica para utilização do SVN em ambiente Windows.
- RabbitVCS: embora o pessoal de Linux é acostumado a digitar centenas de comandos diariamente em suas distribuições, esta ferramenta gráfica para utilização do SVN em Linux inspirada no grande TortoiseSVN torna mais prático o gerenciamento do projeto diretamente no Nautilus.
- Commit Monitor: permite o recebimento de alertas a cada commit realizado nos repositórios SVN.
- CruiseControl e CruiseControl.NET: ótimas ferramentas de Integração Contínua. Esta completa entrada na Wikipedia é uma excelente referência de ferramentas de Integração Contínua.
Ao infinito e além
Caso tenha alguma dúvida, curiosidade, trauma ou angústia sobre o artigo, ou apenas deseja elogiá-lo, utilize o espaço de comentários mais abaixo para entrar em contato.
Seguem abaixo alguns links interessantes:
- Subversion Documentation, documentação oficial do SVN.
- Controle de Versão com com Subversion, clássico livro sobre utilização e gerenciamento de repositórios SVN.
- Subversion Commands and Scripts, lista de comandos SVN no Linux.
- Subversion (software), artigo na Wikipedia sobre SVN.
- Subversion Cheat Sheet, ótimo cheat cheat de uso do SVN.
Ola intentor. muitoo bom o post em!! A maioria das coisas que li, nem imaginava pra que servia rs!!
abç
ResponderCaro Emerson!
Agora é só aproveitar os conhecimentos adquiridos e usar SVN em seus projetinhos! =D
ResponderParabéns pelo post do conceito e utilização do controle de versões de arquivos.
Eu particularmente gosto muito de SVN, acho super simples de usar e muitas ferramentas tem integração nativas para Subversion.
Ahh se tivesse SVN nos projetos do colégio e da faculdade ficaria muito mais fácil fazê-los. srsrs.
abraços,
Thiago
ResponderSVN é fantástico, caro Thiago, com certeza! Mesmo eu flertando principalmente com o GIT, ainda tenho minhas raízes no SVN e o utilizo como principal repositório de arquivos.
E, de fato, se usássemos SVN na época do colégio e mesmo em projetos da faculdade, ajudaria muito (de fato, nos meus projetos de games da faculdade, utilizo o SVN para mantermos nosso repositório centralizado).
E, seja o que for, usar um servidor de repositórios em projetos computacionais é mais do que OBRIGATÓRIO!
ResponderCara Intentor peco desculpa por este ato falho como pode perceber os post do blog sempre coloco a fonte de origem da noticia e no seu caso devo ter esquecido, porem no titulo tem o link original da noticia nao foi tao ruim assim (;
att
ps: muito bom seu artigo!
ResponderNo problem, Mr. catataw! Foi mais um alerta mesmo!
ResponderExcelente Post. Estamos aqui na empresa envolvidos com controles para os testes, que são executados pela equipe de teste, e não somente jUnit...
O texto foi muito útil para esclarecer pontos obscuros do SVN.
Abraço!
ResponderFico contente em saber que o texto tenha sido útil, caro João!
SVN às vezes é realmente misterioso!
ResponderSensacional artigo, Parabéns!
ResponderObrigado pela consideração, caro Charles! Espero que o texto tenha auxiliado a esclarecer suas dúvidas!
ResponderNão tenho nem palavras pra elogiar o post.
Simplesmente animal.
Já venho estudando o SVN a um tempo e até então não encontrei nenhum artigo que detalhe desta forma conceitual tão bem quanto o seu.
Meus parabéns.
ResponderCaro Frederico, obrigado! Particularmente gosto muito do SVN, e espero que você possa usá-lo com maior propriedade depois da leitura do artigo!
ResponderOlá Intentor,
Muito bom o post, gostei bastante.
Mas tenho umas dúvidas.
Em geral o merge que você faz dos branches para o trunk geram conflitos?
Pergunto, pois eu utilizava uma estratégia parecida e ela gerava um número enorme de conflitos quandos se adicionava coisas distintas em branches distintos. Então passei a utilizar uma estratégia em que faço o merge do branch que está sendo integrado ao
trunk diretamente para os outros branches ativos, tentando minimizar este conflitos durante a integração com o trunk.
Outra dúvida é se você costuma fazer testes funcionais no Trunk, pois no projeto em que trabalho não temos este hábito,
mas isto gerou problemas ao fazer a nossa última integração. :(
Então estamos reconsiderando esta abordagem.
Vlw
ResponderCaro Pablo! Obrigado pelos elogios!
Sobre a questão dos merges, em geral não tenho problemas com conflitos quando faço o "Reintegrate a Branch" para atualizar o trunk. Todavia, para que isso ocorra, sempre atualizo o branch com as alterações do trunk antes da reintegração, sendo que o branch deve ter sido criado inicialmente a partir do trunk para que o "reverse merge" utilizado pelo "Reintegrate a Branch" funcione corretamente. Se você criar um branch importando dados e depois tentar reintegrá-lo, terá infinitos conflitos (!). A primeira estratégia de uso do SVN listada no artigo, "Fluxo básico de atividades", mostra como funciona essa ideia.
Porém, levando em conta o que você comentou, sobre estar fazendo merge primeiro do branch no trunk e depois do mesmo branch para outros branches ativos, acredito que a melhor alternativa seria você, após fazer a reintegração no trunk, fazer um "Merge a Range of Revisions" do trunk com cada um dos outros branches ativos. Dessa forma, você assegura que as novas revisões que estão no trunk sejam levadas aos branches sem necessidade de utilizar o branch inicial como ponto de partida - o que com certeza irá reduzir a quantidade de conflitos que você terá.
Acerca da outra questão sobre testes funcionais, se bem a entendi, costumo fazê-los levando em conta blocos de atividades com um time de QA, e podem abranger tanto o trunk (no caso, uma versão que com certeza irá para homologação do cliente ou produção) quanto um branch ou vários branches mesclados, de acordo com a necessidade. Mas, na prática, esse tipo de teste não é automatizado.
O que costumo automatizar são testes unitários de funcionalidades específicas, e estes rodam automaticamente a partir de um servidor de integração contínua, o qual também se assegura de checar, a cada commit, se alguém quebrou o build (ou seja, a aplicação não compila ou algum teste unitário foi executado com erro). Esse tipo de abordagem auxilia bastante na localização de problemas e evita que membros do time baixem uma versão do projeto que não funcione, garantindo maior produtividade.
Espero tê-lo ajudado!
ResponderParabéns pelo post, estou utilizando de referência para um documento one estou trabalhando e colocando as devidas referências para seu post!
Abraços
ResponderCaro Rafael! Obrigado pela consideração!
Fico muito feliz em saber que o post esteja contribuindo para a criação de um documento de apoio na empresa aonde atua! É esse tipo de coisa que traz alegria ao blogueiro: saber que o post foi útil e ajudou outras pessoas!
ResponderNo caso do Fluxo básico de atividades teria que ser realizado os testes nas alterações todos os dias no fim do expediente, a dúvida ocorre porque teríamos que colocar a equipe de testes após o expediente normal da empresa, para poder testar o que foi realizado durante o dia.
ResponderJVWG,
Imagino que sua observação seja relacionada ao processo em sua empresa, certo? Talvez seja interessante mover esses testes para a manhã seguinte, não? O time de QA pode por exemplo obter a última revisão do dia, testá-la e reportar as observações encontradas.
Sinceramente não vejo necessidade de forçar os testes no fim do dia (talvez se você me explicar melhor seu fluxo de trabalho eu melhor entenda a questão). E, caso seja possível, avalie se esses testes não podem ser feitos de forma automatizada. Assim, você poderia liberar a equipe de QA para outros tipos de teste que exijam maior envolvimento humano - e, dessa forma, poupá-los de ficar até mais tarde. :-)
ResponderObrigado pela resposta. Em nossa empresa fechamos a versão parcial todos os dias ao fim da tarde, mas nem sempre conseguimos fazer os testes. Os testes automatizados nem sempre atingem todas as funcionalidades desenvolvidas e geralmente antes de disponibilizar a versão, temos um esforça muito grande para testar todo o sistema. Você aconselharia fazer um teste geral no sistema após um certo período ou após certa quantidades de branchs criados?
ResponderJVWG,
Agora entendi melhor sua dúvida! Bem, então vocês já usam testes automatizados, o que é ótimo. De fato, vocês até poderiam buscar uma ferramenta de testes que simule o usuário, assim vocês conseguiriam pelo menos validar certos retornos característicos do uso da interface e, assim, poupar o pessoal de QA - mas a verdade é que esse é muitas vezes um esforço tão grande que acaba por não valer tão à pena.
Porém, sendo direto em sua pergunta, eu diria "depende".
Vou citar o caso da empresa aonde atuo como exemplo.
Lá, usamos Scrum. Nosso conceito de pronto é somente quando o QA valida a estória (uma funcionalidade baseada em uma necessidade do usuário). Assim, temos participação dos QAs ao longo de todo o projeto, e não necessariamente em branches ou no trunk - embora isso pode acontecer e de fato ocorre -, mas sim em revisões. Dependendo do projeto, boa parte do time atua diretamente no trunk, sendo que versões funcionais são tags que podem ser avaliadas a qualquer momento.
A cada milestone atingido (p. ex. uma versão que irá para homologação), o time de QA faz testes completos da aplicação, dessa vez de forma integrada, com todas as estórias disponíveis em uma versão.
Se você observar os fluxos acima, todos consideram que há alguém atuando no trunk enquanto branches são criados.
Em resumo, a meu ver o melhor não é envolver QA apenas na conclusão do sistema, de um milestone ou certos branches criados, mas sim ao longo de todo o desenvolvimento do projeto - e, assim, tentar evitar com que os companheirinhos de QA fiquem além do horário comercial!
Se ainda tiver dúvidas, por favor responda ao post!
ResponderIntentor,
obrigado pelo esclarecimento. Estamos usando sua matéria para rever nosso modelo.
ResponderMaravilha, JVWG! Precisando de algum apoio é só responder ao post!
ResponderOi Intentor,
Eu atualizei meu servidor SNV da versão 1.5 para 1.7, para habilitar alguns recursos, porém ainda nao consigo utiliza-lo. É necessario mais algum procedimento ?
P.s: oTIMO poST
ResponderOlá, Douglas!
Obrigado pela consideração sobre o post! =D
Sobre sua dúvida, de modo geral, apenas a atualização já deveria permitir o uso, principalmente se seu servidor estava normal antes disso. Verifique se não há algum problema de permissionamento (na dúvida, lance um chmod 777 -R no diretório dos repositórios e verifique se funciona), que é uma causa comum de problemas com novas instalações/atualizações do SVN.
ResponderOlá, Intentor.
Antes de tudo, parabéns pelo post, principalmente, pela abordagem em vários cenários, o que abrange mais dúvidas dos seus leitores e demonstra seu profundo conhecimento do assunto.
Trabalho num empresa onde a produção é intensa e temos várias demanas em paralelo, com vários pacotes sendo entregues e, muitas das vezes, com objetos compartilhados. O controle de versão dessa loucura toda fica a carga de cada líder de equipe, que "tem" que saber o que cada desenvolvedor está fazendo e se necessitará de mexer em algum objeto compartilhado. Temos vários tipos de artefatos: objetos de bancos( trigger, procedures, functions, forms, pkgs, etc). É um ambiente muito complexo. Minha atividade é implantar uma ferramenta de controle de versão mas, na verdade, o que mais me preocupa não é a ferramenta, mas o processo (o cenários aqui é a junção de todos os seus cenários acima! :) )
Minha dúvida é simples: vc já experimentou implantar um SVN por exemplo, numa estrutura grande/complexa? Caso afirmativo, pode me orientar nesta saga? Uma coisa é certa: deverei eleger uma pequena equipe para servir de piloto. Mas preciso de alguma orientação sobre processos, estrutura mais aderente, políticas de boas-práticas, neste caso...etc.
Agradeço pela sua atenção e qualquer ajuda será bem-vinda.
Abs.
ResponderObrigado pelos elogios, Carlos! De fato, tenho um bom relacionamento com o SVN, e ainda não consegui trocá-lo em favor do GIT ou do Mercurial, de tão grande que é meu carinho pela ferramenta!
E, poxa!, vocês não utilizam nenhum tipo de ferramenta de controle de versão?! Imagino a loucura que deve ser no seu dia-a-dia, ainda mais com projetos de grande porte!
Quanto à sua pergunta, já implantei e utilizei SVN nas mais diversas situações, desde projetos pequenos com menos de meia dúzia de indivíduos até algumas poucas dezenas de pessoas atuando ao mesmo tempo. E, posso lhe afirmar, o SVN "segura o tranco" em todas as situações. Porém, é sempre importante uma boa organização dos times de desenvolvimento para minimizar conflitos, principalmente durante a utilização de branches para separar melhor os times.
Em termos teóricos, este artigo já lhe dá todos os nortes que você precisa para começar a organizar a sua equipe. Não sei se vocês utilizam uma metologia ágil; caso não o façam, recomendo VEEMENTEMENTE! O ideal é você separar os times em pequenos grupos de 4 a 6 pessoas que possam atuar em pacotes de funcionalidades de pequena duração (de 1 a 2 semanas é um bom tamanho) e dividir as tarefas entre eles de modo a minimizar a concorrência de desenvolvimento (se um time está atuando na funcionalidade X, evite que outros times atuem nestas funcionalidades). E, se o tamanho do sistema for um problema, sempre é possível dividí-lo em pequenas partes funcionais que por sua vez podem ser divididas entre pequenos grupos de desenvolvedores.
Em termos práticos de SVN, no caso de um projeto gigantesco, você pode utilizar o "Fluxo de atuação em projeto fechado com múltiplos branches" para dividir TODAS as tarefas em branches e a sempre criar novas versões a partir da reintegração dos branches no trunk. Em qualquer fluxo que escolher, e principalmente neste último, é importante você eleger um build manager, o qual será o desenvolvedor responsável por criar versões de aplicação a partir da junção dos branches ou mesmo apenas a partir do trunk. Essa figura é fundamental para garantir a qualidade e estabilidade dos builds, e deve ser alguém que detenha grandes conhecimentos do sistema para que ele possa atuar com desenvoltura na resolução de conflitos ou mesmo em pequenas correções durante a criação de releases diversos. Inclusive você pode utilizar este mesmo indivíduo para auxiliar na correção de conflitos, principalmente se estes envolverem diferentes times (os quais, em tese, não estão familiarizados com as atividades que cada um está desenvolvendo).
Considerando que vocês atuam com grandes projetos (e muitas pessoas), também seria interessante a utilização de um servidor de integração contínua aliado ao SVN para avaliação dos builds, podendo inclusive já realizar testes unitários e geração de métricas de código.
Espero ter contribuído para a resolução de sua dúvida, e caso precise de algo mais específico, só responder ao artigo ou entrar em contato por e-mail.
E... boa sorte na sua implantação! =D
ResponderGostaria de saber se o svn tmb pode ser usado para manter versões de banco de dados ou é apenas usado, por exemplo, para manter codigo fonte sincronizados.
ResponderCaro Alx, obrigado pelo comentário!
O SVN pode ser utilizado perfeitamente para gerir versões de estruturas de banco de dados (scripts), mas não de seus dados. Não é uma prática que eu tenha visto por aí manter o banco de dados inteiro no SVN, até porque no geral os formatos dos arquivos são bastante específicos e o SVN irá tratá-los como binários, o que pode causar muitos confilitos dada a dificuldade de merge para estes casos. Porém, na prática, isso até poderia ser feito - entretanto, de minha parte, não recomendo.
ResponderObrigado pela resposta.
ResponderExiste algum subversion que funciona de maneira online, ou seja, voce pode fazer todas as operacoes sem precisar tem instaldo em seu computador/servidor o sistema propriamente dito?
ResponderCaro Mujhahid, obrigado pelo comentário!
Sinceramente não entendi muito bem sua pergunta, porém o máximo que você poderá fazer online com o SVN é consultar o conteúdo do repositório.
Para utilizá-lo-lo, é necessária uma ferramenta cliente instalada na máquina (como o TortoiseSVN), pois o SVN requer que você tenha uma cópia local de todos os arquivos do repositório com o qual você deseja trabalhar.
Espero ter conseguido esclarecer sua dúvida!
ResponderOK, deixa-me explicar de novo:
1. Por exemplo tens uma equipe de desenvolvedores, que o mas pratico seria usarem um sistema de controlo de version, que terias que instalar em algum servidor que provavelmente garantas que qualquer hora que um programador quiser poderá fazer um cheakout, sincronizar, commitar etc. ate agora estamos juntos!
2. Mas o que realmente quero saber eh, imagina que você não tem o tal servidor que podes garantir que esteja sempre disponível para qualquer momento algum programador da sua equipe sincronizar? então tenta-se procurar algum servidor que alguém possa deixa lo instalar os seus sistemas e que garanta que sempre esteja free. (Isso seria um servidor dedicado, que por ai deve custar 200Reais mensal), então pensei, será que o Proprio SVN não teria algo assim? um SVN online? que posso colocar la meu projeto sem precisar instalar o SNV-Server?
Conseguiste sincronizar com minha ideia?
ResponderCaro Mujhahid!
Agora entendi melhor sua dúvida. Existe hospedagem de SVN na nuvem, como o próprio Google Code. O impasse é que os gratuitos no geral não permitirão projetos privados (caso do próprio Google Code). Entre os serviços mais bacanas que conheço está o Assembla (http://www.assembla.com/). Recomendo que você dê uma curiada no site SVN Hosting Comparison (http://www.svnhostingcomparison.com/). Lá são apresentados todos os principais serviços de hospedagem SVN, permitindo filtrá-los para facilitar sua análise.
Caso esteja buscando por um serviço de hospedagem completo, a KingHost (http://www.kinghost.com.br/) fornece SVN para todos os seus planos de hospedagem a preços bem bacaninhas.
ResponderObrigado.
ResponderParabéns pelo post. Esclareceu minhas dúvidas quanto a trunk, branch e tag.
Eu só utilizo trunk e tag. Com o branch para desenvolver novas funcionalidades, fica mais fácil de integrar ao trunk, mantendo este sempre rodando.
ResponderObrigado! Fico contente em saber que o artigo foi útil!
ResponderOlá Intentor, primeiramente gostaria de agradecer por compartilhar seus conhecimentos e pela paciência em responder as dúvidas de seus leitores.
Muito obrigado mesmo.
Por falar em dúvida, eu tenho uma.
Trabalhamos com Clear Case da IBM e estamos em processo de transição para o SVN, porém estamos com dificuldades de adequar o processo utilizado hoje ao SVN.
O Clear Case detém o conceito de LABELS, o que facilita muito o cenário que utilizamos: Uma linha principal (equivalente ao trunk no svn), uma de INTEGRACAO, uma de HOMOLOGAÇÃO e uma de PRODUÇÃO. Todas as alterações são baseadas em atividades, por exemplo, uma nova funcionalidade é desenvolvida na linha principal e quando é concluída, é aplicada label de INTEGRACAO nessa revisão, dessa forma, as alterações realizadas são mescladas nessa linha. Uma vez testadas em INTEGRAÇÃO, é aplicada label de HOMOLOGAÇÃO na mesma revisão, dessa forma, mesclando as alterações de INTEGRACAO para HOMOLOGAÇÃO, e assim sucessivamente até PRODUÇÃO.
Dessa forma, se possível, gostaria de uma dica sua quanto ao melhor processo a ser seguido no SVN para que se assemelhe à essa realidade.
A grande questão que tenho dúvidas é como um mesmo artefato poderia ter revisões específicas em ambientes (integração, homologação, produção) distintos, sendo que a principal diferença entre essas duas ferramentas é que as revisões são geradas por artefato no Clear Case e no SVN as revisões são geradas por change set (conjunto de mudanças).
Mais uma vez, muito obrigado.
ResponderCaro Leandro!
Fico muito feliz pelos comentários positivos! Feedbacks como esse tornam o compartilhamento de conhecimento uma brincadeira ainda mais prazerosa!
Sobre sua pergunta, embora eu nunca tenha utilizado o Clear Case, acredito que o cenário apresentado não seja tão simples de ser replicado no SVN na íntegra.
Entretanto, imagino que o cenário abaixo pode ser interessante para vocês, parecido com o "Fluxo de atuação em projeto fechado com mesclagem de revisões":
1. O trunk sempre contém a versão atual de produção;
2. Tags são utilizadas para indicar versões de produção, sendo sempre criadas a partir do trunk (assim vocês têm um ponto rápido de acesso a todas as versões criadas);
3. Quaisquer desenvolvimentos são feitos em branches, os quais funcionam como seu label INTEGRACAO e são sempre criados a partir do trunk para assim permitir fácil reintegração utilizando a ferramenta "Reintegrate a Branch";
4. Ao concluir-se o desenvolvimento de um branch, você pode tanto renomeá-lo para algum padrão pré-definido quanto criar um novo branch a partir deste para indicar a tag HOMOLOGACAO (particularmente prefiro a opção de renomear. O SVN criará uma nova revisão e por consequência log desta mudança no próprio branch);
5. Ao concluir-se a homologação e definida a versão de produção, todos os branches homologados são reintegrados ao trunk;
6. Após a reintegração no trunk, uma tag com base na última revisão do trunk é criada para identificar a versão de produção recém criada.
Qualquer dúvida é só postar um novo comentário!
ResponderOi Intentor,
Parabéns pelo artigo, está bem explicado os conceitos.
Eu trabalhei em diversas empresas usando CVS ou SVN, algumas com integração contínua também, porém com diferentes ferramentas ( Continuum ou Jenkins), entretanto em quase todas quando se criava branch para cada solicitação nova , era um parto a parte do merge, principalmente se envolvesse classes grandes ou arquivos HTML ou XML.
Nesses casos foram adotadas algumas práticas, como merge no máximo semanal (nem que fosse com código comentado) e, se possível evitar de criar branch se fosse apenas uma pessoa para fazer a alteração. Toda versão em produção era gerada uma tag... e o ambiente de aceite em alguns casos era um branch e em outros era também controlado com tags.
Gostaria que comentasse se sua equipe em alguns casos adotou o que eu escrevi aqui e se elas tinham muitos problemas com merge.
Estamos avaliando também em fazer uam migração gradativa para Git com git flow.
ResponderCaro Fernando, obrigado pelos comentários!
Sobre seu problema com branches, enfrentar conflitos é muito comum, principalmente se não se mantém um fluxo contínuo de atualização dos branches.
Note que em todos os fluxos que menciono acima, sempre quando há um branch há a necessidade de atualizá-lo com as "novidades" de seu ponto de origem. Como geralmente os branches se originam do trunk, é imperativo que de tempos em tempos (variando aí de acordo com a quantidade de alterações no trunk) todos os branches ativos sejam atualizados com o último release do trunk. Dessa forma, você evita a maioria dos conflitos que poderiam surgir numa eventual reintegração do branch em uma versão muito modificada do trunk.
Seguindo a ideia acima, com certeza você terá bem menos problemas de conflitos ao reintegrar seu branch. Porém, não se esqueça de sempre utilizar a opção "Reintegrate a Branch" para tal, dado que aí há o uso de merge tracking e assim menos problemas com conflitos.
Sobre o Git, com certeza é uma estupenda opção. Seu sistema de merge é bem mais avançado que o SVN e a chance de conflitos por problemas simples de posicionamento de linhas de código em arquivos será bem menor.
Espero tê-lo ajudado!
ResponderÓtimo, ótimo, ótimo artigo. Parabéns!!
ResponderÓtimo artigo! Parabéns!
Com certeza irei usá-lo como base para divulgação e treinamento do SVN na minha empresa.
ResponderMuito obrigado, caro Matheus! Fico muito contente em saber da utilidade do artigo! Espero que seja de grande valia também em sua empresa!
ResponderParabéns pelo blog. Com a a sua experiencia quando se trabalha com mais de um projeto, qual a melhor forma de organizar o repositorio? Criar um repositorio para cada projeto, ou colocar tudo num só? Caso eu use um unico repositorio como ficaria a estrutura das pastas, tipo:
- repositorioEmpresa
- svn
- trunk
- projeto 1
- projeto 2
- branches
- projeto 1
- projeto 2
- tags
- projeto 1
- projeto 2
ResponderCaro Leonardo!
Obrigado pelo post e pela consideração!
Sobre a organização do seu repositório, em minha opinião e experiência o ideal é separar os projetos em repositórios distintos.
Dessa forma fica mais fácil gerenciá-lo, garantindo menos conflitos futuros.
ResponderGrande Intentor melhor post que achei sob o SVN.
Preciso de um help seu com as seguintes considerações.
Qual a ultima versão e onde baixar a mesma free?
Projetos aqui são em php e delphi.
Usei por muito tempo o harvest e estava precisando de um help pois estou organizando a area de desenvolvimento em uma pqna empresa agora.
Parabéns pela atitude e pela grande ajuda.
Att
HKC
ResponderMuito obrigado pelo elogio, caro HKC! Sempre fico muito contente em saber que o post tem sido útil para muitos desenvolvedores pela Internet e além! =D
Sobre os servidores SVN, em Windows você pode utilizar o Visual SVN Server (http://www.visualsvn.com/server/) ou o Subversion Edge da Collab Net (http://www.collab.net/downloads/subversion), o qual também possui versão para Linux. De modo geral, sempre recomendo criar os servidores em ambiente Linux por conta de compatibilidade e performance.
Qualquer coisa só postar um comentário!
ResponderEstou começando a ter que controlar versão no meu sistema, o negócio tá ficando muito intenso!
Aí resolvo procurar no google sobre o uso do SVN o primeiro resultado q aparece, "OEEEEEEEEE", Sr. Martins!
Parabéns man!
ResponderMr. Bolqui, muito obrigado! =D
Esse post já é lendário quando o assunto é SVN!
ResponderCaro Intentor, na sua opinião qual seria a forma correta de trabalhar com o SVN no seguinte sentido: o repositório do projeto (trunk) pode ou deve ser a versão de produção de um projeto? Exemplo:
Situação 1: working copy no pc de cada developer; repository num servidor central da empresa; no webserver fazer um update do repositorio para rodar a versão de produção
Situação 2: working copy no pc de cada developer; repositorio diretamente no webserver e rodar o diretorio trunk como versão de produção
Obs: muito bom o artigo e bastante didático.
ResponderCaro Tiago!
Em minha opinião a opção 1 é mais segura, com o repositório sendo separado do local aonde a aplicação de fato estará.
Inclusive em minha opinião não é interessante manter uma working copy no webserver para evitar arquivos adicionais de desenvolvimento. Sempre que for subir uma versão, prepare um pacote apenas com os arquivos necessários e o envie ao servidor.
Obrigado pela consideração e desculpe o atraso na resposta!
ResponderOlá Intentor,
Eu tenho algumas dúvidas sobre seu artigo.Poderia me ajudar?
- O que você chama de projeto fechado(Fluxo básico de atuação em projeto fechado) ?
- Tem algum livro que posso lê mais sobre esses fluxos de atividades?
Obrigado
ResponderCaro lintz!
Eis suas respostas:
1. Projeto fechado é um tipo de projeto no qual o escopo é bem definido e mudará muito pouco ao longo do desenvolvimento;
2. Recomendo o clássico "Controle de Versão com Subversion" (http://svnbook.red-bean.com/) que é gratuito e pode ser lido pela internet.
Obrigado pelo comentário!
ResponderOlá Intetor,
Obrigado por ajudar com as minhas dúvidas E queria fazer mais uma pergunta:
No, Fluxo básico de atuação em projeto fechado, a principal motivação do passo 6 (Criação de branch para o release recém gerado a partir da opção Branch/Tag) seria para corrigir erros que possam surgir na etiqueta gerada e gerar uma nova etiqueta a partir da branch e depois fazer o Reintegrate no trunk?
Obrigado
ResponderMr. lintz!
Sim, sua observação está correta.
Em posse dessa tag, você possui acesso a todos os releases já realizados, podendo gerar p. ex. branches para correções que posteriormente podem ser reintegrados ao trunk ou versões futuras.
Responder