O que é, e pra que serve?

Mudanças Inevitáveis no Projeto

• Mudanças nos Requisitos
• Mudanças no Código Fonte
• Mudanças no Ambiente de Desenvolvimento
• etc...

Atividades da GCS

Fluxo de trabalho Integrado

Controle de Mudanças

Controle de Versão

Integração Contínua

Ferramentas que auxiliam no registro, avaliação, planejamento e acompanhamento das solicitações de mudanças mudanças

Ferramentas que realizam o registro histórico das configurações, controle da concorrência de edição dos arquivos, cria e mantém variações do projeto 

Ferramentas as quais executam scripts de construção, teste e métricas de qualidade para avaliar a integridades do Sistema

Ferramentas de GC/CM

Situações Comuns

1. "Essa mudança não deu certo, vamos voltar como estava antes."
2. "O que mudou nessa rotina? Quando foi essa mudança? Quem é o responsável?"
3. "Esse defeito já tinha sido corrigido, como apareceu?"
4. "A nova função que implementei ontem era pra estar aqui mas sumiu."  
5. "Preciso daquela versão que está no cliente. Cadê os arquivos?"
6. "Como fazer os teste sem para o desenvolvimento?"

Registrar a evolução do projeto

Registrar a evolução do projeto

• O que mudou?
• Quem mudou?
• Quando mudou?

Registrar a evolução do projeto

Trabalho em equipe

Trabalho em Equipe

Provê mecanismos para controle de concorrência:

• Travamento
• Mesclagem de arquivos
• Ramos individuais

Variações de projeto

Um controle de versão é composto por:

Rastreabilidade Bidirecional

Changeset

=

diferença entre duas configurações

Conceitos importantes

Configuração é o estado dos arquivos do projeto em um determinado momento

Revisão é uma configuração registrada no repositório

Changeset é o conjunto de diferenças entre duas configurações

Versão é uma revisão usada em produção (Release)

Operações do Controle de Versão

Variam de acordo com o arranjo entre o repositório e espaço de trabalho

Controle de Versão Centralizado

Controle de Versão Distribuido

Sincronização de Repositórios

Resumo das operações Básicas

Identificação das Revisões

Mas antes, o que é baseline e codeline?

Delta Storage

• mantém como um conjunto de arquivos e as mudanças feitas a cada arquivo ao longo do tempo

Snapshot Storage

• Conjunto de snapshots de arquivos;
• Se foi alterado, o arquivo não é armazenada ( link para o arquivo que já foi armazenado)

O que é o Git?

• É um sistema de controle de versão distribuído
• Uma das ferramentas de GC mais utilizadas (Rebellabs)
• Foi criado por Linus Torvalds como alternativa para manter o Kernel do Linux

Existem três componentes em um projeto Git:

• Um repositório (repository), onde as mudanças são registradas

• Um espaço de trabalho (working directory), onde contém os arquivos que você está trabalhando

• Um index ou staging area, onde os commits/revisões são preparadas, comparando os arquivos do working directory e do repository.

Em um fluxo básico do Git

1. Os arquivos são modificados no espaço de trabalho
2. As mudanças são preparadas (staged) com o que você deseja incluir no próximo commit.
3. As mudanças são submetidas, o que as retira do index e as armazena no repositório.

Estados no GIT

Fluxos com Repositórios

Onde encontrar a explicação os comandos?

ou

Configurando o ambiente

Identificação

Editor

Verificar configurações atuais

Iniciando um projeto

Para iniciar um repositório Git:

Este comando cria toa a estrutura que o Git necessita para funcionar.

Os arquivos são criados na pasta oculta .git/

Verificando o estado do projeto

O git status exibe as alterações ocorridas no repositório desde o último commit.

Adicionando arquivos

O git add adiciona ou atualiza um arquivo da staging area.

Ou seja, o comando informa ao Git para rastrear o referido arquivo. Caso o arquivo já esteja sob controle do Git, ele o atualiza.

Confirmando mudanças

git commit transfere o estado do projeto salvo na staging area para o repositório do projeto.

Todo commit deve possuir uma mensagem de identificação, usada para descrever as alterações do commit.

Favor, use-a para tal fim.

Escreva mensagens intuitívas.

Comparando Alterações

O comando git diff compara o estado do repositório atualmente com o estado salvo na staging area

O git status informa "quem" foi alterado, mas e se eu quiser saber exatamente "o que" foi alterado?

O comando git diff --cached compara o estado do repositório salvo na staging area com o estado do último commit

Histórico de Alterações

O comando git log exibe o histórico de commits do projeto

Um pouco mais sobre git log

'Passeando' pelo Projeto

A partir do código associado aos commits você pode voltar para um determinado 'estado' do projeto

O comando git checkout também redireciona arquivos e branches

Se eu me arrepender das minhas últimas alterações?

Você pode descartar mudanças no seu working directory voltando o estado dos seus arquivos para o último salvo na staging area.

