O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Gerência de configuração ágil

205 visualizações

Publicada em

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

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Gerência de configuração ágil

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. CONTROLE DE VERSÃO - MODELO DISTRIBUÍDO 10
  11. 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. 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. 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. 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. 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. 16 ESTILOS DE DESENVOLVIMENTO DISTRIBUÍDO
  17. 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. 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. 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. 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. 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. 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. 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. 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. 25. CLAUDIA MELOPEOPLE TECHNOLOGY RESEARCHER @claudia_melo claudiamelo.org @claudiameloblog /claudiamelo

×