Ferramentas para Versionamento de

Código e Integração Contínua

Agenda

Quem sou?

• Vanilton da Thálita 💍
• Pai do Louie 👦🏻 e Lourenzo 👶🏻
• Cientista da Computação 🤓
• 🎓 Especialista  em Engenharia de Software e Gestão de Pessoas
• 👨🏻‍💻Pessoas e Processos na @fpf.tech 😃
• 👨🏻‍🏫 Professor na @etech

O que é uma versão?

O que é uma versão?

 Alterar, entornar, mudar

O que é Gerenciamento?

Ato de administrar, dirigir

Gerenciamento de versão é?

Ato de administrar ou dirigir mudanças

Sistema que registra alterações em arquivos ao longo do tempo para que versões específicas possam ser recuperadas posteriormente.

Controle de Versão

Sistema de controle de versões:

• VCS (do inglês version control system)

• SCM (do inglês source code management)

Nomeclaturas

Nós versionamos apenas código?

Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentação.  

História

História

• Reverter estados
• Comparar mudanças
• Modificações (identificar causas e quem ocasionou)
• Quando foram introduzidos problemas

Benefícios

Benefícios

Aplicações

Aplicações

Equipes de desenvolvedores podem trabalhar simultaneamente no mesmo projeto, cada um em suas próprias "ramificações" (branches), sem conflito.

Aplicações

Autores e editores podem rastrear diferentes versões de um manuscrito, identificando mudanças, correções e revisões.

Aplicações

Utilizado para rastrear alterações em documentos de projeto, especificações técnicas e manuais.

Diversas pessoas podem editar simultaneamente sem sobrescrever o trabalho de outras, comum em redação colaborativa de papers e relatórios.

Aplicações

Engenheiros podem usar sistemas de controle de versão para arquivos CAD, gerando diferentes versões de projetos mecânicos ou arquitetônicos.

Aplicações

Designers podem usar controle de versão para gerir diferentes versões de arquivos de design (ex: PSD, AI), permitindo a recuperação de trabalhos anteriores.

Aplicações

Sistemas como Jenkins, GitHub Actions, GitLab CI, ou Travis CI usam controle de versão para automatizar testes, builds e deploys contínuos.

Aplicações

Para conteúdos de sites estáticos utiliza-se controle de versão para facilmente verificar o que está presente de conteúdo e em casos específicos retornar versões ou até mesmo avançar versões.

Sistemas Locais de Versão

Um Sistema Local de Versionamento armazena o histórico de alterações de arquivos em um único computador, permitindo que o desenvolvedor rastreie versões, faça alterações e reverta mudanças.

Sistemas Locais de Versão

Sistemas Locais de Versão

Sistemas Locais de Versão

Sistemas Locais de Versão

Atividade 1

1. Siga as instruções no link.
2. Tome nota das dificuldades enfrentadas na atividade.

10 Minutos

Sistema Centralizado de Versão (CVCS)

Um Sistema Centralizado de Controle de Versão (CVCS) armazena todo o histórico de versões e arquivos em um servidor central. Desenvolvedores fazem checkout do código diretamente desse servidor, e todas as alterações (commits) são registradas centralmente.

Sistema Centralizado de Versão (CVCS)

Sistema Centralizado de Versão (CVCS)

Sistema Centralizado de Versão (CVCS)

Exemplos de CVCSs

Criando um CVCSs com SVN + Docker

O servidor SVN estará disponível em svn://localhost:3690. O repositório será armazenado na pasta ./svn-repos localmente no host.

Fonte: https://github.com/garethflowers/docker-svn-server

Configurando um repositório com SVN + Docker

Configurando um repositório com SVN + Docker

Customizando sua imagem com SVN + Docker

Criando um CVCSs com SVN Windows

https://www.visualsvn.com/downloads/

Configurando um CVCSs com VisualSVN Server

1. Criar um usuário
2. Criar um repositório permitindo ao usuário criado no passo 1 ter acesso de leitura e escrita

Acessando o repositório criado no VisualSVN Server

Instalando um Cliente SVN

https://tortoisesvn.net/downloads.html

Terminologias

O local central onde todo o código-fonte e histórico de versões de um projeto são armazenados.

Um commit no contexto destes sistemas de controle de versão refere-se a submeter as últimas alterações do código fonte ao repositório e tornar estas alterações parte da versão principal (head) do repositório.

Terminologias

Terminologias

Branch (Ramo): Uma linha paralela de desenvolvimento, permitindo que diferentes versões de um projeto coexistam. Branches são usados para desenvolver novos recursos ou corrigir bugs sem afetar o código principal.

Merge: O processo de integrar as alterações de uma branch a outra. Em geral, o merge une as modificações de uma branch secundária ao branch principal.

