Gestão de Configurações II

Transcrição

1 Gestão de Configurações II

2 Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14

3 Padrões de Gestão Os padrões de gestão de configurações são úteis pois: Consideram como as pessoas trabalham para além dos mecanismos de como se constrói o código Envolvem processos de construção e os artefactos resultantes Pequenas alterações na forma como se faz a gestão de configurações pode melhorar em muito o processo... Gestão de Projecto 15

4 Padrões Gestão de Projecto 16

5 Padrões Sequência de código Sequência principal Sequência activa Política da sequência Versões privadas Sequência da entrega Sequência de preparação para entrega Ramo por tarefa Espaço de trabalho Espaço de trabalho privado Repositório Construção privada do sistema Construção de integração Sequência de terceiros Confirmação de nível tarefa Teste de despistagem Teste de unidade Teste de regressão Gestão de Projecto 17

6 Sequência Principal Denominada Main Line ou HEAD Contexto Desenvolvimento de software por várias pessoas em paralelo A ferramenta de controlo de versões suporta ramos e integrações Gestão de Projecto 18

7 Sequência Principal Problema Como manter o número de sequências de código activas em número pequeno de forma a facilitar a gestão, sem a árvore de versões do projecto ficar demasiado larga e densa? Como se minimiza o esforço adicional de fazer integrações? Gestão de Projecto 19

8 Sequência Principal Criar ramos é um mecanismo para isolarmos-nos de e/ou isolarmos alterações Integração pode ser difícil devido aos conflitos de alterações podendo exigir a presença de todos os intervenientes A dificuldade de integração aumenta com a duração entre integrações Gestão de Projecto 20

9 Sequência Principal Solução Simplificar o modelo de ramos Quando se está a desenvolver uma única versão do produto deve-se trabalhar numa sequência principal Uma sequência principal é a sequência onde é feito todo o desenvolvimento, excepto em circunstâncias especiais Quando se pretende criar um ramo deve-se pensar na estratégia global antes de o criar Se houver dúvidas, escolher o modelo mais simples Gestão de Projecto 21

10 Sequência Principal A sequência principal funciona como a base de ramos e integrações resultantes evitar modelos em escada O desenvolvimento na sequência principal tem as seguintes vantagens: Reduz integrações e sincronizações Permite que as alterações sejam imediatamente visíveis Gestão de Projecto 22

11 Sequência Principal Deve-se criar ramos quando: Versões para o cliente em que já se está a fazer depuração isolam a versão a entregar ao cliente de novas funcionalidades Tarefas de longa duração em que várias pessoas estão envolvidas Gestão de Projecto 23

12 Sequência Principal Aspectos por resolver Como manter a sequência principal usável quando muitas pessoas estão a trabalhar nela? Gestão de Projecto 24

13 Sequência Activa Contexto O desenvolvimento de uma nova versão do produto está a ser feito numa sequência principal O código está a ser alterado por muitas pessoas As alterações podem corromper o sistema e/ou podem ocorrer conflitos entre alterações Gestão de Projecto 25

14 Sequência Activa Problema Como manter uma sequência de código que evolui rapidamente num estado suficientemente estável para que seja útil? Gestão de Projecto 26

15 Sequência Activa Pretende-se que a equipa trabalhe em paralelo Uma sequência de código com erros atrasa o desenvolvimento Situações de impasse podem ocorrer se não forem criados pontos de sincronização Testes podem ser demorados e provocar atrasos Testes podem não ser conclusivos Gestão de Projecto 27

16 Sequência Activa Solução Estabelecer políticas que tornem a sequência de código principal suficientemente estável para o trabalho que é necessário Não procurar uma sequência de desenvolvimento activa perfeita, mas sim uma sequência principal que é usável e suficientemente activa para as necessidades Gestão de Projecto 28

17 Sequência Activa O que é difícil é perceber quão boa deve ser a sequência de código: Quem usa a sequência de código? Que percentagem do sistema está a evoluir? Qual é o ciclo de entrega? Que mecanismos de testes temos disponíveis? Qual é o preço de um ciclo em que a sequência de código fica corrompida? Gestão de Projecto 29

18 Sequência Activa Aspectos por resolver Uma política da sequência deve estabelecer como deve ser o processo de confirmação da sequência Os programadores devem usar um espaço de trabalho privado para isolar alterações e manter a sequência activa Uma sequência de preparação para entrega deve ser criada se se procura estabilidade Criar um ramo para tarefas de longa duração Gestão de Projecto 30

19 Padrões de Espaço de Trabalho Gestão de Projecto 31

