Unidade I-Gerenciamento de Versões

Prévia do material em texto

Gerenciamento de versões 
 
Material Teórico 
1 / 3 
Objetivo da Unidade: 
• Fundamentar a gerência de configuração de software. 
Introdução 
Primeiramente, vamos definir o Gerenciamento de Configuração. Ele 
nada mais é que o processo de identificação e definição dos itens de 
configuração em um sistema, controlando a versão e a alteração desses 
itens ao longo do ciclo de vida do sistema, registrando e relatando 
o status dos itens de configuração e solicitações de alteração, e 
verificando a completude e correção dos itens de configuração. 
O gerenciamento de configuração é praticado de uma forma ou de outra 
como parte de qualquer projeto de engenharia de software, no qual 
vários indivíduos ou organizações devem coordenar suas atividades. 
Embora as disciplinas básicas de Gerenciamento de Configuração sejam 
comuns tanto para projetos de engenharia de hardware quanto 
de software, há algumas diferenças de ênfase devido à natureza dos 
produtos de software. 
O gerenciamento de configuração de software é um sistema de 
gerenciamento da evolução dos produtos de software, tanto durante os 
estágios iniciais de desenvolvimento quanto durante todas as etapas de 
manutenção. 
Um produto de software abrange o conjunto completo de programas de 
computador, procedimentos e documentação e dados associados 
designados para entrega a um usuário. 
 
Figura 1 
 