Terminologias

Terminologias

Tag: Um marcador para identificar versões específicas no repositório, como uma versão de lançamento (v1.0, v2.0 etc.). Diferente das branches, as tags são usadas como pontos fixos, sem intenção de novas alterações.

Checkout: Ação de copiar o código de uma versão específica do repositório para uma máquina local, permitindo ao usuário editar e visualizar o código em uma versão selecionada.

Terminologias

Terminologias

Conflict (Conflito): Ocorre quando alterações conflitantes são feitas na mesma linha de código por diferentes colaboradores. Normalmente, é necessário resolver conflitos manualmente durante um merge.

Diff: Uma comparação entre duas versões do código para destacar o que foi adicionado, removido ou alterado.

Terminologias

Terminologias

Blame: Uma funcionalidade que permite visualizar qual usuário fez mudanças específicas em linhas de código. Útil para rastrear o autor e a data de uma modificação.

Revert: Ação de desfazer uma ou mais alterações no código. Pode ser usada para voltar o código a um estado anterior sem remover completamente o histórico.

Terminologias

Terminologias

Log: Exibe o histórico de modificações de um dado repositório contendo informações como descrição de commits, data e hora e nome do responsável pelas versões.

Staging Area (ou Index): Um espaço onde as mudanças são preparadas antes do commit. O usuário seleciona quais mudanças deseja enviar ao repositório, permitindo controle sobre o que é incluído no próximo commit.

Terminologias

Atividade 2

1. Siga as instruções no link.
2. Tome nota das dificuldades enfrentadas na atividade.

45 Minutos

Sistema Centralizado de Versão (CVCS)

Em um DVCS os clientes não somente usam o estado mais recente dos arquivos: eles duplicam localmente o repositório completo.

Sistema Distribuídos de Versão (DVCS)

Desta maneira, se qualquer servidor morrer, e diversas pessoas estiverem colaborando por meio de um sistema distribuído de controle de versão, qualquer um dos repositórios de clientes podem ser copiado de volta para o servidor para restaurá-lo.

Sistema Distribuídos de Versão (DVCS)

Podemos afirmar que cada clone de repositório é, de fato, um backup completo de todos os dados.

Sistema Distribuídos de Versão (DVCS)

Sistema Distribuídos de Versão (DVCS)

Sistema Distribuídos de Versão (DVCS)

Exemplos de DVCSs

Instalando Git

https://git-scm.com/downloads

Instalando Clientes Git

https://git-scm.com/downloads/guis

https://www.sourcetreeapp.com/

Terminal

Windows

iTerm 

Terminator

Git - História

Git é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo.

O Git foi baseado na ferramenta proprietária chamada BitKeeper

Git - História

• Linus criador do Git
• O termo "Git", uma gíria em inglês britânico para cabeça dura, pessoas que acham que sempre têm razão, argumentativas, podendo ser também pessoa desagradável ou estúpida

"Eu sou um desgraçado egocêntrico, então batizo todos os meus projetos com meu nome. Primeiro Linux, agora Git."

— Linus Torvalds

Git - Licença

• O Git é um software livre, distribuído sob os termos da versão 2 da GNU General Public License. Sua manutenção é atualmente supervisionada por Junio Hamano (Engenheiro de software e hacker).

Git - Portabilidade

• O Git foi primariamente desenvolvido para Linux, mas pode ser usado em outros sistemas operacionais baseados no Unix, incluindo o BSD, o Solaris e o Darwin. O Git é extremamente rápido em arquiteturas POSIX como o Linux.
  O Git também roda no Microsoft Windows.

Git - Quem usa?

Git - Estrutura

Todo o controle de versão realizado localmente.

Git - Estrutura

Processo de sincronização entre repositório local e remoto e vice versa.

Git - Estrutura

Utilizado para alternar entre branchs, restaurar arquivos ou recuperar uma versão específica de um arquivo ou commit. 

Git - Estrutura

Git - Vantagens

Sistema de Controle Convencional

• Versões dos arquivos são armazenadas sequencialmente como deltas (Δ)
• Δ representa as diferenças ou modificações incrementais feitas nos arquivos.

Sistema de Controle no Git

• O Git guarda uma versão completa do repositório, mas otimiza o armazenamento armazenando apenas os arquivos que realmente mudaram

Snapshot

• Cada commit (bolinha azul) no Git é, na verdade, um snapshot de todos os arquivos no projeto naquele momento. Assim, cada commit mantém um histórico completo do projeto.

Estratégia

O formato do objeto dos arquivos de repositório do Git usa uma combinação de codificação delta (armazenamento de diferenças de conteúdo)

v1

src/code.py 

Os 3 estados

