Sistemas de controle de versão
Upcoming SlideShare
Loading in...5
×
 

Sistemas de controle de versão

on

  • 331 views

 

Statistics

Views

Total Views
331
Views on SlideShare
279
Embed Views
52

Actions

Likes
0
Downloads
6
Comments
0

2 Embeds 52

http://frrw-gerencia.blogspot.com.br 50
http://frrw-gerencia.blogspot.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Sistemas de controle de versão Sistemas de controle de versão Presentation Transcript

  • UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Gerência de Projetos 2013.2 Sistemas de Controle de Versão FELIPE OLIVEIRA CARVALHO RAMON BATISTA RAMOS RODRIGO LOSANO FONTES CALHEIROS WASHINGTON CAVALCANTE DA SILVA Professor: Dr. Rogério Patrício Chagas do Nascimento
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 2/67
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 3/67
  • O que é controle de versões? MOTIVAÇÃO Gerenciamento de múltiplas revisões  Documentos, projetos, software, etc.  Histórico de alterações sofridas.  Permitir consultar revisões anteriores.  Permitir comparações entre revisões.  Permitir trabalho cooperativo. 4/67
  • O que é controle de versões? MOTIVAÇÃO Vários nomes:  Revision control system (RCS).  Version control system (VCS).  Source Code Management.  Source Control. Controle de versão não gerenciamento de software. é exclusivo para 5/67
  • Por que controle de versões? MOTIVAÇÃO Software é algo caro de ser produzido.  Consome muito tempo.  Exige cooperação, organização, disciplina.  É importante armazenar tudo que é feito. 6/67
  • MOTIVAÇÃO Onde é utilizado? Sistemas de arquivos. Suítes de escritório. Ambientes colaborativos. Gerenciamento de software.  Importante para qualquer desenvolvedor ou empresa de desenvolvimento de software. 7/67
  • RECURSOS Registro de revisões Toda alteração realizada é registrada.  Quem, quando, o que e por quê?  Nada é perdido para sempre.  Descartar código ruim sem remorso. Rápido acesso a revisões anteriores.  Determinar introdução de defeitos.  Manutenção de código legado. 8/67
  • RECURSOS Auditoria Comparação entre versões do projeto, mostrando diferenças linha-a-linha. Apontar desenvolvedores responsáveis por cada trecho de código do projeto. Automação de testes de estabilidade. 9/67
  • RECURSOS Ramificações Múltiplas linhas de desenvolvimento dentro do mesmo projeto. Permite divergência desenvolvimento. e “reconvergência” do 10/67
  • RECURSOS Trabalho cooperativo Vários desenvolvedores trabalhando sobre o mesmo projeto. Mescla das alterações dos desenvolvedores ou ramificações. diversos 11/67
  • RECURSOS Segurança Autenticação criptográfica de histórico. Controle de acesso sobre o repositório. Cópias de segurança (backup). 12/67
  • MODELOS Modelos Centralizado (cliente-servidor).  Um repositório central de revisões.  Desenvolvedores obtém cópias de trabalho do repositório central. Distribuído  Cada desenvolvedor tem seu repositório.  Desenvolvedores copiam repositórios e alterações de outros desenvolvedores. 13/67
  • Centralizado (clienteservidor) MODELOS Vantagens:  Controle de acesso.  Cópia de segurança.  Controle de qualidade. Desvantagens:  Dependência do repositório central.  Ponto único de falha. 14/67
  • MODELOS Distribuído Vantagens:  Permite submissões particulares, off-line.  Melhor suporte a ramificação e mesclagem.  Independência da rede, mais rápido. Desvantagens:  Estimula o isolamento de desenvolvedores.  Questões de privacidade e segurança. 15/67
  • CONCEITOS Repositório Núcleo do controle de versões. Possui uma “linha do tempo” embutida.  Coletânea de revisões do projeto 16/67
  • CONCEITOS Repositório Revisão/Versão.  Estado em um determinado instante.  Imutável após criada. 17/67
  • CONCEITOS Cópia de trabalho Cópia do repositório em certa revisão.  Geralmente a mais recente.  Checkout (obtenção de uma cópia). 18/67
  • CONCEITOS Cópia de trabalho Onde ocorre o desenvolvimento.  O sistema reconhece as alterações feitas.  Algumas operações devem ser explícitas. Adição, remoção, cópia de arquivos. 19/67
  • Cópia de trabalho CONCEITOS Submissão (commit).  Alterações são registradas em uma nova revisão do repositório. 20/67
  • CONCEITOS Ramificações (branches) Linhas alternativas de desenvolvimento.  Explícitas.  Implícitas. 21/67
  • CONCEITOS Mesclagem (merge) Reintegração de ramificações.  Em grande parte é automatizado.  Conflitos podem ocorrer. O desenvolvedor pode precisar interagir. 22/67
  • CONCEITOS Rótulos (tags) Nomes atribuídos a revisões. 23/67
  • Sistemas de Controle de Versão PRODUTOS Centralizado Aberto Distribuído CVS, GIT, OpenCVS, Proprietário Subversion, Vesta Mercurial ClearCase, SourceSafe, BitKeeper, Bazaar, TeamWare Serena 24/67
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 25/67
  • GIT  HISTÓRICO  Até 2002 as mudanças no kernel do Linux eram repassadas a partir de patches e arquivos compactados.  A partir de 2002 passou-se a utilizar o Sistema de controle de versões proprietário chamado BitKeeper, fornecido gratuitamente para a comunidade do Linux.  Em 2005, a empresa dona do BitKeeper revogou a licença gratuita do software e então este deixou de ser uma solução viável para a comunidade Linux.  Linus Torvalds (criador do Linux) decidiu então criar um sistema de controle de versão próprio que fosse livre e gratuito, inspirado no BitKeeper. Nascia então o GIT. 26/67
  • GIT  CARACTERÍSTICAS:  Facilitar o desenvolvimento distribuído; • Permitir que se desenvolva em paralelo, de forma independente em repositórios locais, sem constante sincronização com um repositório central.  Escalável para suportar milhares de desenvolvedores; • Lidar corretamente com milhares de desenvolvedores em um projeto.  Execução rápida e eficiente;  Manter integridade e confiabilidade; • Utilização de hash SHA-1.  Garantia de auditoria; • Saber quem fez o que, mantendo um registro de todas as ações.  Imutabilidade; • Garantir que todos os objetos GIT são imutáveis, ou seja, não se alteram. 27/67
  • GIT  CARACTERÍSTICAS:  Transações atômicas; • Ou a transação é totalmente efetivada ou nada é feito.  Suporte e estímulo ao desenvolvimento em branches;  Repositórios completos; • Cada repositório local tem uma cópia de tudo que já foi feito.  Design interno limpo;  Ser livre. 28/67
  • GIT  CONCEITOS:  Repositórios. • Bases de dados contendo todas as informações necessárias para manter e gerenciar as revisões e o histórico de um projeto.  Tipos de Objetos GIT: • Blobs (Binary Large Objects). ◦ Cada versão de um arquivo é representado como um blob. • Trees. ◦ Equivale a um diretório, contendo uma lista de arquivos. Descreve o estado dessa árvore de diretório. • Commits. ◦ Faz a ligação entre as árvores junto com um histórico. • Tags. ◦ Adiciona um texto compreensível a um objeto (geralmente um commit). 29/67
  • GIT 30/67
  • GIT 31/67
  • GIT Áreas de trabalho do GIT: 32/67
  • GIT Comandos Básicos:  git config user.name “Nome“ • Configura o nome de usuário.  git config user.email “nome@email.com". • Configura o e-mail.  git init • Inicializa um repositório GIT vazio.  git status • Mostra o status da árvore de trabalho atual.  git add <arquivo> • Adiciona o arquivo ao Staging do GIT.  git rm <arquivo> • Remove um arquivo não versionado do Staging do GIT. 33/67
  • GIT Comandos Básicos:  git reset HEAD <arquivo> • Remove arquivos versionados e modificados do Staging.  git commit –m <mensagem> • Arquivos que foram adicionados ao Staging são “commitados”, ou seja, enviados ao repositório local do GIT.  git reset --hard <hash> • Volta a área de trabalho para o commit com o hash <hash>.  git branch • Lista, cria ou deleta branches.  git log • Mostra os logs dos commits. 34/67
  • GIT Comandos Básicos:  git clone • Clona (copia) um repositório em um novo diretório.  git push • Envia o commit local para o repositório remoto.  git pull • Atualiza a área de trabalho local a partir de um repositório remoto.  git fetch • Faz download dos objetos remotos.  git tag • Cria, lista, deleta ou verifica tags. 35/67
  • GIT 36/67
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 37/67
  • Subversion 38/67
  • Subversion Fundado pela Apache. Licença de Software livre. Lançada a versão 1.0 em 2004. Substituto moderno do CVS. 39/67
  • Subversion Sistema de controle de versão centralizado. Um dos sistemas de controle mais utilizados. Facilidade no uso. 40/67
  • Subversion 41/67
  • Subversion 42/67
  • Subversion X Git Subversion Git Repositório centralizado Repositório distribuído Baixo desempenho Alto desempenho Cada cliente possui uma cópia do projeto Cada cliente possui uma cópia completa do controle de versão do projeto podendo assim distribuir o controle de versão para outros clientes. Sincronismo com o repositório dependente do servidor. Sincronismo com o repositório independente do servidor. 43/67
  • ClearCase 44/67
  • ClearCase Solução de gerenciamento de configuração da família Rational da IBM.  Controle de versão.  Gerenciamento de área de trabalho.  Suporte para desenvolvimento paralelo.  Segurança de IP efetiva.  Auditoria de compilação. 45/67
  • ClearCase Solução paga. Grande poder de gerenciamento. Solução poderosa e flexível.  Pequenas equipes.  Grandes equipes geograficamente distribuídas. 46/67
  • Mercurial 47/67
  • Mercurial Semelhante ao Git, o Mercurial se enquadra em um controle de versão distribuído. É semelhante também por ser um software livre. Também é compatível com diversas plataformas. 48/67
  • Mercurial Usado em grandes projetos como:  Google Code.  Python.  Java (OpenJDK).  Mozilla.  Netbeans (IDE).  OpenSolaris. 49/67
  • Mercurial Existem mais semelhanças entre o Mercurial e o Git que diferenças. A escolha por algum dos dois em um projeto chega a ser subjetiva. 50/67
  • Outros Sistemas de controle de versão 51/67
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 52/67
  • Estudo de Caso 53/67
  • Estudo de Caso 54/67
  • Estudo de Caso 55/67
  • Estudo de Caso 56/67
  • Estudo de Caso 57/67
  • Estudo de Caso A natureza descentralizada do GIT facilita a gestão de projetos que têm várias equipes de desenvolvimento. Lida muito bem com colaboração de vários grupos de trabalhos no mesmo projeto. Essa característica permite o desenvolvimento de vários fluxos de trabalho. 58/67
  • Estudo de Caso O fluxo de desenvolvimento é iniciado com o cadastro de uma demanda no sistema de controle de demandas adotado, o JIRA. No JIRA, a palavra “issue” significa “demanda”. 59/67
  • Estudo de Caso Nunca, jamais submeta um commit no branch master. Submeter commits no branch master impede que o usuário trabalhe em mais de uma issue ao mesmo tempo. O branch master, no repositório central, é configurado para receber commits somente dos gestores do projeto ou revisores de commits. 60/67
  • Estudo de Caso O colaborador terá de baixar o projeto para um repositório local (git clone). Supondo que uma issue de nome “pje 123” seja aberta. O responsável pelo desenvolvimento deve criar um branch de nome “pje 123” e submeter os commits nele. 61/67
  • Estudo de Caso Uma vez concluído, o desenvolvedor irá submeter o código ao servidor de origem (git push). Os commits do PJe devem possuir comentários. 62/67
  • Estudo de Caso Após a submissão do código, o desenvolvedor terá de abrir uma solicitação de merge de código através do GitLab (interface de gestão do GIT) Antes de ser integrada ao master do projeto, esta solicitação será analisada pelos revisores de commit. 63/67
  • Estudo de Caso Antes de iniciar o desenvolvimento da próxima issue, é aconselhável ter a última versão do master para evitar conflitos durante a reintegração do código (git pull). 64/67
  • Agenda  Conceitos gerais;  GIT;  Comparação do GIT com outros SCV;  Estudo de Caso;  Conclusão. 65/67
  • Conclusão Sistemas de controle de versão são essenciais no desenvolvimento de projetos de software. São essenciais para a gerência de software. 66/67
  • Referências LOELIGER, Jon; MCCULLOUGH, Matthew. Version Control with Git. O'Reilly Media, Inc., 2009. Comandos Básicos do GIT, disponível em <http://blog.gustavohenrique.net/2011/03/coman dos-basicos-do-git/>, acessado em janeiro de 2014. 67/67