E se eu já adicionei as alterações na staging area?

O comando git reset HEAD devolve as modificações da staging area para o working directory.

E se eu já commitei minhas alterações?

1ª Solução: git reset

O comando git reset faz o projeto/arquivo voltar para um estado anterior.

2ª Solução: git reset

O comando git revert não desfaz um commit, mas cria outro removendo a alteração anterior

E se eu já commitei minhas alterações?

Removendo arquivos

O comando git rm remove um arquivo do seu projeto.

A opção --cached remove o arquivo apenas do Git, sem esta opção o comando remove o arquivo do seu computador também.

Ignorando arquivos

Deixar todos os arquivos contidos na pasta do projeto sob controle do Git pode acabar dificultando o gerenciamento, e muitas vezes simplesmente não achamos necessário rastrear alterações de alguns arquivos (arquivos temporários, executáveis e etc...).

O arquivo oculto .gitignore é o responsável por dizer ao Git quais arquivos ele pode ignorar.

Ignorando arquivos

• Basta adicionar uma pattern que o Git usará para ignorar os arquivos.

• Todos os arquivos que 'casarem' com as patterns serão ignorados.

• As patterns seguem o padrão utilizado nos sistemas unix/Linux.

Exemplos de patterns e extensões podem ser geradas em gitignore.io

Ramificando a produção de software

O Git permite criar uma linha independente de desenvolvimento no seu projeto. Isto permite alterações em partes especificas do software sem comprometer o restante do projeto.

Ramificando a produção de software

O comando git branch cria um novo branch a partir do último commit.

Além de visualizar commits antigos, o git checkout também é o responsável por alterar o branch corrente.

Após desenvolvedor uma funcionalidade separada do fluxo principal, muitas vezes é interessante incorporar as modificações no branch master.

O comando git merge uni dois branches novamente, combinando as funcionalidades do branch independente com o branch atual.

Quando não há commits posteriores à criação do branch, a incorporação das funcionalidades ocorre sem nenhum problema.

Porém, quando os branches divergem, o Git precisa que combinar seus conteúdos.

Para informar o trecho conflitante, o Git sinaliza as linhas do arquivo com algumas marcações(<<<<<<<, ======= e >>>>>>>), para corrigir o conflito e confirmar o merge, basta apagar as linhas desnecessárias do arquivo, mantendo conteúdo escolhido, e efetuar um novo commit. Este é basicamente o único trabalho manual que o Git necessita

Merge em novo commit

• --no-ff faz com que a mesclagem sempre crie um novo commit.

Após incorporar um branch à outro, pode não ser mais necessário manter uma ramificação. Para deletar um branch utiliza-se do parâmetro -d juntamente com o comando git branch

Branches Principais

Tempo de vida infinito

máster (origin/master)

• Reflete o estado do código fonte de produção

develop (origin/develop)

• Reflete ultimas mudanças entregues em desenvolvimento
• A.k.a.: "Integration Branch"

Branchs de Suporte

• ​Tempo de vida limitado
• Desenvolvimento paratelo entre membros da equipe;
• facilitar o rastreamento defeatures;
• Preparar releases para produção
• Correção rápida de problemas "live production"

Feature Branch

• Aka.: "topic branch"
• são usadas para desenvolver novos recursos para o lançamento futuro distante ou futuro.
• Existem apenas nos repositórios de desenvolvimento do desenvolvedor

Release Branch

Release branches dão suporte à preparação de uma nova liberação(release) de produção.

Utlizadas para pequenas correções de bugs e preparar metadados para uma versão (número da versão, datas de criação, etc.)

Hotfix Branch

• Criada quando ocoorre um erro crítico em uma versão de produção
• A hotfix é ramificada da tag correspondente na ramificação máster que marca a versão de produção.

Trabalhando com repositórios remotos

Muitas empresas possuem servidores dedicados para suas equipes, mas há algumas soluções no mercados que cumprem a mesma função.

Referenciando um repositório remoto

O comando git remote add é o responsável por referenciar um repositório remoto em um repositório local já existente

O comando git remote rm é utilizado para apagar uma referência à um repositório remoto. Util quando se deseja substituir o local onde o remoto está hospedado.

Copiando um repositório remoto

Quando se deseja iniciar/continuar um projeto já existente, utiliza-se dogit clone para copiar todo um repositório remoto para uma máquina local.

Baixando conteúdo do remoto

O Git disponibiliza duas maneiras de baixar as atualizações de um repositório remoto. O comando git fetch baixa as atualizações mas não as incorpora ao repositório local.

Baixando conteúdo do remoto

Outra maneira é utilizando o comando git pull, que baixa e incorpora as modificações no repositório local. Equivale à um git fetch seguido de uma git merge.

O que é uma release?

Um release de sistema é uma versão de um sistema de software distribuída aos clientes.  (Sommerville, 2011).

Versionamento Semânico

Dado um número de versão MAJOR.MINOR.PATCH, incremente a:

1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API,
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.

Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.