Conceitos de Git

Atividade 3

1. Siga as instruções no link.
2. Tome nota das dificuldades enfrentadas na atividade.

60 Minutos

O que é Integração Contínua (CI)?

O que é Integração Contínua (CI)?

Entregar continuamente, ou a cada commit

O que é Integração Contínua (CI)?

Integração Contínua geralmente se refere à integração, construção e teste de código dentro do ambiente de desenvolvimento. Entrega Contínua se baseia nisso, lidando com os estágios finais necessários para a implantação da produção.

Martin Fowler

O que não se quer com CI?

O que se quer com CI?

Organização de repositórios

Estratégia e modelos de Branch

Pontos de atenção

Commits com foco em tarefas e simples

Muitas branches atrasam a integração

Branches curtas menor complexidade no merge

Quanto mais branches mais burocracia nas integrações

Mais que a decisão de um é o time que define o seu padrão

Feature Branch

Feature Branch e Pull Request

Git Flow

Git Flow

Evitando branches de vida longa

Feature Flag

Evitando branches de vida longa

Branch Abstraction

Estratégia de merge

Merge

Rebase

Estratégia de merge

Merge

Rebase

Estratégia de merge

Merge

Rebase

O que não pode faltar no CI?

Teste Automatizado

Lento

Rápido

$$$

$

# de testes

• Automação Funcional

Teste Automatizado - TDD

Teste Automatizado - TDD - Benefícios

Teste Automatizado - TDD - Atividade 4

1. Considerando o contexto ao lado crie a estrutura de um projeto python abaixo:

2. Observe que foi criado um script para a entidade produto e outro para criar o teste de produto. 

3. Crie uma classe de teste para produto, e dentro dela um teste que cubra a criação de um Produto contendo nome e preço. Utilize o framework de teste unittest do python.

4. Implemente a classe de Produto e faça o teste passar. 

Teste Automatizado - TDD X BDD

Resumo sobre Teste e CI

Pipeline Automatizada

Pipeline Automatizada

Ferramentas para automação e controle

Ferramentas para área de teste

Pipeline Automatizada

Build rápido -> Feedback Rápido

• Colete as métricas de execução
  • Verifique as fases de análise de código e teste
  • Utilize uma sequência que falhe rápido
  • Verifique a infra do build do sistema
  • Utilize cache
• TEN-Minute Build 
  • O objetivo do Ten-Minute Build é construir automaticamente todo o sistema e executar todos os testes em dez minutos. Os fundadores do XP sugeriram um período de 10 minutos porque se uma equipe tem um build que leva mais tempo do que isso, é menos provável que ele seja executado com frequência, introduzindo assim um tempo maior entre erros.

• Use ferramentas para automatizar o seu build
• Build deve ser independente da IDE
• Tudo que precisa estar no repositório
  (install scripts, env settings, build scripts, config files, database files, code)]
• Estrutura de diretórios bem definidos e conhecidos
• Builds rápidos que falham rápidos (10 minutos)
• Script único que construí para ambientes (parametrizado)
• Comando único de build (botão de build)
• Use build machine (Cl daemon)

Pipeline Automatizada - Resumindo

• De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas.
• Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.

Padrões de Commit

Fonte: https://www.conventionalcommits.org/pt-br/v1.0.0/

• O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

Tipos e descrição

Fonte: https://www.conventionalcommits.org/pt-br/v1.0.0/

feat - Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

docs - Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

Tipos e descrição

Fonte: https://www.conventionalcommits.org/pt-br/v1.0.0/

build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

style - Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código).

Tipos e descrição

Fonte: https://www.conventionalcommits.org/pt-br/v1.0.0/

chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

Tipos e descrição

Fonte: https://www.conventionalcommits.org/pt-br/v1.0.0/

cleanup - Commits do tipo cleanup são utilizados para remover código comentado, trechos desnecessários ou qualquer outra forma de limpeza do código-fonte, visando aprimorar sua legibilidade e manutenibilidade.

raw - Commits do tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parâmetros.

remove - Commits do tipo remove indicam a exclusão de arquivos, diretórios ou funcionalidades obsoletas ou não utilizadas, reduzindo o tamanho e a complexidade do projeto e mantendo-o mais organizado.

Fonte: https://github.com/iuricode/padroes-de-commits

Padrões de emojis 💈

Fonte: https://github.com/iuricode/padroes-de-commits

Padrões de emojis 💈

Padrões de emojis 💈

1. Comita diariamente o seu código na main do projeto?
2. Você possui build e testes que rodam de modo automatizado?
3. Quando existe um erro no build a equipe conserta em + ou - 10 minutos?

Checando integração contínua

O que é Entrega Contínua (CD)?

Release não apenas engenharia