Onde se encontra a gerência de configuração no desenvolvimento 
de software. Trata-se de um conjunto de atividades de apoio que 
permite a absorção ordenada das mudanças inerentes ao 
desenvolvimento de software, mantendo a integridade e a 
estabilidade durante a evolução do projeto 
Todavia, é importante sabermos que gerenciamento de configuração, 
não é somente para desenvolvimento de software. Muitas outras 
indústrias e negócios se beneficiam com ele. Isso se deve ao 
gerenciamento de configuração ser um conjunto de práticas 
orquestradas para rastrear itens operacionais e seus atributos. É uma 
técnica de operações fundamental que captura informações valiosas 
para processos, como gerenciamento de incidentes, gerenciamento de 
problemas, gerenciamento de mudanças, manutenção, segurança e 
gerenciamento de riscos. 
Veja bem, aqui nessas duas linhas finais do parágrafo anterior, você 
percebe que isso serve para tudo, além de que, são itens que estão 
constantemente integrados aos frameworks de construção de software, 
afinal, nos dias presentes, não se faz software sem gestão de riscos, 
gestão de mudanças, incidentes, sustentação de software e outros. 
Quer exemplos?! 
Companhias aéreas: rastreia as peças e componentes de sua aeronave 
para fins de manutenção e segurança. Se uma determinada peça for 
recolhida por motivos de segurança, a companhia aérea pode 
determinar imediatamente onde a peça está instalada. 
Bancos: mantém o controle de seu software, componentes, bancos de 
dados, infraestrutura e instalações em um banco de dados de 
gerenciamento de configuração para fins como suporte de serviço, 
gerenciamento de incidentes e gerenciamento de riscos de TI. 
Telecomunicações: mantém um banco de dados de gerenciamento de 
configuração que inclui relacionamentos entre componentes. Isso é 
usado para determinar automaticamente o impacto das falhas. Por 
exemplo, se um roteador cair, a empresa terá acesso imediato a uma 
lista de serviços e clientes afetados. A empresa a partir disso, aqui no 
Brasil, deveria ligar para os clientes para avisar que seu serviço está 
inativo antes que eles percebam, mas... 
Espaço: mantém um relato detalhado da configuração básica atual 
de software, componentes, peças e materiais. A mudança é 
cuidadosamente controlada e gerenciada para os objetivos da missão 
usando as informações de configuração. Quando uma missão é iniciada, 
o gerenciamento de configuração inclui detalhes exatos de como ela é 
configurada. Essas informações podem ser usadas para encontrar 
soluções alternativas. 
Gerenciamento de configurações se associa a muitas áreas e se 
influenciam mutuamente a: itens de configuração, gestão de incidentes, 
gerenciamento de problemas, serviço de suporte e gestão de serviços. 
Fundamentos da Gerência de Configuração 
de Software 
A aplicação de gerenciamento de configuração vai além das 
informações de design para incluir todos os requisitos da empresa, além 
de seus produtos, serviços e entregas de solução em todas as fases do 
ciclo de vida do negócio. 
O gerenciamento de configuração de software é a organização dos 
componentes de um sistema de software para que se encaixem em uma 
ordem de funcionamento, nunca fora de sincronia entre si. Para 
Pressman (2011), a gerência de configuração de software é um conjunto 
de atividades destinadas a controlar a mudança, identificando os 
produtos de trabalho que são passíveis de mudança, estabelecendo 
relações entre eles, definindo mecanismos para gerenciar diferentes 
versões desses produtos de trabalho, controlando as mudanças 
impostas e auditando e relatando as mudanças feitas. 
Portanto, é a arte de identificar, organizar e controlar modificações 
no software que está sendo construído por uma equipe de 
desenvolvimento, além disso, ela maximiza a produtividade minimiza 
erros. 
É necessário estabelecer e manter a integridade dos produtos do projeto 
de software ao longo do ciclo de vida do software. As atividades 
necessárias para realizar isso incluem identificar itens e unidades de 
configuração, controlar sistematicamente as mudanças e manter a 
integridade e a rastreabilidade da configuração ao longo do ciclo de vida 
do software. Então, ao identificarmos os itens que precisam ser 
configurados, devemos lembrar que todos os artefatos do projeto são 
candidatos a: documentos, modelos gráficos, protótipos, código e 
qualquer entrega interna ou externa que pode sofrer alteração. 
Na terminologia de software, um item de configuração pode ser uma 
proposta, estimativa ou licitação, plano de projeto, plano de 
gerenciamento de risco, plano de garantia de qualidade, o próprio plano 
de gerenciamento de configuração em si, plano de teste, especificação 
de requisitos de sistema, documento de design de sistema, avaliação de 
métrica, código, resultado de teste, ferramentas como editores, 
compiladores e CASE e assim por diante. 
Existem objetos básicos e objetos agregados a serem configurados. O 
número de relacionamentos entre eles reflete a complexidade da tarefa 
de configuração. 
Mas, provavelmente, isso ainda não gerou um bom entendimento... 
Então vamos usar um exemplo baseado num filme famoso onde 
trabalharam os artistas Tom Hanks, Bill Paxton, Gary Sinise e Ed 
Harris, chamado de Apolo 13. O filme trata dos problemas que a nave 
Apolo 13 enfrentou durante sua missão até a lua, tendo que retornar à 
Terra de forma bastante contingencial. Quem assistiu ao filme deve ter 
percebido que, no centro de controle da missão na NASA, o diretor da 
missão (Ed Harris) conversa constantemente com os técnicos da missão 
e eles corriam para ver documentação, esquemas e outros livros de 
esquemas e outras coisas para tentar descobrir o que fazer para mudar 
os circuitos elétricos, hidráulicos e de circulação de oxigênio para tentar 
trazer os astronautas de volta para nosso planeta, abortando a missão 
lunar. Aquelas idas e vindas em livros, simuladores em tamanho real, 
discussão sobre esquemas, jumpers e outras coisas nada mais era que 
uma consulta aos componentes e circuitos da nave. Isso só era possível 
porque havia uma configuração e ela permitiu, por meio do 
gerenciamento da configuração, entender o que poderia ser feito para 
salvar os astronautas, o que realmente aconteceu. Sem gerência de 
configuração, os astronautas infelizmente teriam morrido! 
Bom, parece que esse é um bom motivo para você ter e manter a 
gerência de configuração de qualquer projeto, principalmente software, 
que é amplamente complexo e necessita de constante lapidação. 
O processo de gerenciamento de configuração é considerado por muitosfuncionários de TI como a melhor solução para lidar com mudanças em 
projetos de software, porque ele identifica os atributos funcionais e 
físicos do software em pontos críticos no tempo e implementa 
procedimentos para controlar mudanças em um atributo identificado 
com o objetivo de manter a integridade e rastreabilidade do software ao 
longo do ciclo de vida do software. 
Os quatro procedimentos normalmente encontrados em um sistema de 
gerenciamento de configuração de software confiável são: 
• bullet 
Identificação de configuração; 
• bullet 
Controle de configuração; 
• bullet 
Documentação de status de configuração; 
• bullet 
Auditorias de configuração 
Esses procedimentos têm nomes diferentes em vários padrões de 
gerenciamento de configuração, mas as definições são basicamente as 
mesmas em todos os padrões. 
Identificação da configuração: é o procedimento pelo qual os atributos 
são identificados que define todas as propriedades de um item de 
configuração. Um item de configuração denominado objeto é um 
produto (hardware e / ou software) que oferece suporte ao uso por um 
usuário final. 
Esses atributos são registrados em documentos de configuração ou 
tabelas de banco de dados e são baseados na linha de base. Uma linha de 
base é um objeto de configuração aprovado, como um plano de projeto, 
que foi autorizado para implementação. 
Normalmente, uma linha de base é um produto de trabalho único ou 
conjunto de produtos de trabalho que podem ser usados como uma base 
lógica para comparação. 
Uma linha de base também pode ser estabelecida como base para 
atividades futuras. A configuração de um projeto geralmente inclui uma 
ou mais linhas de base, o status da configuração e quaisquer dados de 
medição coletados. 
Uma configuração atual se refere ao status atual, auditoria atual, 
medições atuais e a revisão mais recente de todos os objetos de 
configuração. 
Às vezes, uma linha de base pode se referir a todos os objetos associados 
a um projeto específico. Isso pode incluir todas as revisões feitas em 
todos os objetos, ou apenas a última revisão de objetos em um projeto, 
dependendo do contexto em que o termo é usado. 
A definição da linha de base de um atributo de projeto força os 
processos formais de controle de mudança de configuração a serem 
executados no caso de esses atributos serem alterados. Uma linha de 
base também pode ser especializada como um tipo específico de linha 
de base, como: 
• Linha de base funcional: especificações iniciais, 
especificações de contrato, regulamentos, especificações 
de design etc.; 
• Linha de base alocada: estado dos produtos de trabalho 
uma vez que os requisitos foram aprovados; 
• Linha de base de desenvolvimento: status dos produtos 
de trabalho durante o desenvolvimento; 
• Linha de base do produto: contém o conteúdo do projeto 
a ser lançado; 
• Outros, com base em práticas de negócios individuais. 
Controle de mudança de configuração: é um conjunto de processos e 
estágios de aprovação necessários para alterar os atributos de um 
objeto de configuração e para refazê-los. 
Contabilidade do status da configuração: é a capacidade de registrar e 
relatar as linhas de base da configuração associadas a cada objeto de 
configuração a qualquer momento. 
Auditorias de configuração: são divididas em auditorias de 
configuração física e funcional. Uma auditoria ocorre no momento da 
entrega de um projeto ou quando uma mudança é feita. Uma auditoria 
de configuração funcional tem como objetivo garantir que os atributos 
funcionais e de desempenho de um objeto de configuração sejam 
alcançados. Uma auditoria de configuração física tenta garantir que um 
objeto de configuração seja instalado com base nos requisitos de suas 
especificações de design. 
WILLIAMS, 2014, p. 11-12 
Identificação da configuração: é o procedimento pelo qual os atributos são 
identificados que define todas as propriedades de um item de 
configuração. Um item de configuração denominado objeto é um 
produto (hardware e / ou software) que oferece suporte ao uso por um 
usuário final. 
Esses atributos são registrados em documentos de configuração ou 
tabelas de banco de dados e são baseados na linha de base. Uma linha de 
base é um objeto de configuração aprovado, como um plano de projeto, 
que foi autorizado para implementação. 
Normalmente, uma linha de base é um produto de trabalho único ou 
conjunto de produtos de trabalho que podem ser usados como uma base 
lógica para comparação. 
Uma linha de base também pode ser estabelecida como base para 
atividades futuras. A configuração de um projeto geralmente inclui uma 
ou mais linhas de base, o status da configuração e quaisquer dados de 
medição coletados. 
Uma configuração atual se refere ao status atual, auditoria atual, 
medições atuais e a revisão mais recente de todos os objetos de 
configuração. 
Às vezes, uma linha de base pode se referir a todos os objetos associados 
a um projeto específico. Isso pode incluir todas as revisões feitas em 
todos os objetos, ou apenas a última revisão de objetos em um projeto, 
dependendo do contexto em que o termo é usado. 
A definição da linha de base de um atributo de projeto força os 
processos formais de controle de mudança de configuração a serem 
executados no caso de esses atributos serem alterados. Uma linha de 
base também pode ser especializada como um tipo específico de linha 
de base, como: 
• Linha de base funcional: especificações iniciais, especificações de contrato, 
regulamentos, especificações de design etc.; 
• Linha de base alocada: estado dos produtos de trabalho uma vez que os requisitos 
foram aprovados; 
• Linha de base de desenvolvimento: status dos produtos de trabalho durante o 
desenvolvimento; 
• Linha de base do produto: contém o conteúdo do projeto a ser lançado; 
• Outros, com base em práticas de negócios individuais. 
Controle de mudança de configuração: é um conjunto de processos e 
estágios de aprovação necessários para alterar os atributos de um 
objeto de configuração e para refazê-los. 
Contabilidade do status da configuração: é a capacidade de registrar e 
relatar as linhas de base da configuração associadas a cada objeto de 
configuração a qualquer momento. 
Auditorias de configuração: são divididas em auditorias de configuração 
física e funcional. Uma auditoria ocorre no momento da entrega de um 
projeto ou quando uma mudança é feita. Uma auditoria de configuração 
funcional tem como objetivo garantir que os atributos funcionais e de 
desempenho de um objeto de configuração sejam alcançados. Uma 
auditoria de configuração física tenta garantir que um objeto de 
configuração seja instalado com base nos requisitos de suas 
especificações de design. 
WILLIAMS, 2014, p. 11-12 
Segundo Pressman (2011), no contexto de engenharia de software, 
definimos uma linha-base como um marco de referência no 
desenvolvimento de um software, que é caracterizado pela entrega de 
um ou mais itens de configuração, obtida por meio de uma revisão 
técnica formal. 
Se ignorarmos o gerenciamento da configuração ou fizermos 
incorretamente, uma organização paga penalidades severas na forma 
de gastos de recursos de intervenção. Essas despesas são o tempo, 
dinheiro e recursos, gastos não planejados, gastos para compensar os 
problemas de qualidade e cronograma entre tantos outros. 
Quando os problemas de qualidade e cronograma dominam a energia 
que uma organização gasta diariamente, a ação corretiva torna-se a 
“forma de trabalhar” padrão. E, sinceramente, são anos vendo isso 
acontecer em empresas, de tal forma que mudar esse ambiente requer 
uma compreensão de como os processos atuais se relacionam com as 
melhores práticas e a mudança de cultura necessária para fazer a 
transição. 
Alguns dos principais benefícios do gerenciamento da configuração 
incluem: 
• bullet 
Maior eficiência com um processo de configuração 
definido que fornece controle e melhora a visibilidade 
comrastreamento; 
• bullet 
Redução de custos por ter conhecimento detalhado de 
todos os elementos da configuração, o que permite evitar 
duplicações desnecessárias; 
• bullet 
Seu negócio terá maior agilidade e agilidade na resolução 
de problemas, proporcionando uma melhor qualidade de 
serviço aos seus clientes; 
• bullet 
Maior confiabilidade do sistema e do processo por meio 
da detecção e correção mais rápidas de configurações 
inadequadas que podem afetar negativamente o 
desempenho; 
• bullet 
A capacidade de definir e aplicar políticas e 
procedimentos formais que podem ajudar no 
monitoramento e auditoria do status do processo; 
• bullet 
Gerenciamento de mudanças mais eficiente que reduz o 
risco de incompatibilidade ou problemas com o produto; 
• bullet 
Restauração mais rápida do seu serviço se ocorrer uma 
falha no processo. Se você souber o estado necessário da 
configuração, a recuperação da configuração de trabalho 
será muito mais rápida e fácil. 
Todas as práticas do processo de gerenciamento de configuração – CM 
são necessárias para que haja processos eficazes de mudança, liberação 
e gerenciamento de qualidade, mas a identificação e o controle de 
mudanças de configuração são essenciais; se você não souber o que está 
planejando mudar ou testando, será impossível garantir que as 
solicitações de mudança sejam implementadas adequadamente ou que 
o que foi lançado era de qualidade adequada. A rastreabilidade, por 
definição, requer que os artefatos vinculados pelos relacionamentos de 
rastreio sejam claramente identificados e seu estado devidamente 
controlado. 
Controle de Versão 
O controle de versão, também conhecido como controle de revisão ou 
controle de origem, é o gerenciamento de alterações em documentos, 
programas de computador, grandes sites da web e outras coleções de 
informações. Cada revisão está associada a um carimbo de data e hora e 
à pessoa que está fazendo a alteração. 
Uma única pessoa raramente é responsável pela codificação de projetos 
de software de médio ou grande porte. Hoje, as equipes, tanto locais 
quanto geograficamente dispersas, fazem a maior parte do 
desenvolvimento. 
No entanto, em um passado não muito distante, os programadores 
eram fisicamente centralizados e quantas vezes gritavam uns com os 
outros pela sala de desenvolvimento ou então pairavam sobre o colega 
perturbando-o com a versão mais recente, esperando sua chance de 
adicionar arquivos, assim que ele saísse. E, embora esteja claro que 
modificações em documentos para desenvolvimento 
de software baseado em equipe requerem mais estrutura do que um 
único arquivo, implantar um sistema que protege o documento mestre 
enquanto fornece produtividade ideal continua a ser um desafio. 
Um forte sistema de controle de versão de código pode fornecer clareza 
ao revisar o software, esclarecendo o que foi alterado por quem e 
quando. Geralmente, essas soluções funcionam para fornecer um 
formato lógico para rastrear o progresso do desenvolvimento, 
mantendo as alterações detalhadas, e têm a capacidade de reverter para 
versões anteriores. 
O controle de versão permite que você gerencie as alterações nos 
arquivos ao longo do tempo. Você pode usar o controle de versão para 
código de versão, arquivos binários e ativos digitais. Ele é um 
componente do gerenciamento de configuração de software. Além disso, 
também é a prática DevOps de garantir que cada tecnologia em um 
determinado produto esteja usando uma versão escolhida e confiável da 
tecnologia que seja compatível com cada componente dentro do 
ecossistema do produto. 
Hoje, uma equipe de desenvolvedores é responsável pela maioria das 
compilações de software. A importância do controle de versão do código 
é que ele fornece um veículo de comunicação constante para a equipe, 
estejam eles na mesma sala ou ao redor do mundo. 
O controle de versão fornece um método lógico que preserva as 
contribuições individuais dos membros da equipe sem sobrescrever o 
trabalho de outro desenvolvedor e, a seguir, mescla e reconcilia as 
alterações e atualizações. Também é à prova de falhas para localizar e 
dar suporte a problemas que estão em conflito. O registro histórico 
produzido pode ser usado para rastrear as origens do problema ou 
arquivar versões para uso posterior, sendo que isso ajuda muito a 
interação entre o time de testes e o de desenvolvimento. Mesmo se um 
desenvolvedor estiver trabalhando sozinho, o sistema fornece a 
manutenção de registros defensivos do progresso e do processo. A 
preservação de informações valiosas e trabalhos anteriores é possível 
somente por meio do controle de versão. 
Claro que fazemos isso por meio de softwares, como GIT ou BITBUCKET, 
sim, existem outros mais sofisticados e caros, mas, como exemplo, 
esses dois servem muito bem para ilustrar que, os sistemas de controle 
de versão de software oferecem suporte a um plano geral de 
desenvolvimento ágil, fornecendo um mecanismo de prova de como o 
código foi construído, quando foi alterado e por quem. 
Quando esses sistemas são bem gerenciados, eles possuem convenções 
de numeração de versão que são facilmente identificáveis por toda a 
equipe. 
O sistema gerencia os diretórios, arquivos e alterações individuais feitas 
ao longo do tempo, o que permite aos usuários encontrar as causas raiz 
dos erros ou bugs, ou reverter para uma versão anterior. 
Como vantagem, ter controle de versionamento de software é 
importante porque: 
• bullet 
Melhora a produtividade da equipe e permita a 
colaboração; 
• bullet 
Melhora a comunicação da equipe com uma solução 
confiável; 
• bullet 
Reduz erros e conflitos de desenvolvimento; 
• bullet 
Melhora a satisfação do cliente com versões 
de software confiáveis 
Desenvolvedores, codificadores, designers e engenheiros de software são 
os principais usuários de um sistema de controle de versão 
de software de design e construção. Os gerentes de projeto envolvidos no 
desenvolvimento também podem monitorar as práticas de controle de 
versão. 
Ao escolher um sistema de controle de versão, as primeiras etapas 
incluem saber de qual acesso você precisa e como a equipe deve 
colaborar. O modo como o documento é controlado, editado e mesclado 
também é de importância central. 
A configuração básica inclui os seguintes componentes: 
• bullet 
Repositório: o banco de dados principal que armazena os 
metadados para os arquivos do projeto (o conjunto de 
dados principal é chamado de tronco); 
• bullet 
Servidor: o computador que contém o repositório 
principal; 
• bullet 
Cliente: a máquina que o desenvolvedor usa para se 
conectar ao repositório; 
• bullet 
Cópia de trabalho: a cópia do arquivo do projeto que o 
desenvolvedor edita. 
O controle de versão pode ser uma excelente ajuda para correções de 
emergência, manutenção de rotina, atualizações e novos recursos com 
prazos de desenvolvimento potencialmente sobrepostos. 
Quando você precisa solucionar um problema, pode acessar e comparar 
facilmente o último arquivo de trabalho com o arquivo com defeito e 
diminuir o tempo gasto na identificação da causa de um problema. 
Você pode restaurar versões anteriores de um arquivo (ou até mesmo de 
todo o projeto) de forma eficaz por meio do uso de sistemas de controle 
de versão, sendo que você pode simplesmente desfazer tudo que você 
fez com apenas alguns cliques. 
 A perspectiva de desenvolvimento é dividida em três diferentes 
