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

Git - Object Store

O object store, descrito no último post, é a parte principal da implementação do repositório do Git. Ele contém os arquivos de dados original e todas as mensagens de log, informações do autor, datas e outras informações requeridas para gerar qualquer versão ou branch do projeto.

Dentro do objecto store há apenas quatro tipos de objetos, a saber:

                    

• Blobs (binary large object) que representa cada versão de um arquivo. Esse tipo de objeto pode conter qualquer dado. Um blob contém dados de um arquivo, mas não contém quaisquer metadados sobre ele nem mesmo o seu nome.
• Tree que representa o primeiro nível de um diretório. Ele registra identificadores para blob, nome de caminhos, e um pouco dos metadados de todos os arquivos e diretórios. Além disso, ele pode fazer referência a outros objetos tree, de forma recursiva, criando assim, um hierarquia completa de arquivos e subdiretórios.
• Um objeto commit mantém metadados para cada mudança introduzidas no repositório, incluindo o autor, quem fez a submissão, data de quando foi feita a submissão e mensagens de log. Cada commit aponta para um objeto da árvore que captura um snapshot completo, o estado do repositório no momento em que a submissão foi realizada.
• Um objeto tag atribui um nome arbitrário, porém legível,  a um objeto específico, geralmente um commit. Embora 9dfdsf3dfgfd435fds3333deaaaf5169 se refira a uma exata e bem definida committer, um nome de tag  mais familiar como Ver-1.0-Alpha poder fazer mais sentido.

 Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013

Git - Conceitos Básicos

Neste post, iremos descrever alguns dos conceitos comuns aos Sistemas de Controle de Versão(SCV), porém na visão do Git.

Um repositório Git nada mais é do que uma simples base de dados que contém todas as informações necessárias para manter e gerenciar o histórico e revisões de um projeto. No Git, como na maioria dos sistemas de controle de versão, um repositório mantém uma cópia completa de todo um projeto, em cada etapa do seu ciclo de vida. Entretanto, diferentemente de outros SCVs, repositório Git não só fornece uma cópia completa de trabalho de todos os arquivos no repositório, mas também uma cópia do repositório com a qual se está trabalhando.

Git mantém um conjunto de valores de configuração dentro de cada repositório (como nome do usuário do repositório e endereço de e-mail). Ao contrário dos dados de arquivo e outros metadados do repositório, as configurações não são propagadas a partir de um repositório para outro durante uma operação de clone ou duplicação.

Dentro de um repositório, o Git mantém duas estruturas de dados primárias, o object store e o index. Todos esses repositórios de dados são armazenados na raiz do seu diretório de trabalho, em um subdiretório oculto chamado .git.

O object store  é projetado para ser copiado, de maneira eficiente, durante uma operação de clone como parte do mecanismo que suporta um SCVs totalmente distribuídos. O index é uma informação transitória, é privado de um repositório, e pode ser criada ou modificada sob demanda quando necessário.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

ClearCase - Uma introdução

O ClearCase é uma solução de gerenciamento de configuração de software da família Rational da IBM. Uma das suas funcionalidades é o controle de versão, mas ela é composta também pelo gerenciamento de área de trabalho, suporte para desenvolvimento paralelo, segurança de IP efetiva e auditoria de compilação. Assim como grande parte das soluções das IBM, ela é uma solução paga. Entretanto é uma solução poderosa e flexível. Ela pode ser implantada em qualquer tamanho de equipe, desde um pequeno grupo até equipes grandes e geograficamente distribuídas. Ele pode ser implantado em servidores linux ou windows e exige um browser como um meio de acesso a aplicação.

• Controle de versão e gerenciamento de área de trabalho — Gerencia arquivos, diretórios e outros recursos de desenvolvimento durante o ciclo de vida.
• Gerenciamento de mudança colaborativo integrado — Gerencia problemas e mudanças na resolução.
• Desenvolvimento paralelo avançado — Inclui ramificação automática, fusão avançada e tecnologia diferenciada.
• Segurança de IP efetiva — Oferece assinaturas eletrônicas, autenticação de usuário para acesso seguro e controlado e trilhas de auditoria para ajudar a atender aos requisitos de conformidade e de controle.
• Auditoria de compilação confiável — Ajuda a simplificar o ciclo de edição-compilação-depuração e reproduz versões de software.

