Apresentação sobre Sistemas de Controle de Versão

Abaixo seguem os slides da apresentação feita em 06/01/2014 acerca dos Sistemas de Controle de Versão.

Plano de Projeto de Software do SISCONI

Plano do projeto de Software do SISCONI (Sistema de Controle de Internação)

Diagrama de Gantt do SISCONI

Link para a imagem em maior resolução: Diagrama Gantt

Sistema de Controle de Código Fonte (Source Code Control System - SCCS)

O SCCS é um sistema de controle de revisão inicial, voltado para o código-fonte do programa e outros arquivos de texto.  Ele  é um sistema completo de comandos que permite que usuários específicos possam controlar e rastrear as alterações feitas em um arquivo SCCS. Arquivos SCCS permitem que várias versões do mesmo arquivo possam existir simultaneamente, o que pode ser útil no desenvolvimento de um projeto que requer muitas versões de arquivos grandes.

Os comandos SCCS suportam  um conjunto de caracteres multibyte (Multibyte Character Set  - MBCS), e formam um sistema completo para criar, editar, converter ou alterar os controles sobre os arquivos SCCS. Um arquivo SCCS é qualquer arquivo de texto controlado com comandos SCCS. Todos os arquivos SCCS tem o prefixo s., O que os diferencia de arquivos de texto normais.

Se você quiser olhar para a estrutura de um arquivo de SCCS, deve-se  usar o comando pg ou um comando semelhante ao exibir seu conteúdo. No entanto, não se deve usar um editor para alterar diretamente o arquivo, pois pode danificá-lo.

Para alterar o texto em um arquivo SCCS, use um comando SCCS (como o comando get) para obter uma versão do arquivo para edição, e depois usar qualquer editor para modificar o texto. Depois de alterar o arquivo, use o comando delta para salvar as alterações. Para armazenar as versões separadas de um arquivo, e controlar o acesso ao seu conteúdo, os arquivos SCCS tem uma estrutura única.

Um arquivo CCSC é composto de três partes, vistas a seguir.

Tabela Delta

Em vez de criar um arquivo separado para cada versão de um arquivo, o sistema de arquivos SCCS apenas armazena as alterações para cada versão de um arquivo. Essas mudanças são conhecidas como deltas. As alterações são controladas pela tabela de delta em cada arquivo SCCS.

Cada entrada na tabela delta contém informações sobre quem criou o delta, quando o criou, e por que eles criaram. Cada delta tem um SID específico (número de identificação) de até quatro dígitos. O primeiro dígito é o lançamento, o segundo dígito do nível, o terceiro dígito do ramo, e o quarto dígito da sequencia.

Cada vez que um novo delta é criado, a ele é dado o próximo maior número SID por padrão. Essa versão do arquivo é construída usando todos os deltas anteriores. Normalmente, um arquivo SCCS cresce em sequencia, de modo que cada delta é identificado apenas por seu lançamento e nível. No entanto, um arquivo pode ramificar e criar um novo subconjunto de deltas. O arquivo, em seguida, tem um tronco, com deltas identificados pela liberação e nível, e um ou mais ramos, que têm deltas contendo todas as quatro partes de uma SID. Em um ramo, os números de versão e nível são fixos, e novos deltas são identificados, alterando os números de sequencia.

Controle e acompanhamento de flags em arquivos SCCS

Após tabela delta em um arquivo SCCS, uma lista de sinalizadores começando com o @(arroba) definem as várias opções de acesso e monitoramento do arquivo SCCS.  Algumas das funções flags SCCS incluem:

• Designação usuários que podem editar os arquivos
• Bloquear certos lançamentos de um arquivo de editar
• Permitindo a edição conjunta do arquivo
• Mudanças de referência cruzada para um arquivo

Corpo de um arquivo SCCS

O corpo do arquivo SCCS contém o texto para todas as diferentes versões do arquivo. Consequentemente, o corpo do arquivo não parece ser um arquivo de texto padrão. Os caracteres de controle entre parênteses fazem parte do texto e especificam quais deltas criados ou excluídos dele. Quando o sistema SCCS constrói uma versão específica de um arquivo, os caracteres de controle indicam as partes do texto que correspondem a cada delta. As peças selecionadas do texto são então usadas para construir essa versão específica.

Fontes:

en.wikipedia.org/wiki/Source_Code_Control_System

publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.genprogc%2Fdoc%2Fgenprogc%2Fsccs.htm

Melhores práticas no uso dos Sistemas de Controle de Versão

Este post apresenta um conjunto de boas práticas que podem ser aplicadas tanto na utilização de Sistemas de Controle de Versão centralizados como também na utilização dos distribuídos.

Descreva o que foi realizado para cada commit

Escrever uma boa mensagem de commit leva pouco tempo. Em contra partida, evita a perda de tempo na busca de alterações relacionadas a determinado assunto.

Cada commit deve ter um único propósito

Pode acontecer que durante o desenvolvimento de uma tarefa, perceba-se outra questão que precisa de correção. Primeiro deve se commitar os arquivos referentes a essa questão recém descoberta e depois os arquivos relacionados à tarefa de origem. Com isto, caso seja necessário desfazer alguma funcionalidade, somente esta funcionalidade será desfeita e não as outras que foram indevidamente relacionadas.

Evite commits indiscriminados

Como regra geral, não execute commit sem fornecer os arquivos específicos para commitar. Se você não fornecer nenhum nome de arquivo, então o commit irá submeter cada arquivo alterado e pode acontecer de mudanças temporárias para fins de depuração acabem também sendo submetidas.

Compartilhe suas alterações frequentemente

Depois de ter realizado a tarefa por completo, você deve compartilhar essas alterações com os seus colegas o mais rápido possível.