sistemas: sistema de controle de versões, que é o responsável por cuidar 
que as diversas solicitações de modificação possam ser tratadas em 
paralelo, sem corromper o sistema de gestão de configuração como um 
todo; sistema de controle de modificações, que é responsável pelo 
controle da configuração, armazenando as informações das solicitações 
de modificação e relatando essas informações aos outros participantes; 
e o sistema de gerenciamento de construção, que é responsável por 
automatizar o processo de transformação dos artefatos de software em 
um arquivoexecutável e estruturar as linhas-bases selecionadas para a 
liberação (FREITAS, 2010). 
 
Figura 2 – Perspectivas de desenvolvimento 
Automação e Ferramentas para Controle de 
Versão 
Os sistemas de controle de versão são uma categoria de ferramentas 
de software que ajudam a registrar as alterações feitas nos arquivos, 
mantendo um controle das modificações feitas no código. 
Os sistemas de controle de versão possuem, normalmente, um 
repositório, onde há, tecnicamente, um banco de dados de alterações – 
lá existem todas as edições e versões históricas do projeto. O segundo 
componente é a chamada cópia pessoal de trabalho, ou seja, a cópia de 
todos os arquivos de um projeto. Você, caso seja um desenvolvedor, 
pode editar essa cópia, sem afetar o trabalho dos outros 
desenvolvedores e, ao final, enviar para um repositório quando 
terminar de fazer suas alterações. 
Existem 3 tipos de controle de versão: 
• bullet 
Sistemas de Controle de Versão Local: é um dos mais 
simples e possui um banco de dados que mantém todas as 
alterações dos arquivos sob controle de revisão. Eles 
mantêm conjuntos de patches, ou seja, diferenças entre 
arquivos em um formato especial no disco. Ao adicionar 
todos os patches, ele pode recriar a aparência de qualquer 
arquivo em qualquer momento; 
• bullet 
Sistemas de controle de versão centralizados: contêm 
apenas um repositório e cada usuário obtém sua própria 
cópia de trabalho. Você precisa se comprometer a refletir 
suas mudanças no repositório. É possível que outras 
pessoas vejam suas alterações atualizando. O benefício é 
que ele favorece a colaboração entre os desenvolvedores, 
além de fornecer uma visão, até certo ponto, sobre o que 
todos os outros estão fazendo no projeto. Ele permite que 
os administradores tenham controle refinado sobre quem 
pode fazer o quê. Por outro lado, a desvantagem óbvia é o 
ponto único de falha que o repositório centralizado 
representa se ele cair durante esse período de colaboração 
e não for possível salvar as alterações de versão. E se o 
disco rígido do banco de dados central for corrompido e 
os backups adequados não forem mantidos? Você perde 
absolutamente tudo. Provavelmente, você pensou 
em backup, redundância e contingência. Mas se isso 
ocorrer durante o dia com uma mudança maciça, adeus 
alterações mesmo! Teria que trabalhar com o backup do 
dia anterior ou então você pode possuir algum servidor 
espelhado com um sync a cada 2 horas, por exemplo, mas 
seriam 2 horas perdidas de 
alteração. Alguns softwares: Subversion (SVN) ou Sistema 
de Versão Concorrente (CVS); 
• bullet 
Sistemas de controle de versão distribuída: contêm 
vários repositórios. Cada usuário tem seu próprio 
repositório e sua cópia de trabalho. Apenas confirmar 
suas alterações não dará a outros o acesso às suas 
alterações. Isso ocorre porque o commit irá refletir essas 
mudanças em seu repositório local e você precisa 
“empurrá-las” para torná-las visíveis no repositório 
central. Da mesma forma, ao atualizar, você não obtém as 
alterações de outros, a menos que primeiro tenha obtido 
essas alterações em seu repositório. De forma muito 
simples: 
 