20 Bibliografia A Visual Guide to Version Control Distributed Version Control /03/17.html Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 32

21 Espaço de Trabalho Privado Contexto Está-se a trabalhar numa sequência activa Pretende-se trabalhar com o código mais actualizado Pretende-se controlar quando se começa a trabalhar com as alterações que os outros entretanto fizeram Gestão de Projecto 33

22 Espaço de Trabalho Privado Problema Como se manter actualizado com as alterações mais recentes do código mas sem sofrer alterações não controladas do ambiente de trabalho, de forma a poder progredir? Gestão de Projecto 34

23 Espaço de Trabalho Privado O desenvolvimento no contexto de uma equipa envolve os seguintes passos: Escrever e testar as nossas alterações ao código Integrar o nosso código com o trabalho das outras pessoas A integração pode ser: Contínua Diferida Gestão de Projecto 35

24 Espaço de Trabalho Privado Solução Fazer o trabalho num espaço privado onde se pode controlar as versões do código com que se está a trabalhar Gestão de Projecto 36

25 Espaço de Trabalho Privado Um espaço de trabalho contém o seguinte: Código que se está a editar Componentes construídos localmente Objectos de terceiros que não se pretende construir Configuração e dados necessários para executar e testar o sistema Scripts de construção do sistema neste espaço de trabalho Informação identificando as versões de todos os componentes do sistema Gestão de Projecto 37

26 Espaço de Trabalho Privado Um espaço de trabalho não deve conter o seguinte: Scripts privados genéricos de construção do sistema Ferramentas e compiladores que são os mesmos para todas as versões do produto Gestão de Projecto 38

27 Espaço de Trabalho Privado O seguinte procedimento deve ser seguido: 1. Obter os dados mais recentes da sequência activa 2. Fazer alterações 3. Fazer uma Construção Privada do Sistema 4. Testar as alterações com Testes de Unidade 5. Actualizar o espaço de trabalho com a versão mais recente dos componentes na sequência activa 6. Construir o sistema e executar Testes de Despistagem para garantir que não se corrompeu nada Gestão de Projecto 39

28 Espaço de Trabalho Privado Aspectos por resolver Uma Construção Privada do Sistema evita que se introduzam erros quando se fazem confirmações É necessário carregar o espaço de trabalho de um Repositório Componentes externos devem vir de uma Sequência de Terceiros Uma vez que o trabalho isolado está terminado é necessário integrar com o resto do sistema fazendo uma Construção de Integração Gestão de Projecto 40

29 Repositório Contexto Para criar um Espaço de Trabalho Privado ou para executar uma Construção de Integração é necessário obter os componentes certos Problema Como obter as versões correctas dos componentes certos num espaço de trabalho? Gestão de Projecto 41

30 Repositório Solução Ter um único ponto de acesso, ou repositório, para o código e outros artefactos relacionados Fazer com que criar um espaço de trabalho seja o mais simples e transparente possível Gestão de Projecto 42

31 Repositório Uma forma simples de implementar este padrão é colocar todo o código fonte, ficheiros de configuração, scripts de construção e componentes de terceiras partes no sistema de controlo de versões Aspectos por resolver Organizar o código de terceiras partes numa Sequência de Terceiros Gestão de Projecto 43

32 Construção Privada do Sistema Contexto As alterações feitas no Espaço de Trabalho Privado devem funcionar com o restante sistema Problema Como se verifica, antes de se confirmar as alterações, que as nossas alterações não vão corromper o sistema? Gestão de Projecto 44

33 Construção Privada do Sistema Fazer confirmação de alterações que podem corromper o sistema e fazem perder tempo A construção de pré confirmação pode funcionar bem mas a construção da noite falha A depuração feita a partir do nosso ambiente de desenvolvimento dá mais pistas do que a que é feita a partir do sistema em produção Gestão de Projecto 45

34 Construção Privada do Sistema Solução Antes de confirmar o código deve-se construir o sistema usando uma construção privada similar à construção da noite Gestão de Projecto 46

35 Construção Privada do Sistema A construção privada deve ter as seguintes características: Ser, tanto quanto possível, como a Construção de Integração e as construções do produto Incluir todas as dependências Incluir todos os componentes que dependem da alteração Gestão de Projecto 47

36 Construção Privada do Sistema Pode ser feita uma construção completa ou uma construção incremental Deve ser feita uma construção completa sempre que: Se estão a adicionar novos ficheiros ao sistema de controlo de versões devese começar com um espaço de trabalho vazio Houve alterações profundas de funcionalidade central Gestão de Projecto 48

