Gerência de configuração ágil, Engenharia de Software, UnB, 2018

1. 1
ENGENHARIA DE SOFTWARE - AULA 04
GERÊNCIA DE CONFIGURAÇÃO
(+VERSIONAMENTO, GIT, GITHUB)
PROF. DRA. CLAUDIA MELO
26/Mar/2018
@claudia_melo claudiamelo.org

2. GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE (GCS): O QUE É?
•É um conjunto de atividades projetadas para gerir
modificações, identificando os produtos de trabalho que
podem ser modificados, estabelecendo relacionamentos entre
eles, definindo mecanismos para administrar as diferentes
versões desses produtos de trabalho, controlando as
modificações impostas e fazendo auditoria, e preparando
relatórios sobre as modificações efetuadas.
•CM ou SCM (Configuration Management ou Software
Configuration Management)
2

3. GCS: O QUE É? (2)
•Gerenciamento de versão
•Acompanhar as várias versões dos componentes do sistema e garantir que as alterações feitas
nos componentes por diferentes desenvolvedores não interfiram entre si.
•Build de sistema
•O processo de montar componentes, dados e bibliotecas de programas, compilando-os para criar
um sistema executável.
•Gestão de mudança
•Acompanhar solicitações de alterações no software de clientes e desenvolvedores, calcular os
custos e o impacto das alterações e decidir se as alterações devem ser implementadas.
•Gestão de release
•Preparando o software para liberação externa e mantendo o controle das versões do sistema que
foram liberadas para uso do cliente.
3

4. PADRÕES INTERNACIONAIS SOBRE GCS
•IEEE Std. 828-1998 IEEE Standard for Software Configuration
Management Plans
•ANSI/EIA-649-1998 National Consensus Standard for
Configuration Management
•MIL-STD-973 Military Standard for Configuration
Management[1] (cancelled, but still good reference)
•GEIA Standard 836-2002 Configuration Management Data
Exchange and Interoperability
4

5. NO MUNDO ÁGIL, GERÊNCIA DE CONFIGURAÇÃO É CHAVE
•O desempenho da TI, de acordo com o Puppet
Labs "State of DevOps" report 2014, vem de:
• Código, configuração da aplicação e configuração do
sistema em um sistema de controle de versão.
• Obtenção de alertas de falha dos sistemas de log
(registro) e monitoramento.
• Desenvolvedores realizando merge do código no
trunk do repositório diariamente.
• Equipes de desenvolvimento e operações interagindo.
• Desenvolvedores dividindo grandes funcionalidades
em pequenas mudanças incrementais (forma ágil de
trabalhar!).
5
•Os principais indicadores do
desempenho de TI nesse relatório são:
• Processo de aprovação de alterações
revisado por pares.
• Tudo sob controle de versão.
• Monitoramento proativo.
• Cultura organizacional de alta confiança.
• Relação ganha-ganha entre
desenvolvedoras/es (DEV) e operações
(OPS).
https://puppet.com/resources/whitepaper/2014-state-devops-report

6. TERMINOLOGIA DE GCS
6
Termo Significado
Baseline (Linha de base) Uma linha de base é uma coleção de versões de componentes que
compõem um sistema.
Branching A criação de uma nova linha de código a partir de uma versão existente de
linha de código.
Controle de configuração
(versão)
O processo de assegurar que versões de sistemas e componentes sejam
registradas e mantidas para que as alterações sejam gerenciadas e todas
as versões dos componentes sejam identificadas e armazenadas durante
a vida útil do sistema.
Item de configuração Qualquer coisa associada a um projeto de software (design, código, dados
de teste, documento, hardware, firmware etc.) colocada sob controle de
configuração.
Mainline Uma sequência de linhas de base que representa diferentes versões de um
sistema.

7. TERMINOLOGIA
7
Termo Significado
Merge A criação de uma nova versão de um componente de software,
mesclando versões separadas em diferentes linhas de código.
Release Uma versão de um sistema que foi liberado para uso.
Repositório Um banco de dados compartilhado de versões de componentes de
software e meta-informações sobre alterações nesses componentes.
System building
(Build)
A criação de uma versão do sistema executável compilando e vinculando
as versões apropriadas dos componentes e bibliotecas do sistema.
Versão Uma instância de um item de configuração que difere, de alguma forma,
de outras instâncias desse item.
Workspace Uma área de trabalho privada onde o software pode ser modificado sem
afetar outros desenvolvedores que possam estar usando ou modificando
esse software.