• Você se compromete em mudar o código no seu 
repositório; 
• Você empurra essas mudanças atualizando; 
• Eles puxam as mudanças feitas; 
• Eles o atualizam repositório central deles e o ciclo 
reinicia. 
Um sistema de controle de versão distribuído é projetado para atuar nos 
dois sentidos. Ele armazena todo o histórico do arquivo em cada 
máquina localmente. Ele também sincroniza as alterações locais feitas 
pelo usuário de volta ao servidor sempre que necessário, para que as 
alterações possam ser compartilhadas com outras pessoas, 
proporcionando um ambiente de trabalho colaborativo. 
 
Figura 3 – Alguns softwares de controle de versão e seus tipos 
Quais os mais famosos? 
Subversion (SVN) - é um sistema de controle de versão que foi 
originalmente projetado para substituir o CVS (Concurrent Versions 
System) enquanto adiciona funcionalidades que faltavam ao CVS. 
Lançado originalmente em 1990, o sistema de controle de versão CVS 
tinha altas classificações em seus dias e viu sua versão estável final ser 
lançada em 2008. O SVN é considerado de segunda geração. Mais 
significativamente, ele depende de um repositório central. Embora 
esteja crescendo há anos pelos padrões de software, no entanto, ele 
ainda está em desenvolvimento ativo e uso ativo em todo o mundo. 
Enquanto muitas empresas podem querer um SVN mais moderno que 
suporte ramificação infinitas e um modelo de repositório distribuído, o 
SVN ainda é um candidato sólido e funciona maravilhosamente bem 
com certos fluxos de trabalho. 
Você poderá instalar aqui: 
para Windows. 
ACESSE 
Você poderá instalar aqui: 
para servidores Apache 
ACESSE 
https://tortoisesvn.net/downloads.html
https://subversion.apache.org/
 