Entrega contínua (Continuous Delivery)

Entrega contínua (Continuous Delivery)

Fonte: https://agilemanifesto.org/iso/ptbr/manifesto.html

Entrega contínua (Continuous Delivery)

Prática de desenvolvimento que garante que o código sempre esteja pronto para ser lançado.

Entrega contínua (Continuous Delivery)

O que é Deploy Contínuo (Continuous Deployment)?

Extensão da entrega contínua, onde cada alteração aprovada é automaticamente implantada em produção.

Deploy Contínuo (Continuous Deploy)

• Todo código que passa nos testes automatizados é automaticamente implantado em produção.
• Elimina a etapa manual de aprovação.
• Necessita de monitoramento contínuo para garantir a estabilidade.

Deploy Contínuo (Continuous Deploy)

Diferença entre Deploy Contínuo e CD

Diferença entre Deploy Contínuo e CD

Deploy e seus problemas

• Gerenciamento manual de ambientes
• Ambientes diferentes de homologação ou produção
• Deploy Manual

Deploy e seus problemas

• Gerenciamento manual de ambientes
• Ambientes diferentes de homologação ou produção
• Deploy Manual
• Deploy apenas no fim de um ciclo

Deploy e seus problemas

• Gerenciamento manual de ambientes
• Ambientes diferentes de homologação ou produção
• Deploy Manual
• Deploy apenas no fim de um ciclo

Deploy e como atuar nos problemas?

• Automatizar os pipelines por ambiente
• Tornar todo o deploy automatizado
• Realizar deploy com frequência durante o ciclo de desenvolvimento.
• Analisar e atualizar com frequência os scripts de infra

Atividade 5

Quizz

• /etc/gitconfig: válido para todos os usuários no sistema e todos os seus repositórios. Se você passar a opção --system para git config, ele lê e escreve neste arquivo.
• ~/.gitconfig ou ~/.config/git/config: Somente para o seu usuário. Você pode fazer o Git ler e escrever neste arquivo passando a opção --global.
• config no diretório Git (ou seja, .git/config) de qualquer repositório que você esteja usando: específico para este repositório.

Configuração Inicial do Git

Perfil

1. Abrir o git bash
2. Criar uma pasta com nome "git"
3. Acessar a pasta "git"

Perfil - Identificando Usuário

Alterando editor padrão

Para windows: https://stackoverflow.com/questions/10564/how-can-i-set-up-an-editor-to-work-with-git-on-windows

Alterando branch padrão

Ficou na dúvida do comando?

1. Criar uma pasta chamada "Project" dentro de nossa pasta git 
2. Acessar a pasta

1. E se quisermos alterar uma configuração apenas para o repositório?

Alterando outras configs do repositório local

caso não esteja no repositório

Versionando

Histórico de commits

Fonte: https://git-scm.com/docs/git-log#Documentation/git-log.txt-emHem

Experimente

Fonte: https://git-scm.com/docs/git-log#_examples

Altere o arquivo README.md conforme abaixo

Fonte: https://git-scm.com/docs/git-add

Fonte: https://git-scm.com/docs/git-commit

Fonte: https://medium.com/@andgomes/os-tr%C3%AAs-tipos-de-reset-aa220658d9b2

1. git reset --mixed (default)

2. git reset --soft

3. git reset --hard

Vamos simular a necessidade de ignorar arquivos que não necessitam ser enviados para o repositório git.

O .gitignore usa padrões globbing para fazer a comparação dos nomes de arquivos. Ex:

• **/logs - Padrão com um asterisco duplo para combinar diretórios em qualquer lugar no repositório.
• *.log - Um asterisco é um curinga que corresponde a zero ou mais caracteres.
• !important.log - Ignora um padrão
• debug[0-9].log - Colchetes podem ser usados para corresponder a um único caractere de um intervalo especificado.

Fonte: https://git-scm.com/docs/gitignore

Fonte: https://git-scm.com/docs/gitignore

Fonte: https://git-scm.com/docs/gitignore

Fonte: https://git-scm.com/docs/git-log

Fonte: https://git-scm.com/docs/git-log

Fonte: https://git-scm.com/docs/git-log

Fonte: https://git-scm.com/docs/git-branch

https://git-scm.com/docs/git-checkout

Fonte: https://git-scm.com/docs/git-branch

Fonte: https://git-scm.com/docs/git-branch

Experimentem:

1. Crie uma branch chamada "funcionalidade1"
2. Faça 2 commits na branch "funcionalidade1" com novos arquivos
3. Retorne a branch master
4. Liste os arquivos contidos no repositório
5. O que ocorreu?

Fonte: https://git-scm.com/docs/git-merge

Juntar dois ou mais históricos de desenvolvimento