Git - Uma introdução

O Git é um sistema de controle de versão que teve seu primeiro protótipo lançado em abril de 2005. Idealizado por Linus Torvalds, criado do Linux, ele foi projetado para evitar falhas encontradas na maiorias dos sistemas de controle de versão.

Adaptado para melhor velocidade, desempenho, flexibilidade e facilidade de uso, ele trás como premissa as seguintes características:

• Atomicidade, que garante a unicidade de uma operação. Desta forma, ele evita, por exemplo, a perda de dados ou incompatibilidade de versão devido a operações parciais.
• Performance, que garante velocidade para lidar com milhões de arquivos. Conceitualmente, a maioria dos outros sistemas de controle de versão (Subversion, CVS, etc), veem seus dados como um conjunto de arquivos e as mudanças em cada um deles como uma versão contínua. A figura abaixo representa como os outros sistemas tratam arquivos e suas versões:

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide.

Diferentemente, o Git toma um snapshot (fotografia) de todo o conjunto de arquivos ao invés de armazenar apenas a diferença entre as versões de cada arquivo. Isso, contribui com a velocidade em determinadas operações como, por exemplo, reverter o conteúdo de seu arquivo de versões anteriores. Cada vez que uma versão é criada um snapshot é tirado. Isso não significa que o Git armazena várias réplicas de seus arquivos. Se ele descobre que não há nenhuma mudança em qualquer um dos conteúdos dos seus arquivos, apenas uma referência para o arquivo que aponta para o snapshot anterior é armazenado no novo snapshot.  A figura abaixo, ilustra esse processo:

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide.

• Segurança, que garante que ninguém possa adulterar o conteúdo dos seus arquivos. O Git utiliza um hash SHA-1 em suas operações. Isso significa que é impossível mudar o conteúdo de qualquer arquivo ou diretório, sem que seja possível tomar conhecimento dessas alterações.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

Conceitos, termos e abreviações

Quando lidamos com Sistemas de Controle de Versão, é necessário o conhecimento dos seus principais conceitos, termos e abreviações, os quais listamos abaixo:

artefato	Qualquer produto do ciclo de produção do projeto, podendo ser arquivos eletrônicos de código-fonte, arquivos eletrônicos de código compilado, a reunião desses arquivos, arquivos de documentação ou mesmo objetos físicos, como manuais impressos ou discos de instalação
repositório	Sistema de controle de versões de artefatos eletrônicos em que os itens de configuração eletrônicos são armazenados com a garantia de possibilidade de reversão a uma versão anterior do item
SCV	Sistema de Controle de Versões
baseline	Conjunto de artefatos aprovados e revisados que serão utilizados para atividades posteriores. É definida pela gerência de projeto como base para evoluções e desenvolvimento futuro
branch	Linha de desenvolvimento paralela à linha principal do repositório de código-fonte e documentação
tag	Rótulo de identificação de um conjunto de itens de configuração que representa um todo de interesse. Ordinariamente, as versões de release e as baselines são identificadas com tags para melhor referência
trunk/master	Linha principal de desenvolvimento existente no repositório
merge	Operação de integração de alterações de um determinado branch (ramo) ao trunk ou a outro branch
release	Versão do sistema validada para instalação, seja em produção, seja para homologação. Conjunto de itens enviado a um tribunal ou a um departamento para instalação, que não deve conter o código-fonte do sistema. Cada release pode encerrar novas funcionalidades ou mudanças decorrentes de evolução do sistema
commit	Submeter ao sistema de controle de versão alterações em um conjunto de arquivos
checkout	Copiar uma versão dos arquivos do sistema de controle de versão. Geralmente esta operação copia a última versão dos arquivos e, em alguns SCVs, o checkout inclui metadados necessários para o próximo commit.

Tipos de controle de versão - Parte 3

No post passado foi descrito o uso do sistema de controle de versão centralizado. Com essa abordagem é possível disponibilizar arquivos (e seus históricos) para uma equipe de trabalho. Esses arquivos ficam em um servidor que é acessado por todos os integrantes, que mantém em suas estações de trabalho uma cópia da última versão dos arquivos trabalhados.