Figura 4 – Interface Subversion AquaDataStudio 
Fonte: Reprodução 
Saiba Mais 
Vamos aprender como se faz: PRONUS. Controle de Versão 
com Subversion disponível em: 
Git - desenvolvido sob a direção de Linus Torvald, o projeto Git foi 
lançado em 7 de abril de 2015, apenas alguns dias antes do lançamento 
do Mercurial, e ganhou muita força ao longo dos anos e se beneficia da 
interface on-line bem projetada do GitHub que permite colaboração, 
revisão de código e gerenciamento de código para open source e projetos 
privados. Com o Github, projetos públicos são sempre gratuitos e 
compartilhar repositórios Git se tornou o método preferido para muitos 
desenvolvedores de software de código aberto compartilharem e 
colaborarem em projetos. Pode fazer quase tudo que o desenvolvedor 
quiser. Mas, por outro lado, o Git pode ser complicado de aprender, não 
é bem documentado e muda rapidamente, de modo que acompanhar 
todos os seus recursos pode ser um desafio, mesmo com os vídeos e 
cursos que tem por aí. 
Você poderá instalar aqui: 
para vários sistemas operacionais. 
ACESSE 
Você poderá instalar aqui: 
GitHub para Windows. 
ACESSE 
https://git-scm.com/downloads
https://github.com/git-for-windows
 
