Como utilizar o SVN com Unity e garantir rastreabilidade total de alterações em seu código fonte

1 Flares 1 Flares ×

svn-unity-como-utilizar

Se você é um desenvolvedor, seja em C#, VB.NET ou qualquer outra linguagem, e ainda não usa nenhum tipo de Sistema de Controle de Versão de Código Fonte eu recomendo que você faça isso já, pois são ferramentas poderosíssimas que irão aumentar muito a sua produtividade individual, e de sua equipe, bem como a rastreabilidade de alterações em seus códigos fontes.

Existem diversas opções de sistemas de controle de versão de códigos fontes como: SVN (Subversion), GIT, CVS, Mercurial e outros. Você pode ler sobre as características de cada um aqui.

Eu já trabalhei com diversos deles e prefiro o SVN. Existem diversas empresas que oferecem serviços de servidor SVN. Eu uso o Wush.net há mais de 8 anos, e desde a Game Jam que rolou entre os membros da Academia de Produção de Jogos, venho usando juntamente com o Wush, o Assembla, que também vem se mostrando estável e possui alguns planos gratuitos.

 

Como usar o SVN

Neste artigo vou explicar como você deve proceder para começar a usar o SVN, desde a criação da conta no servidor, até algumas operações básicas. No próximo, irei apresentar algumas operações avançadas que você pode realizar para extrair o máximo destes produtos.
O primeiro passo é criar uma conta em Servidor de SVN, e como exemplo, vou utilizar o Assembla, que oferece repositórios gratuitos:
Acesse a URL https://www.assembla.com/workspaces/repositories-features e entre na opção de repositórios gratuitos, conforme indicado nas figuras abaixo:

 

svn-e-unity instalar-svn

Você será redirecionado para criar uma conta:

criar-conta-svn

Você deve escolher entre SVN, GIT e P4, mas como este artigo fala sobre SVN sugiro que você escolha SVN.

Cadastre um nome para o repositório e prossiga.

repositorio-snv-jogos

Quando o repositório for criado você será redirecionado para seu DashBoard, de onde é possível manipular os arquivos, mas eu prefiro trabalhar com um cliente para Windows (TortoiseSVN) integrado ao Windows Explorer, que trataremos seguir.

criando-sistema-controle

Se você clicar na opção HOME tem a oportunidade de convidar outros usuários do assembla a fazerem parte de sua equipe, sendo que esta é uma das principais vantagens de se usar o SVN, pois com ele, é possível que 2 ou mais programadores trabalhem no mesmo arquivo ou então na mesma “function”.

codigo-fonte-unity6

Configuração de um cliente SVN em seu PC – TortoiseSVN 

Depois de criar a conta no servidor você precisará configurar um cliente SVN em seu PC. Entre no site https://tortoisesvn.net/downloads.html faça o download de um SVN Client de acordo com a versão do Windows instalada em seu PC (32 ou 64 bits).

configuracao-cliente-svn

Faça a instalação padrão e reinicie o computador (Não pule esta etapa).

Abra o Windows Explorer e clique com o botão direito em uma pasta (preferencialmente vazia) onde você deseja guardar o seu código fonte e verifique que novos ícones foram adicionados para o uso do SVN.

instalando-snv-pc8

O SVN irá criar uma estrutura inicial de pastas, e inicialmente eu sugiro que você não a altere. Para fazer o download dos arquivos iniciais do SVN acesse a opção SVN Checkout do menu e você verá uma tela semelhante à da figura abaixo:

Preencha com os dados de sua conta e pastas:

janela-instalacao

Ao clicar em OK o cliente irá solicitar usuário e senha (eu sugiro que você salve a senha em seus PC, pois em um projeto serão milhares de updates e commits):

autenticacao-svn

O SVN irá fazer o download das pastas, sendo que após concluir esta etapa você terá uma estrutura inicial conforme a figura abaixo:

estrutura-pc