37 Construção Privada do Sistema Aspectos por resolver Depois de se ter verificado que se consegue construir o sistema deve ser feito um Teste de Despistagem para verificar se a funcionalidade não ficou corrompida Se o sistema é muito grande pode não ser eficiente construir todos os componentes que usam os nossos componentes, sendo isso deixado para a Construção de Integração Gestão de Projecto 49

38 Construção de Integração Contexto Os programadores trabalham separadamente nos seus espaços de trabalho O trabalho deve ser integrado Problema Como garantir que a construção na sequência activa que resulta da integração dos espaços de trabalho é fiável? Gestão de Projecto 50

39 Construção de Integração Alterações em paralelo podem não ser compatíveis Uma construção completa e centralizada pode resolver o problema Solução Garantir que todas as alterações, e suas dependências, são construídas usando um processo de integração central. Deve ser: Reproduzível Similar à construção do produto final Automatizado ou requerendo pouca intervenção Mecanismos de notificação e história Gestão de Projecto 51

40 Construção de Integração Fazer a integração num espaço de trabalho que contenha os componentes a serem integrados Determinar a frequência das construções de integração baseado em: Quanto tempo demora a construir o sistema A frequência de alterações ao sistema Gestão de Projecto 52

41 Construção de Integração Aspectos a resolver Após a construção de integração fazer Teste de Despistagem Se a construção for publicada como uma base estável fazer Teste de Regressão Gestão de Projecto 53

42 Sequência de terceiros Contexto A sequência de código está associada a um conjunto de componentes externos que fazem parte do produto Alguns dos produtos externos podem ter de ser adaptados Pode ser necessário associar versões de componentes externos ao nosso produto Os componentes externos devem ser incluídos no espaço de trabalho Gestão de Projecto 54

43 Sequência de terceiros Problema Qual a estratégia mais eficaz de coordenar as versões de componentes externos com versões do código do produto? Gestão de Projecto 55

44 Sequência de terceiros Os ciclos de versões de entrega de um vendedor são diferentes dos ciclos de versões do nosso produto É necessário identificar que versões do componente externo fazem parte de cada versão do nosso produto Se forem feitas alterações ao componente externo é necessário que essas alterações sejam integradas com as versões futuras Gestão de Projecto 56

45 Sequência de terceiros Solução Criar uma sequência de código para código de terceiros Construir espaços de trabalho e procedimentos de instalação a partir desta sequência de código Gestão de Projecto 57

46 Sequência de terceiros Criar ramos separados para o código da terceiros e para as versões das adaptações a ele feitas Gestão de Projecto 58

47 Alteração de Nível Tarefa Contexto Uma construção de integração é fácil de depurar se soubermos o que podemos retirar até ela funcionar Problema Quanto trabalho deve ser feito entre submissões ao sistema de controlo de versões? Quanto tempo se deve esperar antes confirmar as alterações? Gestão de Projecto 59

48 Alteração de Nível Tarefa Codificar é uma sequência de depuração de erros, melhorias e novas funcionalidades que devem ser registadas Adicionar uma funcionalidade ou corrigir um erro pode levar a muitas alterações no código Deve ser possível recuperar para um estado anterior às alterações se elas corromperem o sistema Gestão de Projecto 60

49 Alteração de Nível Tarefa Quando uma construção de integração falha deve ser possível identificar a alteração que provocou a falha Uma história de alterações de grande granularidade reduz a sobrecarga de confirmações Uma história detalhada de alterações permite uma recuperação selectiva Gestão de Projecto 61

50 Alteração de Nível Tarefa Solução Fazer uma confirmação por cada tarefa consistente de pequena granularidade Cada alteração deve representar um estado coerente do sistema Gestão de Projecto 62

51 Confirmação de Nível Tarefa Aspectos por resolver As alterações que demoram muito tempo e são difíceis de alcançar devem ser feitas num Ramo por Tarefa A existência de testes de unidade, regressão e despistagem permitem motivar confirmações de pequena granularidade Gestão de Projecto 63

52 Teste de Despistagem Contexto A construção de integração e a construção privada do sistema são úteis para verificar aspectos de integração em tempo de construção É necessário verificar aspectos de tempo de execução Problema Como saber que o sistema continua a funcionar após se ter feito uma alteração? Gestão de Projecto 64

53 Teste de Despistagem Podem-se escrever testes que cobrem as partes mais críticas e sujeitas a falhas do sistema, mas é difícil de desenvolver testes completos Correr todos os testes disponíveis pode ser muito demorado Testes que demoram muito a executar levam a que o programador aumente o tempo entre integrações Gestão de Projecto 65