Figura 5 – Interface GIT 
Fonte: Reprodução 
Saiba Mais 
Vamos aprender como: Git e GitHub: prático e sem usar 
comandos no terminal. 
Mercurial – um concorrente direto do Git, o sistema de controle de 
versão Mercurial é um pouco mais simplificado e bem documentado e é 
escrito em Python em vez de C e C++. O maior cliente do Mercurial é de 
longe o Facebook. 
Você poderá instalar aqui: 
para vários sistemas operacionais. 
ACESSE 
https://www.mercurial-scm.org/wiki/Download
 
Figura 6 – Interface do EasyMercurial 
Fonte: Reprodução 
Saiba Mais 
Vamos aprender: WILL, B. Controle de versão com Mercurial. 
Disponível em: 
Essa é a parte dois desse vídeo com o mesmo título e autor, 
apenas muda o link: 
Ambientes de Desenvolvimento Colaborativo 
de Software 
Não adianta falar de ambiente sem antes falar sobre o que é 
colaboração. 
Colaboração é uma prática de trabalho pela qual os indivíduos 
trabalham juntos para um propósito comum de obter benefícios 
comerciais. Isso, além de honesto, é verdadeiro. Poderíamos mencionar 
aqui os efeitos e benefícios sociológicos e psicológicos da colaboração 
entre adultos, mas o foco é software e o desenvolvemos dentro de 
empresas e empresas visam ao lucro. Então, como bons 
desenvolvedores e analistas de sistemas, devemos abstrair o essencial 
desse modelo e construir com a máxima eficiência. 
Os espaços de trabalho compartilhados estão entre as entradas mais 
visíveis no espaço de colaboração. Eles visam ao compartilhamento de 
documentos e aplicativos com bate-papo e, talvez, controle de versão e 
outros recursos de auditoria, eles podem ter mais ou menos. O Google 
Docs é um exemplo notável por ser gratuito para indivíduos que se 
juntam para cumprir um objetivo. Professores, no geral, utilizam 
bastante para que os alunos aprendam a desenvolver trabalhos em 
equipe dinâmicos e, também, aprendem alguns soft skills como trabalho 
em equipe e pensamentocomputacional. Temos também o Microsoft 
SharePoint, o Office 365 entre os mais conhecidos. 
Mas ainda temos, em nível corporativo, repositórios coletivos de bases 
de conhecimentos, um lugar onde os que vieram antes escreveram 
coisas importantes, como enfrentamentos de problemas para os que 
estão na empresa agora – não temos que ficar constantemente 
“reinventando a roda”. 
Os wikis, nesse caso, talvez sejam considerados como enciclopédias on-
line ou manuais de como fazer, em muitas empresas. Eles são soluções 
que permitem aos usuários criar, editar e reorganizar livremente o 
conteúdo, mas, acima de tudo criar e manter conhecimento adquirido 
com muito suor nos projetos feitos pelas equipes de desenvolvimento e 
gestão na empresa, garantindo que não haverá perda da memória 
empresarial. Quando falamos em wiki, o que nos vem à mente é a mais 
famosa delas, a Wikipedia, que ainda é discriminada no meio acadêmico, 
mas é fartamente utilizada pelos estudantes no meio de 
desenvolvimento e engenharia. 
Claro que grande parte dessa suposta má fama é a de que qualquer um 
pode inserir qualquer coisa, por isso é importante que todos da 
empresa, ou melhor, todos os desenvolvedores e analistas de negócios 
sempre examinem as informações para garantir que nada de errado seja 
colocado lá, mesmo de forma não intencional. 
É tudo uma questão de cultura e maturidade da equipe e da empresa. 
Há, hoje, duas formas de pessoas e times colaborarem: 
• bullet 
Síncrono, onde todos interagem em tempo real, como em 
reuniões on-line, por meio de mensagens instantâneas, 
entre outros; 
• bullet 
Assíncrono, onde a interação pode ser em momentos 
diferentes no tempo, como ao enviar documentos ou 
anotações para espaços de trabalho compartilhados ou 
fazer contribuições numa wiki. 
O autopoliciamento é a chave para o sucesso num grupo 
multidisciplinar para o controle do conteúdo. Não devemos esquecer 
que colaboração envolve: conscientização, motivação, participação, 
mediação, pacto, reciprocidade, autorreflexão, entre outras coisas. 
Há um texto muito importante nas fontes do GitHub que vale a pena 
citar aqui sobre contribuição, especificamente sobre a transparência e 
na distribuição de cargas de trabalho. 
Transparência é a base para qualquer cultura de fonte interna, assim 
como para a comunidade de fonte aberta mais ampla. 
Compartilhe projetos em sua organização da forma mais ampla 
possível. Exceções podem ser feitas para projetos que requerem um 
nível mais alto de segurança caso a caso. 
Certifique-se de que sua equipe tenha as ferramentas e processos para 
se comunicar abertamente e construir de forma consistente – e que 
essas ferramentas e processos estão sendo usados. Se não estiverem, 
descubra o porquê e faça ajustes até estabelecer uma rotina sólida. 
Confirme se suas iniciativas de engenharia possuem recursos 
adequados e são apoiadas pela liderança. 
Dê aos desenvolvedores autonomia suficiente para contribuir com 
projetos fora de suas equipes imediatas. 
Quanto a carga de trabalhos, para adotar práticas internas de maneira 
eficaz, os colaboradores precisam ser capazes de trabalhar facilmente 
entre equipes e silos organizacionais. 
Torne as aprovações e revisões mais eficazes, distribuindo o controle 
por um grupo menor de participantes. Uma pequena equipe 
multifuncional de tomadores de decisão também pode ajudar as equipes 
a manter os padrões de qualidade e obter apoio da liderança. 
Distribua cargas de trabalho pesadas entre desenvolvedores 
distribuídos geograficamente ou até mesmo com membros da equipe 
que não são desenvolvedores. 
Lembre-se de que os não desenvolvedores são um recurso valioso para 
sua comunidade como fonte interna. 
Os gerentes de projeto podem avaliar rapidamente o estado do projeto, 
e as alterações feitas nos cronogramas do projeto podem ser vinculadas 
diretamente ao código em questão. 
Os escritores técnicos devem ser encorajados a trabalhar junto com os 
engenheiros de projeto, documentando precisamente os recursos do 
código de onde eles se originam. 
Os engenheiros de segurança podem revisar o código em busca de 
conformidade e pontos fracos relacionados à segurança, evitando 
problemas no início do fluxo de trabalho. 
GITHUB, 2019, p. 1-2 
Transparência é a base para qualquer cultura de fonte interna, assim 
como para a comunidade de fonte aberta mais ampla. 
Compartilhe projetos em sua organização da forma mais ampla 
possível. Exceções podem ser feitas para projetos que requerem um 
nível mais alto de segurança caso a caso. 
Certifique-se de que sua equipe tenha as ferramentas e processos para 
se comunicar abertamente e construir de forma consistente – e que 
essas ferramentas e processos estão sendo usados. Se não estiverem, 
descubra o porquê e faça ajustes até estabelecer uma rotina sólida. 
Confirme se suas iniciativas de engenharia possuem recursos 
adequados e são apoiadas pela liderança. 
Dê aos desenvolvedores autonomia suficiente para contribuir com 
projetos fora de suas equipes imediatas. 
Quanto a carga de trabalhos, para adotar práticas internas de maneira 
eficaz, os colaboradores precisam ser capazes de trabalhar facilmente 
entre equipes e silos organizacionais. 
Torne as aprovações e revisões mais eficazes, distribuindo o controle 
por um grupo menor de participantes. Uma pequena equipe 
multifuncional de tomadores de decisão também pode ajudar as equipes 
a manter os padrões de qualidade e obter apoio da liderança. 
Distribua cargas de trabalho pesadas entre desenvolvedores 
distribuídos geograficamente ou até mesmo com membros da equipe 
que não são desenvolvedores. 
Lembre-se de que os não desenvolvedores são um recurso valioso para 
sua comunidade como fonte interna. 
Os gerentes de projeto podem avaliar rapidamente o estado do projeto, 
e as alterações feitas nos cronogramas do projeto podem ser vinculadas 
diretamente ao código em questão. 
Os escritores técnicos devem ser encorajados a trabalhar junto com os 
engenheiros de projeto, documentando precisamente os recursos do 
código de onde eles se originam. 
Os engenheiros de segurança podem revisar o código em busca de 
conformidade e pontos fracos relacionados à segurança, evitando 
problemas no início do fluxo de trabalho. 
GITHUB, 2019, p. 1-2 
Agilidade e Gerenciamento de Configuração 
Preponderantemente, as empresas de software utilizam metodologias 
ágeis. Portanto, mais que nunca é importante entender que a 
implementação do gerenciamento de configuração deve ser ajustada 
para garantir que os princípios do Agile permaneçam intactos sem 
danificar nenhum dos princípios, então, identificar, controlar, auditar e 
relatar são princípios que independentes da metodologia devem ser 
mantidos. Qual o mindset necessário para uma gerência configuração 
ágil: 
Pense menor: Um dos principais focos do Ágil é pensar em iterações 
menores e incrementos de trabalho. A Gestão de Configuração – GC 
deve suportar a capacidade de gerenciar incrementos menores de 
trabalho e o aumento na taxa de mudança. GC para ágil não é GC 
mínimo, mas GC que pode lidar com identificação e controle rápidos a 
fim de manter o ritmo acelerado de mudança e, ao mesmo tempo, 
minimizar o esforço no gerenciamento da mudança. Embora seja mais 
uma função de gerenciamento de produto ou gerenciamento de 
liberação, o GC precisa estar pronto para acomodar as partes menores 
de trabalho e maior taxa de mudança. Normalmente, isso significa que 
há mais entregas incrementais (internas e externas) com a implicação 
de uma maior necessidade de automação, ajustes na ramificação e uma 
necessidade mais forte de mesclagem automatizada (mais sobre isso 
em breve). 
Construir continuamente: Em uma metodologia de desenvolvimento 
tradicional com ciclos de lançamento mais longos, a construção do 
código normalmente não começa até a fase de desenvolvimento e a 
construção frequentemente pode ser semanal com algumas equipes 
reduzindo isso paravárias vezes por semana ou até mesmo todas as 
noites. Em uma metodologia ágil, os builds devem ser contínuos, 
significando com a frequência diária ou noturna e mais tipicamente 
após cada check-in (ou promoção) no fluxo de integração. Além disso, é 
essencial que uma construção bem-sucedida ocorra no espaço de 
trabalho privado com as mudanças locais e a última linha de base do 
código do pai ou fluxo de apoio antes de promover ou verificar o código 
para o fluxo pai (observe, esta é uma boa prática independentemente da 
metodologia de desenvolvimento utilizada). 
A capacidade de realizar compilações contínuas também implica que 
você tenha as ferramentas e os processos adequados para gerenciar essa 
frequência. Implementar ferramentas de construção como Cruise 
Control ou Build Forge (e existem muitas outras) ajudará a conseguir 
isso. Outra opção é criar um script de função de construção no check-in. 
Além disso, há uma forte necessidade de entender a prática de 
construção atual e adaptá-la com os tipos de construção que são 
necessários (privado, compartilhado, integração, liberação) e níveis de 
construção (componente, produto etc.). Isso ajuda a determinar onde 
estão os gargalos – logo, onde estão os resíduos. 
MOREIRA, 2008, p. 2-3 
Pense menor: Um dos principais focos do Ágil é pensar em iterações 
menores e incrementos de trabalho. A Gestão de Configuração – GC 
deve suportar a capacidade de gerenciar incrementos menores de 
trabalho e o aumento na taxa de mudança. GC para ágil não é GC 
mínimo, mas GC que pode lidar com identificação e controle rápidos a 
fim de manter o ritmo acelerado de mudança e, ao mesmo tempo, 
minimizar o esforço no gerenciamento da mudança. Embora seja mais 
uma função de gerenciamento de produto ou gerenciamento de 
liberação, o GC precisa estar pronto para acomodar as partes menores 
de trabalho e maior taxa de mudança. Normalmente, isso significa que 
há mais entregas incrementais (internas e externas) com a implicação 
de uma maior necessidade de automação, ajustes na ramificação e uma 
necessidade mais forte de mesclagem automatizada (mais sobre isso 
em breve). 
Construir continuamente: Em uma metodologia de desenvolvimento 
tradicional com ciclos de lançamento mais longos, a construção do 
código normalmente não começa até a fase de desenvolvimento e a 
construção frequentemente pode ser semanal com algumas equipes 
reduzindo isso para várias vezes por semana ou até mesmo todas as 
noites. Em uma metodologia ágil, os builds devem ser contínuos, 
significando com a frequência diária ou noturna e mais tipicamente 
após cada check-in (ou promoção) no fluxo de integração. Além disso, é 
essencial que uma construção bem-sucedida ocorra no espaço de 
trabalho privado com as mudanças locais e a última linha de base do 
código do pai ou fluxo de apoio antes de promover ou verificar o código 
para o fluxo pai (observe, esta é uma boa prática independentemente da 
metodologia de desenvolvimento utilizada). 
A capacidade de realizar compilações contínuas também implica que 
você tenha as ferramentas e os processos adequados para gerenciar essa 
frequência. Implementar ferramentas de construção como Cruise 
Control ou Build Forge (e existem muitas outras) ajudará a conseguir isso. 
Outra opção é criar um script de função de construção no check-in. Além 
disso, há uma forte necessidade de entender a prática de construção 
atual e adaptá-la com os tipos de construção que são necessários 
(privado, compartilhado, integração, liberação) e níveis de construção 
(componente, produto etc.). Isso ajuda a determinar onde estão os 
gargalos – logo, onde estão os resíduos. 
MOREIRA, 2008, p. 2-3 
 