https://semver.org/lang/pt-BR/​

Versionamento Semânico

Criando Versões

• Conforme incluímos funcionalidades no sistema, podemos definir pontos relevantes no software, que geralmente, marcam uma versão de lançamento.

• O comando git tag inclui um rótulo à um determinado commit para que este possa ser referenciado mais facilmente.

Compartilhando Versões

• Para visualizar as versões ja criadas, utilize  git tag.

• Por padrão, o comando git push não transfere tags

• Você deve enviar as tags explicitamente – você executa git push origin [nome-tag].

• se deseja enviar muitas tags ao mesmo tempo digite:

Gestão de Mudanças

• Organizational needs and requirements change during the lifetime of a system
  • bugs have to be repaired
  • and systems have to adapt to changes in their environment.
• The change management process is concerned with
  • analyzing the costs and benefits of proposed changes,
  • approving those changes that are worthwhile and
  • tracking which components in the system have been changed.

Ian Sommerville

"

"

Gestão de Mudanças

O processo de controle de mudanças deve ser implementado depois que uma baseline for fixada - antes disso, somente um controle de mudanças informal precisa ser aplicado

Roger Pressman

"

"

Processo?

Nããããããoooooo!

Pra quê processo?

 Processos permitem que:

Ian Sommerville

Fatores de Análise de mudanças

• O ciclo de release do produto
• Os custos de fazer uma mudança
• O número de usuários afetados pela mudança
• As consequencias de não realizar a mudança

Formulário de Solicitação de Mudanças (a)

Formulário de Solicitação de Mudanças (b)

Estados de uma solicitação de mudanças

Gestão de Mudanças e Métodos Ágeis

• O cliente geralmente está diretamento envolvido na gestão de mudanças

• Ele propõe a mudança dos requisitos e trabalha com o time para avaliar o impacto e decidir a prioridade da mudança em relação aos demais requisitos

• Alterações para melhoria do software são decididas pelos programadores que trabalham no sistema

• A refatoração, onde o software é aprimorado continuamente, não é vista como uma sobrecarga, mas como uma parte necessária do processo de desenvolvimento.

GitHub

Para gerenciamento de Mudanças

Gestão de mudanças no Github?

• Issues
• Projects
• Pull requests

Integração Contínua

Continuous integration (CI) is a software development practice where
developers regularly merge their code changes into a central repository, after
which automated builds and tests are run.
 

Amazon Web Series, 2017

CI most often refers to the build or
integration stage of the software release process and requires both an automation component (e.g., a CI or build service) and a cultural component (e.g., learning to integrate frequently)

Amazon Web Series, 2017

• Sistema de Controle de Versão
• Automatização de build
• Self-testing build
• Integração diária

1. Encontrar e investigar bugs mais rapidamente;
2. Melhorar a qualidade do software; e
3. Reduzir o tempo que leva para validar e lançar novas atualizações de software.

Benefícios da Integração Contínua

CI Workflow

CD extends CI

Continuous delivery (CD) is a software development practice where code
changes are automatically built, tested, and prepared for production release

Amazon Web Series, 2017

CD != CD

continuous delivery is not to apply every change to
production immediately, but to ensure that every change is ready to go to
production.

Amazon Web Series, 2017

Qual a principal diferença?

CI/CD Pipeline

O que é GitHub Actions?

• É uma ferramenta que permite automatizar fluxos de trabalho (workflow) de CI e CD dentro do próprio GitHub.
• Você pode escrever tarefas individuais (actions) e combina-las para criar um workflow padronizado.

O GitHub Actions permite que você crie fluxos de trabalho personalizados de ciclo de vida de desenvolvimento de software (SDLC, Software Development Life Cycle) diretamente no seu repositório do GitHub.

GitHub, 2020

O que são workflows?

Workflows são processos automatizados que podem ser configurados em seu repositório para construir, testar, empacotar ou implantar qualquer projeto (no Github).

É basicamente, um pipeline CI/CD

Jobs

• Uma séria de passos (steps) que podem ser executados no mesmo runner.
• As regras de dependência entre eles são definidas no arquivo que define o workflow
• Podem ser executados em paralelo eu sequencialmente dependendo do status do job anterior.

Runners

• Qualquer máquina com GitHub Actions Runner Instalado
• Responsável por executar seus jobs quando um de seus eventos é disparado
• Podem ser hospedadas no GitHub (GitHub Runners) ou administradas externamente por você (Self-hosted Runners)

Runners

• Os GitHub Runners pode ser Linux, Windows e MacOS.
  • ​Veja mais aqui.
• Já possuiem software e ferramentas mais usadas instalados por padrão (não é possível configura-las)
  • Já possuem ferramentas e suporte a linguagens (Python, Ruby, nodejs), Android SDK e Xcode.
  • Veja mais aqui.

• Já Self-Hosted Runners possibilitam mais controle do hardware, sistema operacional e ferramentas.

Vamos praticar um pouco