Comunicação com seus colegas de trabalho

O sistema de controle de versão pode frequentemente mesclar as alterações que diferentes pessoas fazem simultaneamente. No entanto, quando duas pessoas editam uma mesma linha, surge um conflito que só pode ser resolvido manualmente. Para evitar isso, é aconselhável o diálogo com seus colegas de trabalho de modo que um possa commitar antes que o outro comece a modificar. 

Não submeter os arquivos gerados

O controle de versão é destinado aos arquivos que as pessoas editam. Logo, os arquivos gerados não devem estar nos commits. Um exemplo de arquivos gerados são os arquivos binários que resultam da compilação dos arquivos de classe.  

Entenda sua ferramenta de mesclagem

A parte menos agradável de trabalhar com controle de versão é a resolução de conflitos . Se você seguir as melhores práticas, raramente você vai ter que resolver conflitos.  Mas quando estes aparecerem, você deve certificar-se de que você compreende a sua ferramenta de mesclagem, evitando assim a introdução de mais erros.

Fonte: http://homes.cs.washington.edu/~mernst/advice/version-control.html

Visual Source Safe

Além das versões “livres” de sistemas de controle de versão, existem outras, as chamadas “comerciais”, disponíveis para desenvolvedores e empresas.  Muitas organizações preferem essas versões para poderem obter suporte e terem a quem culpar em caso de problema.

Dentre as diversas ferramentas comerciais, o Microsoft Visual SourceSafe (MVSS) é um sistema de controle de versão que permite a muitas organizações trabalharem em várias versões de um projeto ao mesmo tempo. Esta capacidade é particularmente útil em ambientes de desenvolvimento de software, onde ele é utilizado na manutenção de versões de códigos feitos por vários usuários ao mesmo tempo.

MVSS permite o compartilhamento rápido e eficiente de arquivos entre os projetos. A organização dos arquivos em projetos torna a coordenação da equipe intuitiva. Quando se adiciona um arquivo ao Visual SourceSafe, o arquivo é armazenado no banco de dados e disponibilizado para outros usuários. As alterações que forem feitas em um arquivo são salvas para que qualquer usuário possa recuperar uma versão antiga a qualquer momento. Os membros da equipe podem obter a versão mais recente de um arquivo, fazer alterações em cópias de arquivos locais, e salvar uma nova versão do banco de dados.

Usando as interfaces de automação Visual SourceSafe, é possível escrever extensões, conforme seja necessário, para o ambiente de trabalho. Extensões são normalmente fornecidas na forma de aplicações autônomas escritas para as interfaces de automação. É possível estender a funcionalidade do Visual SourceSafe escrevendo um add-in ou plug-in que seja compatível com o ambiente de desenvolvimento integrado (IDE) de software de terceiros.

Visual SourceSafe suporta o desenvolvimento paralelo e técnicas de desenvolvimento multiplataforma. Esse apoio permite que os membros de uma equipe possam completar diferentes partes e versões de um projeto ao mesmo tempo. O Visual SourceSafe inclui uma série de mecanismos para resolver conflitos de mesclagem. Operações de mesclagem de arquivos permitem o trabalho independente, sem a necessidade de sincronizar as alterações com aquelas feitas por outros indivíduos.

Visual SourceSafe fornece uma série de ferramentas poderosas de manutenção de banco de dados para manter seus bancos operando de forma eficiente e segura. Ele suporta arquivamento e restauração através de assistentes fáceis de usar, assim como vários utilitários de manutenção baseado em linha de comando.

De modo geral, o MVSS se comporta como a maioria dos sistemas de controle de versão. Porém, o seu uso é mais interessante quando se está desenvolvendo com as ferramentas da Microsoft como o Visual Studio.

Fonte: http://msdn.microsoft.com/

Software de Gerenciamento da Configuração

Software de Gerenciamento da Configuração (SCM - Software Configuration Management) tem como objetivo controlar e gerir mudanças em um projeto de software.

É sabido que a mudança é inerente e permanente em qualquer projeto de software. Sendo assim, a capacidade de monitorar e controlar tais mudanças de forma adequada forma a base de um bom projeto de software. O SCM  tenta preencher esta lacuna através da definição de um processo de controle de mudanças.

Desta forma, ele define processos para evitar alterações não autorizadas, procedimentos a seguir sempre que houver alterações, informações requeridas para o projeto, bem como o gerenciamento do fluxo de trabalho. A gestão da mudança é a parte mais complexa do controle de versão de um software.

Processo tradicional de um SCM é encarado como a melhor solução de ajuste às mudanças de manipulação em projetos de software. Processo tradicional SCM identifica os atributos funcionais e físicos de um software em vários pontos no tempo e realiza o controle sistemático das alterações nos atributos identificados, com a finalidade de manter a integridade do software e rastreabilidade ao longo do ciclo de vida de desenvolvimento de software.

Os processos de um SCM definem ainda a necessidade de traçar as mudanças e a habilidade de verificar se o software final entregue tem todas as melhorias que foram planejadas como parte da versão.

É interessante notar que um Sistema de Controle de Versão (SCV) é um caso especial de um SCM. O SCV apenas se preocupa com o gerenciamento de múltiplas versões de um sistema de software. Ao passo que o SCM tenta identificar e tratar elementos relevantes da configuração de um sistema, de modo que todos possíveis erros possam ser identificados, e suas possíveis soluções encontradas.

  

Fontes:

http://pt.slideshare.net/philipmjohnson/introduction-to-version-control-and-configuration-management 

http://www.pearsonhighered.com/assets/hip/us/hip_us_pearsonhighered/samplechapter/0321200195.pdf