54 Teste de Despistagem Solução Sujeitar cada construção a um teste de despistagem que verifica que o sistema não se corrompeu de uma forma óbvia Os testes de despistagem devem ser automatizados Os testes de despistagem não substituem testes mais exaustivos Não são desculpa para não testar o seu próprio código Gestão de Projecto 66

55 Teste de Despistagem Um teste de despistagem deve: Rápido a executar Indicar automaticamente do seu sucesso ou insucesso Fornecer uma cobertura abrangente do sistema que é o nosso alvo Poder ser executado pelos programadores como parte do processo de garantia de qualidade Gestão de Projecto 67

56 Teste de Despistagem Aspectos por resolver Um teste de despistagem deixa muitos aspectos por testar que devem ser considerados num Teste de Regressão Os programadores devem fazer um Teste de Unidade por cada módulo que necessitam Utilizar Teste de Unidade para verificar que o módulo que se está a alterar continua a funcionar de forma adequada Gestão de Projecto 68

57 Teste de Unidade Contexto Um teste de despistagem não é suficiente para testar uma alteração em detalhe, especialmente quando se está a trabalhar num novo módulo Problema Como testar que um módulo continua a funcionar correctamente após ter sido alterado Gestão de Projecto 69

58 Teste de Unidade Quando um teste de despistagem falha desejamos saber que parte do sistema falhou Desejamos isolar os aspectos de integração das alterações locais Desejamos testar o contrato que cada módulo fornece localmente Gestão de Projecto 70

59 Teste de Unidade Solução Desenvolver e executar testes de unidade Os testes de unidade devem ter as seguintes características: São automáticos e auto avaliam-se Têm pequena granularidade São isolados Simples de executar Gestão de Projecto 71

60 Teste de Unidade Os testes de unidade devem ser executados quando: Se está a codificar Antes de confirmar uma alteração Para encontrar um problema com um teste de despistagem ou de regressão Os testes de unidade devem ser suportados por frameworks como o Junit, CxxUnit, PyUnit, etc Gestão de Projecto 72

61 Padrões de Sequência Gestão de Projecto 73

62 Política da Sequência Contexto Existem diversas sequências de código e os programadores necessitam de saber como trabalhar em cada uma delas Uma Sequência da Entrega deve ter regras muitos restritivas acerca de como e quando se pode alterar Numa Sequência Activa as regras devem ser menos restritivas Gestão de Projecto 74

63 Política da Sequência Problema Como é que os programadores sabem em que sequência de código confirmar o seu código, quando o fazer e que testes devem correr antes de o fazer? Gestão de Projecto 75

64 Política da Sequência Cada sequência de código tem objectivos diferentes Depuração Entrega Portar para outra plataforma Nova versão... Cada sequência tem requisitos de estabilidade diferentes É difícil garantir que os programadores sigam as políticas Gestão de Projecto 76

65 Política da Sequência Solução Para cada sequência de código estabelecer uma política que determina quando e como os programadores podem fazer alterações As políticas devem ser concisas 1 a 3 parágrafos, máximo 1 página auditáveis acessíveis Gestão de Projecto 77

66 Política da Sequência A descrição do objectivo da sequência (3 parágrafos) pode incluir: Tipo de trabalho desenvolvimento, manutenção, versão, função, subsistema Quando e como devem os elementos ser confirmados, checked out, criados ramos ou integrados Restrições de acesso por indivíduo, papel ou grupo Relações com outras sequências Duração do trabalho e quando a sequência deve terminar Carga esperada de actividade e frequência de integração Gestão de Projecto 78

67 Política da Sequência Algumas políticas de sequências Desenvolvimento alterações intermédias ao código devem ser confirmados e os componentes afectados devem ser construídos Entrega o sistema deve ser construído e passar testes de regressão antes da confirmação; as confirmações estão limitados à depuração de erros; não são introduzidas novas funcionalidades; após a confirmação a sequência não sofre alterações até que todo o ciclo de QA termina Principal todos os componentes devem compilar e passar testes de regressão, e novas funcionalidades completamente testadas podem ser confirmadas Gestão de Projecto 79

68 Política da Sequência Aspectos por resolver É necessário utilizar automatização e ter em consideração a cultura da equipa Usar o ANT para fazer cumprir a política Gestão de Projecto 80

69 Versões Privadas Contexto É necessário avaliar rapidamente uma alteração complexa que pode corromper o sistema que está a ser desenvolvido na sequência activa Problema Como se pode experimentar uma alteração complexa, tirando ao mesmo tempo partido do sistema de controlo de versões, sem tornar as alterações públicas? Gestão de Projecto 81