Algumas informações sobre as pastas da figura acima:

  • Branches: é a pasta onde você deve armazenar diferentes versões de seus projetos.
  • Tags: é a pasta onde você deve armazenar versões congeladas de seus projetos. Exemplo: Versão do game que foi para a Google Play Store no dia 5/1. Esta versão deve ser congelada numa pasta Tags, para que você tenha uma cópia fiel dos fontes no dia que foram publicados. Nunca altere o conteúdo de arquivos da pasta TAG.
  • Trunk: Seria a pasta principal do projeto, mas não iremos utiliza-la neste momento, pois usaremos a pasta Branches.

Eu ainda irei detalhar melhor o conceito de branches, tags e trunk em um artigo futuro onde falarei de Integração contínua.

Trabalhando com Unity e SVN

Vou criar um projeto exemplo usando a Unity, que é uma das game engines mais utilizadas por desenvolvedores. Veja que a localização dos arquivos é a pasta Branches criada anteriormente.

unity-svn

Assim que o projeto for criado, o Unity irá criar a seguinte estrutura de pastas:

pastas-unity

Agora, com as pastas criadas é preciso adiciona-las ao SVN. É importante salientar que as pastas e arquivos foram criados pelo Unity e estão localizados fisicamente em seu computador. Assim sendo, o repositório de dados ainda não possui uma cópia deles. Para isso, clique com o botão direito na pasta de seu projeto, depois clique em TortoiseSVN e em Add:

configuracao-svn-unity

Você terá uma imagem semelhante à da figura abaixo (Vá com calma e NÃO Clique em OK antes de ler os próximos parágrafos):

instalando-snv-jogos

O Unity cria algumas pastas temporárias que não devem ser adicionadas ao SVN pois são alteradas frequentemente e causam muitos conflitos de arquivos (falaremos disso depois)

Desabilite a checkbox da pastas “Library” e “Temp”:

rastreabilidade-codigo-fonte

rastreabilidade-codigo-jogo17

Agora clique em OK. Você verá uma tela semelhante à da figura abaixo, mas seus arquivos ainda não estão na nuvem. Este processo simplesmente criou uma serie de arquivos e pastas temporárias que auxiliarão o TortoiseSVN a gerenciar seus arquivos. Por padrão eles são criados dentro de pastas com o nome .svn ou _svn.

 

codigo-fonte-svn

Commit

Depois de adicionados, a etapa final para enviar os arquivos para a nuvem é “comitar o codigo”. Para fazer um Commit, clique com o botão direito na pasta com o botão direito e selecione SVN Commit.

comitar-codigo-svn

Neste ponto o usuário recebe uma janela indicando quais são os arquivos que podem ser “comitados” e existe uma caixa de texto para adição de uma mensagem.

Eu recomendo que você SEMPRE escreva alguma mensagem útil nesta caixa, já que futuramente isso poderá ser utilizado para rastrear mudanças no código fonte e resolver problemas de conflitos.

comit-codigo-svn

A etapa final é clicar em OK:

estrutura-comit21

Adicionando novos arquivos

Numa situação real, novos arquivos sempre serão inseridos em seu projeto. Para exemplificar criei uma pasta Scripts contendo um script C# teste chamado GameManager. Veja no Unity:

arquivos-svn-unity22

E no Windows Explorer:

adicionar-arquivos-svn

SVN/ADD

Para adicionar os novos arquivos ao SVN, clique com o botão direito do mouse na pasta, depois em TortoiseSVN e Add.

SVN/Commit

Finalmente, para “comitar” os arquivos, clique com o botão direito do mouse na pasta, depois em SVN Commit.

Alterando arquivos

Uma função muito interessante do SVN é gerenciar alterações em arquivos. Para exemplificar eu Editei o script C# usando Visual Studio, e assim que o arquivo foi salvo, um ícone de Exclamação aparece ao lado esquerdo do arquivo. Isso indica que você possui código alterado e não “comitado”.

alterar-arquivo-svn

Caso você queira conferir o que foi alterado antes de fazer o Commit, você pode clicar com o botão direito no arquivo, e no menu do SVN selecione uma opção chamada Diff. O TortoiseSVN instala em seu PC uma poderosa ferramenta de comparação de arquivos chamada WinMERGE. Esta ferramenta irá buscar a última cópia de duas alterações e comparar com o arquivo local exibindo um ao lado do outro, conforme a figura abaixo:

winmerge-svn

Caso você tenha certeza que suas alterações estão corretas, basta fazer o commit e seu código irá para a nuvem, juntamente com todo o histórico de alterações feitas anteriormente.  

Considerações Finais

Neste artigo vocês puderam ver um pouco de como funciona o SVN.

Na próxima semana, vocês irão receber a segunda parte, mostrando recursos avançados, e também vou mostrar como eu uso esta ferramenta, juntamente com um BugTracker e um gerenciador de Tempo (Toggl – https://www.toggl.com) para criar uma estrutura de rastreabilidade de tempo, escopo de alterações, e custo em meus projetos.

Para finalizar, deixarei algo para discutirmos: eu venho usando SVN hospedado na nuvem há mais de 10 anos.

Fui questionado algumas vezes por clientes e parceiros comerciais em relação a confidenciabilidade e segurança dos dados na nuvem.

O que você pensa sobre isso ?
Você hospedaria seus projetos em algum destes servidores que eu citei?   

Se tiver duvidas não deixe de escrever nos comentários.

Ah! E se você quer se aprofundar no desenvolvimento de jogos e saber mais sobre a Academia PDJ, não deixe de participar de uma aula online com o Raphael Dias. Você pode se inscrever por meio deste link.

Até o próximo post! =)

  • Raphael Dias

    Parabéns por mais esse ótimo artigo, Rogério!

    Muita gente ainda não dá o devido valor a versionamento de código-fonte. Eu espero que esse artigo ajude o pessoal a dar os primeiros passos com SVN 🙂

    Abraço!

  • Matheus Amazonas

    No texto você citou que já usou outras ferramentas. Qual a vantagem do SVN sobre o Git?

    • Deiverson Silveira

      Eu uso tanto o Sourcetree + BitBucket quanto o SVN + Assembla e gostei tanto de um quanto o outro e eu escolho o sistema de versionamento que minha equipe vai utilizar me baseando no grau de experiência dos membros da equipe no sistema de versionamento sugerido. Eu considero muito válido o artigo. Dependendo do esforço para nivelar o conhecimento da equipe, é bem mais rápido usar o SVN do que o GIT, pelo menos é essa minha experiência. De nada vale eu determinar para equipe usar um sistema de versionamento que ela não conseguiu se adaptar e o processo se tornar improdutivo, então precisamos ser flexíveis e pensar sempre na produtividade. No momento que minha equipe começar a ficar improdutiva com esse sistema, eu altero para outro. Eu faço a escolha do sistema com base no conhecimento prévio da minha equipe.

      • Matheus Amazonas

        Entendi. Concordo com fazer escolhas de tecnologia baseado na equipe, as vezes o que achamos que é melhor pode terminar sendo um bloqueio na produção. Também considero o artigo extremamente válido, tem grandes chances de ajudar muita gente.

        Mas tirando a curva de aprendizado da equipe (digamos que temos a equipe perfeita que é acostumada com os 2 sistemas de versionamento), qual ferramenta você escolheria e por que?

        Pergunto isso porque já utilizei o SVN com Tortoise e comparado ao Git, achei muito mais lento e limitado, então fico curioso para conhecer as vantagens do sistema.

        • Deiverson Silveira

          Se eu tiver 2 equipes e as duas saberem mexer com os dois sistema de versionamento, a escolha do sistema se torna de pouca relevância para equipe. Quais as limitações que você considera que o SVN + Tortoise tem em relação ao Git? Para as necessidades dos projetos que participei, tanto uma quanto a outra funcionaram sem problemas ou prejuízos ao projeto. Mas já vi equipes que usavam o SVN e quando foram mudar para GIT, tiveram grandes transtornos no “push”, entre outras dores de cabeça inclusive usando o proprio SourceTree que crashava, mas isso não é regra, conforme comentei, eu usei os dois sem problemas por enquanto, quando minha equipe começar a “bater cabeça” com um sistema, se for gastar muito tempo para resolver ou for recorrente, vou sugerir mudança para outro.

          O meu critério de escolha se faz com base na opinião da equipe, até para compartilhar a responsabilidade da escolha. 🙂

          Normalmente nos projetos em que tem que decidir algumas coisas que podem afetar o desempenho da equipe, eu faço uma reunião para os membros exporem seus pontos de vista e terem noção da responsabilidade compartilhada pela decisão!

          • Rogerio Ranieri

            Eu também nao me preocupo se um é melhor que o outro. Até o momento o SVN tem todos os recursos que eu preciso, fora a interface amigável, entao nao cogito usar outra ferramenta até que seja necessário.

          • Matheus Amazonas

            Rogerio Ranieri Até uns 2 anos atrás, o Git era carente de softwares de interface gráfica, mas atualmente a situação é outra, com cliente do próprio GitHub, o SourceTree e o novo GitKraken, cada um com um “nível de profundidade” distinto.

            Sobre o SVN suprir todas as suas necessidades, acho extremamente válido, desde que você tenha consciência da escolha e conheça as novas alternativas. Se você quiser dar uma lida sobre o assunto:

            https://enrise.com/2012/01/stop-grumbling-on-svn-and-start-using-git/
            http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

            Obrigado pelo comentário.

          • Matheus Amazonas

            @Deiverson_Silveira:disqus , vou listar rapidamente alguns pontos do SVN que me fizeram ficar com o git:
            Centralização: o SVN é um sistema centralizado, o que me deixou refém do servidor. Eu sempre preciso estar conectado ao servidor para fazer operações no repositório, desde um simples commit a abrir um branch novo. Como o git é distribuído, não existe um “servidor master” (inclusive o nome dos remotes e dos branches são uma pura convenção), logo qualquer operação (tirando operações remotas, obviamente) podem ser feitas em computadores que não estão nem conectados à internet. Como trabalho numa empresa que me forneceu um laptop e permite que eu trabalhe remotamente (de casa, numa viagem, enfim) isso é um grande plus: eu posso dar commits, abrir branches e pular entre um e outro (piada intencional) como eu quiser. Depois do trabalho todo, posso simplesmente dar um pull/push e pronto, eu e minha equipe estamos sincronizados, mesmo se cada um passou 1 semana trabalhando sem nem conectar ao servidor remoto. Além disso, como o @disqus_Tn8Mr1lce7:disqus falou, eu não preciso configurar um servidor local na minha casa/escritório se eu quiser usar o Git.

            Outro problema que vi foi a velocidade em geral do SVN. Como a maioria das operações do Git (commit, branch, merge, checkout) são locais, elas são muito (mas muito mesmo) mais rápidas. No SVN, todas essas operações passam pela rede, o que torna tudo isso tudo lento demais. Abrir um branch no git é instantâneo e dar um checkout num commit de 4 meses atrás dura 3 segundos. É tão lindo que a primeira vez que você o faz, você não acredita que a operação realmente foi concluída.

            O recurso de stashes no Git é fantástico. Se você está trabalhando em algo e queria parar só meia hora pra corrigir um bug, não quer misturar o atual estado do seu trabalho e não quer abrir um branch só pra isso, joga tudo numa stash e traz ela de volta depois, em menos de 1 segundo. O uso de stashes com o de auto-merge do Git salva vidas em casos de conflito de código. Se você estava trabalhando com um arquivo e alguém acabou de dar um commit no mesmo arquivo, não tem problema: joga seu arquivo numa stash, dá pull e aplica ela de volta. Se você não modificou as mesmas linhas do arquivo, o git roda um auto-merge e você nem precisa abrir aquele MergeFile pra fazer um merge manual.

            Confiabilidade. O git por ser distribuído não corre o mesmo risco do SVN quanto a catástrofes. Se seu servidor SVN central corrompe o HD, já era, você perdeu seu histórico de commits, tags, branches e tudo mais. Você ainda tem o projeto salvo no seu computador, mas o repositório foi perdido. No git, cada cópia em cada computador é um repositório, então se isso acontecer, simplesmente configura um dos seus computadores como um novo remote e manda os outros desenvolvedores apontarem pra ele. Problema resolvido.

            Sem entrar em detalhes porque a resposta já está gigante, mas na minha opinião a gestão de branches do Git é mais fácil e suave que a do SVN.

            Bom, acho que os pontos mais gritantes pra mim foram esses. Valeu pela discussão.

        • Michel Felipe

          @matheusamazonas:disqus e @Deiverson_Silveira:disqus Eu utilizo o Git + Github/Bitbucket/Gitlab no meu dia-a-dia e gosto d+. Já usei SVN a anos luz atrás para versionamento de código de outras aplicações, não necessariamente com o Unity, mas não gosto muito dele. Mas concordo plenamente que o importante é versionar o código, não importa qual software de versionamento você utilize (Git, SVN, Mercurial, Bazaar…). È interessante utilizar aquilo que você e sua equipe mais se sente a vontade.

          No entanto, é sabido que a grande rede social de código fonte, o Github popularizou de forma gigante o uso do Git, que tem se solidificado cada vez + como “a bola da vez” para versionamento de código fonte. Na minha opinião, a maior vantagem do Git é que não preciso de um servidor externo para versionar o meu código. A sua filosofia é totalmente descentralizada…basta instalar o Git na sua máquina e voi-la! Você já pode criar seus commits, branches, tags e etc. O uso de um remote no git é basicamente para compartilhar o seu código com mais pessoas.

          Eu uso o git em linha de comando (ainda que ferramentas como o Sourcetree sejam excelentes). Isso por que na linha de comando, as possibilidades são gigantes e eu consigo entender kd coisa que faço no meu versionamento. Como uso o Unity no Mac, é um casamento perfeito. Git em linha de comando no Windows é bem tenso, uma vez que é preciso instalar o Git Bash que usa por debaixo dos panos uma “emulação” de um pequeno Kernel Linux.

          Aproveitando, gostaria de compartilhar uma dica no stackoverflow que me ajudou muito a configurar melhor o Unity para versionamento. Por padrão, Ele géra algumas pastas temporárias, de cache e etc, que são completamente desnecessárias para serem versionadas. Apesar da pergunta esta totalmente direcionada para o uso com Git, o mesmo pode ser feito para qualquer outro software de versionamento 🙂

          Link: http://stackoverflow.com/questions/18225126/how-to-use-git-for-unity-source-control

  • Gustavo Larsen

    Rogério, parabéns pelo artigo. Essa foi uma ótima dica. Achei essa possibilidade (posso arranjar inimigos agora…) muito melhor que Github ou BitBucket, pois este te permite fazer check-in e check-out nos arquivos direto nas pastas no Windows Explorer usando Tortoise (Ja havia utilizado o Tortoise antes, detre todas que já trabalhei foi a que mais gostei)

  • Felipe Costa Mauricio

    Parabéns e obrigado Rogério! Você acabou de me ajudar a resolver um problema que estava tendo a um tempo hehe Ótimo
    artigo.

  • Desculpe, pode parecer dúvidas bobas, mas preciso perguntar:
    1 Controle de versão é mais válido para os códigos ou para todo projeto? Equipe de arte também deve “comitar” os assets que cria?
    2 SVN é muito diferente de GIT? Terei que aprender novos comandos?

  • Ótimo artigo, já estou configurando meu ambiente de trabalho para meu projeto que farei seguindo a filosofia da academia. Só me preocupa a pasta assets torrar meu 1GB rapidinho, porque o plano é bem caro hehe.

  • Tio nélio Do Rincão

    nossa, chorei agora com esse artigo (brinks hehe)
    maravilhoso esse doc que voce fez

    Ja tentei usar o git e achei realmente complicado
    ja com esse tutorial, ficou bem mais simplificado
    graças a você estou conseguindo meus codes e function rsrs

    Att,
    Cornélio José Wiedemann ( TI & DBA )