2 - 
Material Complementar 
 
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/YZrn56Vp_C3rK_RUEeKhwyHQmFflOjvX
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/YZrn56Vp_C3rK_RUEeKhwyHQmFflOjvX
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/YZrn56Vp_C3rK_RUEeKhwyHQmFflOjvX
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/YZrn56Vp_C3rK_RUEeKhwyHQmFflOjvX
Material Complementar 
2 / 3 
Indicações para saber mais sobre os assuntos abordados 
nesta Unidade: 
Vídeos 
Controle de versão – Versionamento Centralizado e Distribuído 
Aprenda sobre controle de versão e como funciona o controle de versão 
centralizado e o descentralizado (distribuído). 
Gerência de Configuração – Introdução e Conceitos 
Introdução ao versionamento de código 
Gestão ágil de projetos com os superpoderes do Trello 
Chegar para trabalhar bem cedinho no escritório e descobrir que você 
tem notificações em meia dúzia de ferramentas diferentes para 
responder, como Slack, e-mail, Google Sheets e até sua ferramenta de 
CRM pode ser um tanto frustrante. Para acabar com essa mudança de 
contexto, você pode usar o Trello como um verdadeiro hub para 
trabalhar com todas as ferramentas que você e seu time usam de forma 
colaborativa. Em um só lugar, sem ter que fazer login em todas elas. 
 
3 - 
Referências 
 
 
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/qIQ2WMJY4i_1GZxI-uMNkB-uMSxBlxXb
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/qIQ2WMJY4i_1GZxI-uMNkB-uMSxBlxXb
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/qIQ2WMJY4i_1GZxI-uMNkB-uMSxBlxXb
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273310-dt-content-rid-134566423_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_I/flip/index.html#/lessons/qIQ2WMJY4i_1GZxI-uMNkB-uMSxBlxXb