8. SISTEMA DE CONTROLE DE CONFIGURAÇÃO
•Determinação de versão
•Salvar todas essas versão para permitir a gestão
efetiva das entregas do produto e permitir aos
desenvolvedores voltar a versões anteriores.
•Acompanhamento de dependência e gestão
de mudanças
•O repositório gerencia grande quantidade de
relacionamentos entre elementos de dados
armazenados nele.
•Acompanhamento de requisitos
•Fornece a capacidade de acompanhar todos os
componentes e produtos passíveis de entrega de
projeto e construção que resultam de uma
especificação de requisitos específica. 8
• Gestão de configuração
• Acompanha uma série de
configurações representando marcos
do projeto ou versões de produção
específicas.
• Gestão de versão fornece as versões
necessárias e gestão de ligações
guarda trilha de interdependências.
• Pista de auditoria
• estabelece informação adicional sobre
quando, por que e por quem
modificações foram feitas.

9. REPOSITÓRIO X CONTROLE DE VERSÃO
• Qual a diferença do Git e
do Github?
• Git: sistema de controle de
versão
• Github: repositório
compartilhado (cloud-based)
9
https://blogs.carleton.edu/bostonmassacre3d/2017/05/16/introducing-our-git-workflow/

10. CONTROLE DE VERSÃO - MODELO DISTRIBUÍDO
10

11. CONTROLE DE VERSÃO - MODELO DISTRIBUÍDO
•Um repositório “master" (ou trunk) é criado em um servidor que mantém o código
produzido pela equipe de desenvolvimento.
•O/A desenvolvedor/a cria um clone do repositório do projeto que é baixado e
instalado em seu computador.
•Desenvolvedora/es trabalham nos arquivos necessários e mantêm novas versões
em seus repositórios privados em seus computadores.
•Quando as alterações são feitas, elas/es dão um "commit" dessas alterações e
atualizam o repositório do servidor privado.
•Eles podem depois fazer um "push" dessas mudanças para o repositório do projeto.
11

12. CONTROLE DE VERSÃO - BRANCHING E MERGING
•Pode haver várias sequências independentes de versões que refletem alterações em um componente ao longo do tempo.
•Isso é normal no desenvolvimento do sistema, onde diferentes desenvolvedores trabalham independentemente em
diferentes versões do código.
•Em algum momento, pode ser necessário mesclar ramificações (branches) para criar uma nova versão de um componente
que inclua todas as alterações feitas.
•Se as alterações feitas envolverem partes diferentes do código, as versões do componente podem ser mescladas
automaticamente combinando os "deltas" que se aplicam ao código.
12

13. BUILD DO SISTEMA
•A construção do sistema é o processo de criar um sistema executável
completo, compilando e vinculando os componentes do sistema,
bibliotecas externas, arquivos de configuração etc.
•Ferramentas de build de sistema e ferramentas de gerenciamento de
versão devem se comunicar.
• O processo de build baseia-se em certa versão do repositório gerenciado pelo
sistema de gerenciamento de versões.
•A descrição da configuração usada para identificar uma linha de base
também é usada pela ferramenta de build do sistema.
13

14. BUILD DO SISTEMA
14
Automated
build system
Source
code files
Data files
Libraries
Configuration
files
Executable
tests
Executable
target system
Test resultsCompilers
and tools

15. BUILD EM AGILE: INTEGRAÇÃO CONTÍNUA
•Uma das práticas mais importantes do
desenvolvimento ágil!
•Agilizar tarefas demoradas como a
compilação de um projeto e a execução
dos seus testes automatizados.
•Tarefas são executadas a cada
mudança no repositório de código e,
em caso de erros de compilação ou
falhas nos testes automatizados, todos
os desenvolvedores são alertados
rapidamente.
15https://developers.redhat.com/blog/2017/09/06/continuous-integration-a-typical-process/

16. 16
ESTILOS DE
DESENVOLVIMENTO
DISTRIBUÍDO