Mas o que aconteceria se esse servidor ficasse fora do ar? Ou por algum motivo os arquivos fossem perdidos ?

Visando resolver essa questão, foram criados os sistemas de controle de versão distribuídos que funcionam como um híbrido entre o local e centralizado.  Nesse tipo de sistema de controle, os arquivos e seus históricos são mantidos tanto no servidor quanto nas máquinas clientes.

Um sistema de controle de versão distribuído é projetado para funcionar em ambos os sentidos. Ele armazena toda o histórico do arquivo/arquivos em cada máquina local e também sincroniza as alterações locais feitas pelo usuário para o servidor sempre que necessário. Assim, as alterações podem ser compartilhados com outras pessoas proporcionando um ambiente de trabalho colaborativo.

De modo geral, em um sistema distribuído de controle de versão é possível ter os benefícios dos dois mundos. Além disso, existem várias outras vantagens em termos de desempenho, facilidade de uso e administração.

As figuras a seguir mostram os três tipos de sistemas de controle de versão apresentados neste blog.

Sistema de Controle de Versão Centralizado

Sistema de Controle de Versão Centralizado

Sistema de Controle de Versão Distribuído

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

Tipos de controle de versão - Parte 2

No post passado foi descrito o sistema de controle de versão local. Com ele, é possível manter o histórico de versões de um ou mais arquivos na máquina do usuário. Todavia, esse modo de controle não é útil para o trabalho colaborativo entre as pessoas de um mesmo projeto.

Para resolver esse problema, os arquivos não são mais mantidos na máquina local do usuário e sim, em um local comum em que todos envolvidos possam ter acesso. Esse modelo de controle é conhecido como sistema de controle de versão centralizado.

Este modelo fornece não apenas acesso aos arquivos para as pessoas que deles necessitam, mas também oferece visibilidade sobre o que outras pessoas estão trabalhando. Como os arquivos são armazenados em um único servidor central, a partir do qual todos precisam compartilhar os arquivos, todas as alterações feitas neles são automaticamente compartilhadas com outras pessoas envolvidas no projeto.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

Tipos de controle de versão - Parte 1

Existem basicamente três tipos de sistemas de controle de versão.

• Sistema de controle de versão local
• Sistema de controle de versão centralizado
• Sistema de controle de versão distribuído

Hoje, iremos descrever o sistema de controle de versão local

Sistema de controle de versão local

O sistema de controle de versão local trabalha mantendo um conjunto de patchs, (diferenças entre diversos estágios de mudança de um arquivo). Desta forma, ele permite que o usuário volte para qualquer ponto (versão) do arquivo salvo anteriormente. Esses arquivos são armazenados no disco local da máquina do usuário, em um formato específico, dentro da chamada trilha de versão. A recuperação de um arquivo para um estado anterior, é feita através da junção de todos os patchs necessários a partir de um determinado ponto.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

No processo de desenvolvimento de software, principalmente em grandes equipes de trabalho, há uma preocupação em relação a execução de atividades que demandam trabalho compartilhado. Controlar as alterações feitas em um determinado projeto, principalmente em módulos ou códigos em que várias pessoas da equipe precisam trabalhar simultaneamente, torna-se ainda mais importante.

Visando evitar esses tipos de problemas, foram criados os Sistemas de Controle de Versão que têm como objetivo controlar as modificações feitas em determinados módulos/códigos, e ainda permitir a criação de versões que possam ser estendidas e disponibilizadas em projetos futuros.

Existem várias ferramentas disponíveis para esse propósito, algumas livres como o SVN (Subversion), CVS (Concurrent Version Systems), e Git; outras pagas como o ClearCase da IBM e o SourceSafe da Microsoft. Cada uma delas têm seus prós e contras e é preciso analisar esses pontos para escolher a ferramenta adequada para a equipe de trabalho.

Fonte:  Avaliação de uma ferramenta de controle de versões de software com o modelo de avaliação OPENBRR. Gestão da Produção, Operação e Sistemas - Ano 5, nº 3, Jul-Set/2010, p.149-165. 

Boas vindas

Sejam bem-vindos ao FRRW Gerência. Neste espaço apresentaremos os Sistemas de Controle de Versão.
Desfrute-os!