70 Versões Privadas As alterações, mesmo as complexas, são melhor feitas em pequenos passos que podem ser refeitos O processo de alteração pode consistir em experimentar diversas alternativas O sistema de controlo de versões permite criar pontos de recuperação (checkpoint) Trabalhando só no espaço de trabalho privado não permite ter versões Gestão de Projecto 82

71 Versões Privadas Solução Fornecer aos programadores um mecanismo de guardar as alterações a um nível de granularidade com que eles estejam confortáveis Utilizar uma área local de controlo de revisões Apenas o código estável é confirmado no repositório do projecto Gestão de Projecto 83

72 Versões Privadas A área local de controlo de versões pode ser um ramo Deve-se assegurar que os programadores que utilizam a versão privada migram as alterações para o sistema de controlo de versões partilhado em intervalos razoáveis Gestão de Projecto 84

73 Sequência da Entrega Contexto Está-se a fazer desenvolvimento sobre uma sequência activa Foram entregues versões que necessitam de manutenção e pequenas melhorias Pretende-se manter a versão entregue estável Problema Como fazer a manutenção de uma versão entregue sem interferir com o trabalho de desenvolvimento em curso? Gestão de Projecto 85

74 Sequência da Entrega É necessário reparar urgentemente um erro de uma versão em produção e a versão em desenvolvimento não vai estar pronta rapidamente Os utilizadores não querem fazer actualização para uma nova versão O esforço de manutenção da versão entregue pode ser incompatível com alguma da funcionalidade ou refactorização em curso na versão em desenvolvimento Gestão de Projecto 86

75 Sequência da Entrega Solução Separar a versão entregue e a nova versão em diferentes sequências de código Cada versão entregue é uma sequência (sequência da entrega) ramo da sequência principal Na sequência da entrega será feita a manutenção Gestão de Projecto 87

76 Sequência da Entrega Alterações na sequência de entrega são propagadas para a sequência activa com regularidade sempre antes da próxima entrega Correcções de erros na sequência principal devem ser propagados para a sequência de entrega se possível O código da sequência da entrega fica morto quando a versão deixa de ser suportada Gestão de Projecto 88

77 Sequência de Preparação para Entrega Contexto Está-se a terminar uma entrega e é necessário iniciar o desenvolvimento de uma nova versão Problema Como estabilizar o código que se está a preparar para um entrega permitindo contudo que novo trabalho continue na sequência activa Gestão de Projecto 89

78 Sequência de Preparação para Entrega Por vezes o processo de preparação de uma entrega pode-se prolongar devido a vários factores configurações, instalações, erros imprevistos,... Nem toda a equipa necessita de estar envolvida na actividade de preparar a entrega Gestão de Projecto 90

79 Sequência de Preparação para Entrega Solução Criar um ramo de engenharia da entrega quando o código começa a ter a qualidade necessária para a entrega Terminar de preparar a entrega neste ramo enquanto que na sequência activa continua o restante desenvolvimento O ramo torna-se no ramo da entrega O responsável pela sequência activa define a política sobre como e quando as alterações são propagadas da sequência de preparação para a sequência activa Gestão de Projecto 91

80 Sequência de Preparação para Entrega Aspectos por resolver Se poucas pessoas estão a trabalhar na nova versão cria-se um ramo por tarefa para a nova versão Gestão de Projecto 92

81 Ramo por Tarefa Contexto Algumas tarefas de desenvolvimento demoram muito tempo e os seus passos intermédios geram muita instabilidade Problema Como pode uma equipa fazer múltiplas alterações, e de longa duração, a uma sequência de código, sem comprometer a sua consistência e integridade Gestão de Projecto 93

82 Ramo por Tarefa Integrações frequentes são importantes para se ter estabilidade global Pretende-se colocar as alterações no sistema de controlo de versões para se ter rastreabilidade e recuperação Algumas alterações desestabilizam a sequência de código Gestão de Projecto 94

83 Ramo por Tarefa Solução Criar um ramo separado para cada actividade que traz alterações significativas a uma sequência de código Gestão de Projecto 95

84 Ramo por Tarefa Um ramo por tarefa é um mecanismo para isolar fisicamente actividades de risco do código base Deve-se integrar frequentemente as alterações da sequência activa com o ramo Gestão de Projecto 96

85 Estabilidade vs Progresso Qualidade é essencial e seguem-se os procedimentos, uma entrega de cada vez, reduzindo a produtividade e possivelmente deixando os programadores frustrados A rapidez de desenvolvimento é essencial e a qualidade e gestão de versões fica para depois Gestão de Projecto 97