17. GIT FLOW
17https://www.toptal.com/software/traunk-based-development-git-flow
• Há uma ramificação de desenvolvimento principal
com acesso restrito. Muitas vezes é chamado de
branch de desenvolvimento.
• Os desenvolvedores criam feature branches a partir
desse ramo principal e trabalham nelas. Depois que
eles terminam, eles criam pull requests.
• Em pull requests, outros desenvolvedores comentam
sobre mudanças e podem ter discussões, muitas
vezes longas.
• Demora algum tempo para concordar com uma
versão final das alterações. Depois de acordado, o
pull request é aceito e mesclada ao branch de
desenvolvimento.
• Uma vez que a branch de desenvolvimento tenha
atingido maturidade suficiente para ser liberada,
uma branch separada é criada para preparar uma
release.

18. GIT FLOW
18https://www.toptal.com/software/trunk-based-development-git-flow
• Essa versão (release branch) é testada e as correções
de bugs são aplicadas até o momento em que ele
está pronto para ser publicado para os usuários
finais.
• Feito isso, mescla-se a versão ao ramo mestre
(master branch), que é marcada com a versão de
release.
• Enquanto isso, novos recursos podem ser
desenvolvidos na branch de desenvolvimento.

19. MAINLINE MODEL
19https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• O desenvolvimento de certa funcionalidade
acontece em uma branch aberta a partir da
mainline.
• A versão de release é anotada na branch de
desenvolvimento.
• Quando uma release é definida, ocorre um grande
merge da versão criada com o código da mainline.
• A integração das funcionalidades desenvolvidas em
diferentes branches ocorre tanto na mainline quanto
na própria branch de desenvolvimento.
• Modelo herdado dos primórdios da GCS, não é bem-
visto hoje.

20. TRUNK-BASED DEVELOPMENT (TBD)
20https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• Todos os desenvolvedores (para uma determinada
funcionalidade implantável) realizam commits na
linha principal (trunk).
• DEVs podem, em suas próprias estações de trabalho,
fazer alguns desenvolvimentos multi-branch
(digamos, com o Git), mas quando eles são “feitos”
com uma mudança ou uma correção de bug, ele
deve voltar para o trunk compartilhado.
• DEVs não fazem commit de código que quebre o
build do código que está no trunk
• rollback/revert quando isso ocorrer OU
• pode ser usada estratégia de pré-commit para
ajudar nessa disciplina
• DEVs não trabalham isolados por dias em branches
locais - atualização frequente (+ que diária)

21. TRUNK-BASED DEVELOPMENT (TBD)
21https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• Branches são feitos para uma release.
• Desenvolvedores não podem fazer branches nesse local
compartilhado. Somente engenheiros de release se
comprometem com essas ramificações e, de fato, criam
cada branch de release.
• Eles também podem selecionar alguns commits
específicos (cherry-pick: conveniência e importância) e
fazer um merge na branch.
• Depois que uma release for substituída por outra, a
ramificação provavelmente será excluída.
• TBD significa que desenvolvedores regulares não realizam commit em uma branch de release.
• TBD significa que você excluirá branches de versão "antigas", sem mesclá-las de volta ao trunk.

22. TRUNK-BASED DEVELOPMENT (TBD)
22https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• TBD significa que desenvolvedores regulares não
realizam commit em uma branch de release.
• TBD significa que você excluirá branches de versão
"antigas", sem mesclá-las de volta ao trunk.

23. EM QUE SITUAÇÕES OS MODELOS FUNCIONAM MELHOR?
• Projetos open-source
• Muitos desenvolvedores júnior
• Quando o produto já está bem estabelecido
Git flow • Quando estamos iniciando um projeto/
produto
• Quando é necessário iterar rapidamente
• Quando o time é formado de mais DEVs
sênior
Trunk-based

24. LEIA MAIS, ESTUDE, EXPLORE
24https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• Manual completo em português do Git: https://git-scm.com/book/pt-br/v1/
• 15 minutos aprendendo git: https://try.github.io/levels/1/challenges/1
• Tutorial desenvolvido por seus colegas da FGA: https://github.com/fga-gpp-mds/A-Disciplina/wiki/Git
• Comandos extra do git: https://github.com/tj/git-extras/blob/master/Commands.md
• CONFIGURATION MANAGEMENT CAMP
• http://cfgmgmtcamp.eu/
• vários vídeos disponíveis, evento anual
Paul Hammant. Trunk Based Development in the Enterprise - Its Relevance and Economics
https://www.slideshare.net/perforce/trunk-based-development-in-the-enterprise-its-relevance-and-economics

25. CLAUDIA MELOPEOPLE TECHNOLOGY RESEARCHER
@claudia_melo
claudiamelo.org @claudiameloblog
/claudiamelo