Gerência de Configuração Boa tarde a todos, Meu nome é XXXX e estarei apresentando a vocês alguns conceitos sobre Gerência de Configuração no decorrer desta semana. Como vêem, a ênfase principal da G.C. é o controle de modificações sobre os elementos de um software (códigos scripts, componentes terceirizados e documentos do sistema). Esta definição foca somente nas modificações do sistema, deixando de lado questões importantes como a influencia da organização no processo a ser seguido. Introdução
Módulos 1. Introdução 2. Padrões GC 3. Disciplina de GC e Ambiente 4. Controle de Mudanças 5. Sistemas de Controle de Versão 4. Integração Contínua 6. Sistemas de Controle de Mudanças Introdução
Gerência de Configuração Introdução Introdução
Objetivos Fornecer os principais conceitos relacionados a GC Criar uma visão geral de como GC pode ser aplicada ao seu projeto Introdução
Pré-requisitos Noções de Engenharia de Software Introdução
Motivação Problemas na manutenção de software: bugs previamente corrigidos que reaparecem Features já testadas que somem repentinamente Um programa que deixa de funcionar Estes são problemas frustrantes provenientes da falta de gerência de configuração Podemos adicionar aqui: Ambientes que funcionam somente para parte dos desenvolvedores; Descontrole sobre o que deve ser empacotado no ultimo release do sistema Erros que ocorrem em produção não podem ser reproduzidos em desenvolvimento Problemas de coordenação do trabalho concorrente dos desenvolvedores Introdução
Outros problemas Ambientes que funcionam somente para parte dos desenvolvedores; Descontrole sobre o que deve ser empacotado no ultimo release do sistema Erros que ocorrem em produção não podem ser reproduzidos em desenvolvimento Problemas de coordenação do trabalho concorrente dos desenvolvedores Introdução
Problema da Quebra de Comunicação Desenvolvedor A Desenvolvedor B Desenvolvedor C - Mesmo sabendo da importancia de G.C. para controlar mudancas no desenvolvimento. Este controle se torna ainda mais importante no desenvolvimento em paralelo. Introdução
Problema da Quebra de Comunicação (continuação) Falhas de comunicação em equipes Ocorre pelas mais diversas razões: Vocabulários incompatíveis Culturas de desenvolvimento diferentes Distância geográfica Dificuldade de expressão Quando este problema acontece: Os sistemas produzidos não atendem aos requisitos Força de trabalho é desperdiçada Introdução
Problema dos Dados Compartilhados Desenvolvedor A Desenvolvedor B Programa de A Programa de B Componente Compartilhado O Problema dos Dados Compartilhados é extremamente comum em qualquer ambiente no qual dois ou mais desenvolvedores compartilham um recurso. Por exemplo, se o recurso compartilhado for um componente de software, o problema poderá ocorrer sempre que um desenvolvedor A modificar o componente compartilhado e esquecer de avisar aos outros (uma instância do problema da falha de comunicação). Da próxima vez que um dos outros desenvolvedores for trabalhar no componente, este não estará no estado esperado. Se, por exemplo, ele fizer uma alteração no componente e essa alteração afetar a parte que foi modificada por A, um erro poderá ocorrer. Por não saber da modificação feita por A, o desenvolvedor estará completamente no escuro com relação à causa do problema. A1 A2 A3 B1 B2 B3 Introdução
Problema dos Dados Compartilhados - Cenário O desenvolvedor A modifica o componente compartilhado Mais tarde, o desenvolvedor B realiza algumas alterações no mesmo Ao tentar compilar o componente, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou O desenvolvedor B não tem a menor idéia sobre a causa do problema Este problema é ainda mais sério em grandes equipes: - Quem foi responsável por isto ? Introdução
Problema dos Dados Compartilhados - Solução simplista cada desenvolvedor trabalha em uma cópia “local” do componente resolve o Problema dos Dados Compartilhados, mas cria um novo problema Introdução
Problema da Manutenção Múltipla Desenvolvedor A Desenvolvedor B Programa de A Programa de B Componente Compartilhado Componente Compartilhado Componente Compartilhado Componente Compartilhado A1 A2 A3 B1 B2 B3 Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado O Problema da Manutenção Múltipla acontece quando os membros de uma equipe precisam modificar um mesmo recurso (no exemplo, novamente um componente de software) mas, ao invés compartilhá-lo, cada um mantém uma cópia “local” para que as modificações realizadas por um desenvolvedor não afetem o desenvolvimento do outro. O problema fica evidente quando é necessário saber qual a versão mais “atualizada” do componente. Um desenvolvedor A pode ter detectado um defeito que não foi percebido por outro desenvolvedor, B. Ao mesmo tempo, B pode ter implementado uma funcionalidade que A não implementou. Qual versão do componente deve ser utilizada? A de A ou a de B? A situação torna-se mais crítica, quão maior for o tamanho da equipe. Introdução
Problema da Manutenção Múltipla (continuação) Ocorre quando cada desenvolvedor trabalha com uma cópia “local” do que seria o mesmo componente Dificuldade para saber: Que funcionalidades foram implementadas em quais versões do componente Que defeitos foram corrigidos Evitado através de uma biblioteca central de componentes compartilhados Nesse esquema, cada componente é copiado para a biblioteca sempre que alterado Resolve o Problema da Manutenção Múltipla, mas... Introdução
Problema da Atualização Simultânea Biblioteca Central de Recursos Compartilhados Desenvolvedor A Desenvolvedor B Componente Compartilhado Programa de A Programa de B Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado O Problema da Atualização Simultânea acontece quando os membros de uma equipe precisam modificar um mesmo recurso (no exemplo, novamente um componente de software) e cada um trabalha em uma cópia local do componente mas, sempre que uma modificação no componente é realizada, ele é copiado para uma biblioteca central de componentes compartilhados. Nessa biblioteca deve sempre estar disponível a versão mais nova do componente. O problema com esse esquema é que quando dois desenvolvedores A e B pegam a mesma versão V1 do componente compartilhado para trabalhar localmente, se A terminar suas modificações e copiar a nova versão do componente para a biblioteca mas não avisar a B, da próxima vez que B copiar a sua versão modificada para a biblioteca o trabalho de A estará perdido, uma vez que B alterou a versão V1 e não levou em consideração as modificações feitas por A. A1 A2 A3 B1 B2 B3 Introdução
Problema da Atualização Simultânea – Cenário 1: O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige o mesmo defeito em sua versão do componente por não saber que A já tinha feito isso O trabalho de A é desperdiçado Introdução
Problema da Atualização Simultânea – Cenário 2: O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige um outro defeito em sua versão do componente, sem saber do defeito corrigido por A O desenvolvedor B copia sua versão do componente para a biblioteca central Além de o trabalho de A ser desperdiçado, a versão do componente que se encontra na biblioteca central continua apresentando um defeito O desenvolvedor A julga o problema como resolvido Introdução
Como Resolver? O problema da atualização simultânea não pode ser resolvido simplesmente copiando componentes compartilhados para uma biblioteca central Algum mecanismo de controle é necessário para gerenciar a entrada e saída dos componentes Introdução
Sobre Gerência de Configuração “Em qualquer time, um certo grau de confusão é inevitável. O objetivo é minimizar a confusão de modo que mais trabalho possa ser feito.” “A arte de coordenar o desenvolvimento de software para minimizar esse tipo particular de confusão é chamada de Gerência de Configuração.” W.A. Babich Introdução
O que é Gerência de Configuração? Gerência de configuração (GC) é o processo de identificar, organizar e controlar modificações ao software sendo construído A idéia é maximizar a produtividade minimizando os enganos Introdução
Objetivos de GC Definir o ambiente de desenvolvimento Políticas para controle de versões garantindo a consistência dos artefatos produzidos Definir procedimentos para solicitações de mudanças Administrar o ambiente e auditar mudanças Facilitar a integração das partes do sistema Introdução
Benefícios Aumento de produtividade no desenvolvimento Menores Custos de Manutenção Redução de defeitos Maior rapidez na identificação e correção de problemas Introdução
Conceitos Básicos Introdução
Configuração do Software Um projeto de desenvolvimento de software produz os seguintes itens: Programas (código fonte, programas executáveis, bibliotecas de componentes, etc.) Documentação (manuais do usuário, documento de requisitos, modelo de análise e projeto, etc.) Dados (dados de teste e do projeto) Esses conjuntos de itens são chamados, coletivamente, de configuração do software A configuração do software traz também relacionamentos entre os seus itens, como: Faz parte Depende Estes relacionamentos são extrema importância para se identificar o impacto das mudanças de um item nos itens restantes do sistema. Workspace != Configuração do Software !!! Um workspace é um local onde o desenvolvedor possui todos os artefatos necessários para que ele execute uma tarefa. Alguns Workspaces podem ser gerenciados por uma IDE. Um desenvolvedor pode ter vários workspaces. Introdução
Workspace Todos os artefatos necessários para a execução de uma tarefa O desenvolvedor pode ter exercer várias tarefas, e ter consequentemente vários workspaces Podem ser gerenciados por uma IDE. A configuração do software pode ser composta por vários workspaces Introdução
Item de Configuração Um conjunto de itens de hardware e/ou software vistos como uma entidade única para fins de gerência de configuração Um item de configuração está sujeito a mudanças e essas devem obedecer às políticas estabelecidas Normalmente, um item de configuração é estabelecido para cada pedaço de software que pode ser projetado, implementado e testado de forma independente Na literatura, é comum o termo “item de configuração” ser definido como “um programa e sua documentação associada”. Apesar de simplificada, essa definição captura bem a idéia de que um item de configuração é um conjunto de artefatos visto como uma entidade única, para fim de gerência de configuração. Freqüentemente, quando se modifica algo em um programa, sua documentação tem que ser atualizada para refletir as mudanças. É muito importante, porém, ressaltar: um item de configuração não é necessariamente um programa. Pode ser um documento, um arquivo de propriedades, dados ou qualquer artefato que só possa ser modificado de acordo com as políticas de gerência de configuração. Introdução
Configuração de Software item fluxo tempo Introdução
Codeline Uma codeline contem todas a versões de cada artefato sobre um ramo evolucionário do sistema Codelines armazenam todas as mudanças R1 R2 R1 R2 V1 V2 V3 Introdução
Baseline Uma especificação ou produto que foi formalmente revisado e aceito Serve como base para os passos posteriores do desenvolvimento A configuração do software em um ponto discreto no tempo Só pode ser modificado através de procedimentos formais (solicitações de mudança) Um artefato ou conjunto de artefatos só se torna um item de configuração depois que um baseline é estabelecido Baseline != codeline (linha de desenvolvimento) Uma codeline pode armazenar todas as mudanças, não somente aquelas aprovadas (baseline). Uma codeline possui várias versoes “conceituais” que nem sempre precisam ser identificadas. Versões importantes, e aprovadas são incorporadas na baseline. Introdução
Baseline e Codelines fluxo item baseline tempo codeline Introdução
Razões para Criar um Baseline Reproducibilidade – a habilidade de reproduzir uma versão anterior do sistema Rastreabilidade – Estabelece uma relação predecessor-sucessor entre artefatos do projeto (projeto satisfaz requisitos, código implementa projeto, etc.) Geração de Relatórios – A comparação dos conteúdos de dois baselines ajuda na depuração e criação de documentação Controle de Mudanças – referencial para comparações, discussões e negociações Há diversas vantagens em criar baselines: Um baseline provê um ponto estável e uma visão dos artefatos de desenvolvimento em um ponto discreto do tempo. Baselines provêm um ponto estável a partir do qual novos projetos podem ser criados. Desenvolvedores individuais podem pegar componentes para os quais baselines foram estabelecidos para servir como base para atualizações em suas áreas de trabalho individuais. Um baseline fornece uma maneira de voltar atrás nas mudanças, caso elas sejam consideradas suspeitas ou instáveis. Um baseline fornece uma maneira de reproduzir defeitos reportados, dado que se pode recriar a configuração quando um release foi construído. Introdução
Baselines importantes Baselines são considerados marcos no processo de desenvolvimento: Funcional : requisitos De Produto : releases, iterações Funcional: é o primeiro baseline. Consiste de um documento de requisitos (DR) aprovado, contendo todos os requisitos, funcionais e não-funcionais, associados a um determinado item de configuração. O processo formal de gerência de mudanças é iniciado quando este baseline é estabelecido. Alocado: É alcançado ao fim da fase de projeto. Consiste de todos os artefatos (diagramas, modelo de dados, descrições dos casos de uso, etc.) produzidos para um item de configuração. O nome “alocado” deriva da idéia de as funcionalidades definidas no documento de requisitos estarem alocadas aos componentes e sub-sistemas, quando este baseline é atingido. De Produto: O conjunto de todos os artefatos produzidos pelo processo de desenvolvimento (código fonte, código objeto, documentação, dados, arquivos de configuração, etc). Introdução
Repositório Local (físico e lógico) onde os itens de um sistema são guardados Pode conter diversas versões do sistema Utiliza mecanismos de controle de acesso Desenvolvedor Repositório Introdução
Lock Resolve a Atualização Simultânea Garante que apenas o usuário que detém o lock pode alterar o arquivo Problema: “serializa” o trabalho dos desenvolvedores Hoje, a uma tendência em se utilizar notificadores para se avisar que documentos estão sendo atualizados simultaneamente. Introdução
Check-Out Check-out cliente Repositório Introdução
Check-Out (continuação) Recuperar a (última) versão de um item de configuração guardada no repositório Escrita Verifica que ninguém detém o lock do item de configuração Obtém o lock do item Cria uma cópia, para edição, no cliente Leitura Verifica que alguém já detém o lock Cria uma cópia, apenas para leitura, no cliente Introdução
Check-In Check-in cliente Repositório Introdução
Check-In (continuação) Ação de inserir/atualizar um item de configuração no repositório Verifica o lock do item de configuração, caso o mesmo já exista Verifica e incrementa a versão do item Registra informações das mudanças (autor, data, hora, comentários) Inclui/atualiza o item Introdução
Tags Rótulos que são associados a conjuntos de arquivos Um tag referencia um ou mais arquivos em um ou mais diretórios Costuma-se usar tags para: Denominar projeto rotulando todos os arquivos associados ao projeto Denominar uma da versão do projeto (um build ou release) rotulando todos os arquivos associados ao build ou release Ou Label Introdução
Histórico de um arquivo Tags 1.1 1.2 1.3 1.4 release_1 release_2 Histórico de um arquivo tag Introdução
Branch Criação de um fluxo alternativo para atualização de versões de itens de configuração Recurso muito poderoso Regras bem definidas para criação de branches Por que e quando devem ser criados? Quais os passos? Quando retornar ao fluxo principal? Por que e quando devem ser criados: em que circunstâncias é justificável criar um novo branch? Apenas para correção de bugs? Para realizar melhorias solicitadas pelos usuários? Quais os passos: que procedimentos devem ser seguidos para criar um branch? Deve ser feita uma solicitação formal? Um backup do item de configuração deve ser realizado? Algum membro da equipe deve ser notificado? Quando retornar ao fluxo principal: quando pode se considerar o branch como encerrado? Isso depende da razão pela qual ele foi criado. Se foi para remover defeitos, o branch deve acabar assim que esses defeitos tenham sido corrigidos, ou deve ser mantido para corrigir novos defeitos que foram descobertos? Introdução
Branch (continuação) Uso de lock inviabiliza a criação de branches Branches normalmente se originam de correções em versões anteriores Introdução
Branch (exemplo) 3.m.1 3.m.2 3.m.3 1 hello.c 2 3 hello.h José Maria 4 5 6 • 3 4 • 3.j.1 3.j.2 3.j.3 Note que um branch geralmente adiciona um um número de versão menor (*.1) para identificar de qual linha de desenvolvimento ele se origina. Geralmente se deseja realizar um branch de um conjunto de arquivos. Neste caso, esse conjunto será desviado em uma outra linha de desenvolvimento como uma unidade. 2.j.1 2.j.2 Introdução
Merge Unificação de diferentes versões de um mesmo item de configuração Integração itens de configuração de um branch com os itens de configuração do fluxo principal Check-out atualizando a área local Algumas ferramentas fornecem um mecanismo automático para realização de merges Mesmo com o uso de ferramentas, em vários casos há necessidade de intervenção humana Um merge pode ser automatizado através de ferramentas que identificam mudanças textuais entre arquivos, mas você precisa sempre entender as intenções da mudança realizada para garantir que o merge será realizado corretamente. Introdução
Merge (exemplo) 3.m.1 3.m.2 3.m.3 hello.c Maria hello.h 2.m.1 2.m.2 4 5 • hello.h 2 3 4 • hello.c 3.j.1 3.j.2 3.j.3 3.j.4 José hello.h 2.j.1 2.j.2 2.j.3 Introdução
Tronco principal de desenvolvimento Branching e Merging Branch patch 1.2.2.1 rel_1_fix tag 1.2.2.2 1.1 1.2 1.3 1.4 release_1 release_2 Merge Tronco principal de desenvolvimento tag Introdução
Build Representa uma versão ainda incompleta do sistema em desenvolvimento, mas com certa estabilidade Costumam apresentar limitações conhecidas Espaço para integração de funcionalidades Introdução
Mais sobre build Incluem não só código fonte, mas documentação, arquivos de configuração, base de dados, etc. A política de geração dos builds deve ser bem definida na estruturação do ambiente A geração de builds deve ser automatizada e realizada com freqüência adequada Alguns especialistas na área de engenharia de software advogam a idéia de que builds devem ser realizados, no mínimo, diariamente. A justificativa é que problemas com integração são freqüentes no desenvolvimento de software e gerar builds com freqüência ajuda a encontrar esses problemas cedo no processo de desenvolvimento. Introdução
Release Versão do sistema validada após os diversos tipos de teste Produto de software Supostamente sem erros Entregue ao cliente ou ao mercado Processo iterativo/incremental produz, em geral, mais de um release Introdução
Mais sobre release Implantado no cliente Deve ser devidamente mantido Enquanto a linha principal evolui Uso de branches e merges Introdução
Oportunidades criadas com GC Reuso de itens de software Artefatos Componentes Automação de processo Construção de builds Geração de releases Testes Integração Introdução
Conclusões GC é um fluxo de apoio ao projeto como um todo Passos iniciais para a adoção de um processo de software Requer uma certa disciplina na manipulação de itens de configuração Apoio de ferramentas sempre que possível Lembrar que apesar de ferramentas serem muito importantes na Gestão de Configuração, elas não devem comandar as políticas implementadas. Introdução
Padrões em Gerência de Configuração Reuso de soluções Introdução
Créditos Compilação de padrões contidos no livro “Software Configuration Management Patterns: Effective Teamwork, Practical Integration” de Steve Berczuk Introdução
O que são padrões? Padrões são formas de representação de conhecimento, organizado de forma estruturada Objetiva a rápida assimilação e aplicação em um novo contexto Construído a partir da destilação de anos de experiência Padrões apresentam soluções para problemas constantes, sem impor sempre a mesma implementação. Alexander falou que padrões não são importantes porque mostram coisas que não sabemos, mas porque mostram coisas que já sabemos, mas não admitimos porque parecem muito simples. Introdução
Estrutura de um padrão Nome Contexto Problema a ser solucionado Solução Diagrama representando a solução (opcional) Introdução
Padrões em GC Catálogo com 15 padrões Classificação dos padrões: Codeline Workspace Introdução
Mainline “Simplifique seu modelo” Classificação: Codeline Você quer simplificar sua estrutura de codelines Como manter várias codelines (e minimizar merging)? Introdução
Mainline (Contexto) A utilização de Branches é uma ótima maneira de isolar esforços paralelos. Exemplos de branches durante o desenvolvimento: Variar código para plataformas Manter manutenções de releases Isolar esforços durante o desenvolvimento. Porém, isto requer merging, o que pode ser custoso. Tarefa 1 Merge Tarefa 2 Tarefa 3 Introdução
Mainline (Contexto) O uso desenfreado de branches pode gerar estruturas complexas, difíceis de serem mantidas e integradas. Algumas empresas aboliram o uso de branch devido a más experiências Introdução
Mainline (Solução) Controle o uso de branch elegendo uma linha de desenvolvimento principal que Agrega todos os esforços Serve de base para outras codelines Reduz custo com merging Rel 1.1 1.0 Correções t1 /Mainline t1 1.0 t2 2.0 Rel 1.0 Rel 2.0 Introdução
Mainline (Criação/Manutenção) Crie uma codeline a partir da base de artefatos Check-in todas mudanças nesta codeline Mantenha a codeline reutilizável (testes) Planeje cuidadosamente a necessidade de e a vida (criação e morte) de cada branch [Não Resolvido] Como motivar o uso da mainline por muitas pessoas? Doing mainline development does not mean “do not branch.” It means that all ongoing development activities end up on a single codeline at some time. Think hard before branching; ask yourself if the work really requires a branch. Mainline O padrão Active dev. Line é aplicado no contexto do mainline Active dev. line Introdução
Active Development Line “Defina suas metas” Classificação: Codeline Você está desenvolven-do em uma mainline Como manter a evolução rápida de uma codeline de maneira estável para que seja útil? Introdução
Active Development Line (Contexto) A mainline é um ponto de sincronização Requer a comunicação entre os desenvolvedores Check-ins e integrações freqüentes são bons Check-ins com má qualidade afetam a todos Procedimentos rigorosos Demoram muito tempo Geram menos check-ins (natureza humana) Logo, atrapalham o projeto Introdução
Active Development Line (Contexto) Problemas de produtividade Linha de desenvolvimento pouco ativa e muito estável Linha de desenvolvimento muito ativa e pouco estável Bons testes Testes fracos Introdução
Active Development Line (Solução) Use uma linha de desenvolvimento ativa Com políticas para a estabilidade necessária da codeline para suas necessidades Considerando, o próprio ritmo de desenvolvimento. Introdução
Active Development Line (Problemas não resolvidos) Alguns padrões complementares Private Workspace : Ambiente isolado de desenvolvimento Smoke Test : Mantém a estabilidade da codeline Task Branch: Lida com tarefas de grande risco: Release Prep Codeline: Evita congelamento da codeline Mainline Active dev. line Private Workspace Smoke Test Release Prep Codeline Task Branch Introdução
Private Workspace “Isole o seu trabalho” Classificação: Workspace Você quer suportar uma Active Development Line Como evoluir sem se distrair com as freqüentes mudanças do ambiente? Introdução
Private Workspace (Contexto) Integração freqüente evita o trabalho com artefatos desatualizados Porém, pessoas não conseguem raciocinar em um ambiente em constante mudança Algumas vezes, artefatos diferentes dos encontrados no ambientes são necessários Porém, isolamento em excesso é proibitivo Introdução
Private Workspace (Solução) Crie um ambiente de trabalho privado que contenha tudo o que você necessita para executar suas tarefas em uma codeline Você controla quando atualizá-lo Antes de integrar suas tarefas Update Build Test Servidor central atualiza Ambiente local desenvolvedor commit Introdução
Private Workspace Pode conter: Não pode conter: Código-fonte a ser editado Componentes compilados localmente Dados e código para testar localmente o sistema Scripts de build Não pode conter: Versões especializadas de scripts, quebrando a política do projeto; Componentes que estão versionados mas que você copiou de um outro local desconhecido; Diferentes versões de ferramentas certificadas pela organização Introdução
Private Workspace (Problemas não resolvidos) Alguns padrões complementares Repository: Povoar o ambiente de trabalho Private system build: Construir e testar o ambiente Integration Build: Integração com as mudanças dos outros Active dev. line Private Workspace Repository Integration Build Private sys build Introdução
Repository “Um único lugar para compras” Classificação: Workspace Private workspaces e Integration Builds precisam de componentes Como obter a versão correta de um determinado componente em um ambiente de trabalho? Introdução
Repository (Contexto) Diferentes artefatos compõem um workspace Codigo, scripts, componentes de terceiros Artefatos podem vir de diversas fontes Outros grupos, empresas terceiras Integradores, Testadores e Desenvolvedores precisam, se necessário, ter acesso às mesmas versões de componentes Introdução
Repository (Solução) Ponto único de acesso a todos os artefatos em suas devidas codelines Mecanismos de acesso Replicação de workspaces Organização de todas as versões de cada itens de configuração Código fonte Repository Workspace Biblioteca de terceiros Scripts de build Introdução
Repository (Problemas restantes) Caso a ferramenta de controle de versão não faça o mapeamento automático dos componentes no ambiente de trabalho, uma ferramente de script, como o ANT Introdução
Private System Build “Pense globalmente e construa localmente” Classificação: Workspace Você precisa construir e testar o que está em seu Private Workspace Como verificar que suas mudanças não interropem o sistema antes de realizar um commit no Repositório? Introdução
Private System Build (Contexto) Adequar as necessidades de um build para um workspace de desenvolvimento O build do sistema pode ser complicado Manter consistência com outros builds Evitar commits de mudanças que interropam o sistema Atenuar isolamento de um Private Workspace Introdução
Private System Build (Solução) Construa o sistema usando os mesmos mecanismos do build central de integração Use os mesmos componentes e ferramentas (reproduzir problemas) Considere apenas detalhes relevantes ao desenvolvimento Inclua todas as dependências requeridas Faça isto antes de cada commit Inclua chamada para testes durante o build Atualize o cabeçalho da codeline antes de executar o build - Evite colocar detalhes do release ou do empacotamento do sistema num Private System build. Por exemplo, não coloque a criação de instaladores ou outros detalhes do produto final. Introdução
Private System Build (Problemas não resolvidos) Se a construção de todo o sistema é proibitivo, construa a menor quantidade de componentes que sua mudança requer. Alguns padrões complementares Smoke Test: Testar o que você construiu Private Workspace Private sys build Smoke Test Introdução
Integration Build “Realize um build centralizado” Classificação: Workspace O que é realizado em um Workspace precisa ser compartilhado Como garantir que o codebase sempre é construído consistentemente? Introdução
Integration Build (Contexto) Trabalhos individuais devem ser integrados Comunicação não é o suficiente Você quer garantir que o que é atualizado no repositório funciona Private System Build é uma forma de testar o sistema Porém, construir sempre todo os sistema pode levar muito tempo Introdução
Integration Build (Solução) Execute um build centralizado para todo o sistema em um ambiente isolado Introdução
Integration Build (Processo) Determine a freqüências de acordo com O tempo de duração do build A freqüência das mudanças O processo de build deve ser: Reprodutível Tão próximo quanto possível de um build de produto final Automatizado, com mínima intervenção manual Um mecanismo de log e de notificação (e-mail) para sanar problemas rapidamente Introdução
Integration Build Identifique builds com uma tag (Repositório) Repita para todas as plataformas suportadas Se um build falhar continuamente, adicione mais verificações antes dos commits. Se possível, use o Integration Build como base para install kits. Introdução
Integration Build (Problemas não resolvidos) Alguns padrões complementares Repository: Diponibilizar resultados do build Smoke Test: Testar se o build é útil Regression Test: Testar stable baselines Task Level Commit: Descobrir o que quebrou o build Private Workspace Integration Build Repository Task level commit Smoke Test Regression test Introdução
Task Level Commit “Realize um commit por cada pequena tarefa” Classificação: Workspace Você precisa associar mudanças com um build de integração Quanto você deve trabalhar antes de realizar um commit no Repositório? Um Integration Build torna-se mais fácil de gerenciar, depurar, etc, se você sabe exatamente quais funcionalidades foram inseridas no build Este padrão mostra como balancear as necessidades por estabilidade, velocidade e atomicidade Introdução
Task Level Commit (Contexto) É tentador realizar várias pequenas mudanças em um único check-in Políticas rigorosas Tarefas complexas Quanto menores as mudanças associadas a um check-in, Mais fácil é voltar atrás. Mais fácil é identificar problemas Introdução
Task Level Commit (Solução) Efetue um commit por tarefa consistente (ou sub-tarefa, com granularidade adequada) Considere a complexidade de cada tarefa, se pode ser subdividida, etc. Se houver dúvida, induza o erro para a granularidade menor Isto aumenta a freqüência das integrações Aumenta a possibilidade de desfazer, de forma segura, o trabalho feito Introdução
Task Level Commit Algumas modificações são intrinsecamente longas Utilize Task Branch, e repita as considerações propostas por Task Level Commit dentro do novo branch Antes de realizar um commit, assegure que seu workspace possui o estado corrente da codeline Utilize testes (Unit Test) para assegurar mudanças consistentes Introdução
Codeline Policy “Defina as regras” Classificação: Codeline Active Development Line e Release Line precisam ter regras diferentes. Quando os desenvolvedores sabem quando e como usar cada codeline? Um Integration Build torna-se mais fácil de gerenciar, depurar, etc, se você sabe exatamente quais funcionalidades foram inseridas no build Este padrão mostra como balancear as necessidades por estabilidade, velocidade e atomicidade Introdução
Codeline Policy (Contexto) Diferentes codelines têm diferentes requisitos de estabilidade Como explicar uma política? Qual o nível de documentação que você precisa? Como motivar as pessoas a utilizá-la? Política de release line Release Política de Mainline Main Introdução
Codeline Policy (Solução) Defina regras para cada codeline como uma Política do Codeline, que Determine como e quando as pessoas realizaram mudanças. Seja concisa e passível de auditoria As políticas de cada codeline podem conter: Tipo de trabalho sugerido (desenvolvimento, release, etc) Como e quando novos elementos podem sofrer check-in, check-out, branch e merge Restrições de acesso para indivíduos, papéis e grupos A duração dos trabalhos A carga de trabalho esperada e a freqüência de integrações Introdução
Codeline Policy (Boas práticas) Textos curtos e objetivos: “direto ao ponto” Com apenas o essencial ao contexto da codeline De 1 a 3 parágrafos. Uma página no máximo Adicione aos comentários de sua codeline no seu sistema de controle de versão Crie um Branch, sempre que tiver incompatibilidade de políticas Divulgação efetiva das políticas no grupo Utilize ferramentas automáticas que facilitem o uso de sua política (ex.: ANT) Introdução
Smoke Test “Verifique funcionalidades básicas” Classificação: Workspace Você precisa de verificações em seus builds de forma a manter a Active Development Line. Como verificar que o sistema continua funcionando após a mudança? Não basta apenas compilar o código Verificação do comportamento run-time do sistema é importante para garantir integração Introdução
Smoke Test (Contexto) Testes exaustivos são bons para garantir a qualidade Quanto mais longo for teste, mais longos serão os commits Commits com menor freqüência Maior probabilidade de mudanças na Baseline desde a última verificação Introdução
Smoke Test (Solução) Condicione cada build a um teste de fumaça que verifique que o sistema ainda funcionará em cenários básicos. Testes simples de caixa preta Iterações inadvertidas, bugs conhecidos Garante integração básica dos componentes Rápido de executar Provê cobertura geral do sistema Se você possui metas de qualidade muito severas que necessitem de testes exaustivos, consider Task Branches ou políticas de codeline diferentes. Testes de fumaça são mais eficazes para builds que possam não muitos consistentes (Private System Build) Entradas prontas podem ser utilizadas caso elas sejam realisticas Se seu teste é muito complicado, vc pode acabar adicionando riscos tendo que testar os próprios testes Introdução
Smoke Test (Problemas não resolvidos) Smoke Tests não são o sulficiente: Regression Test: Lida com problemas que você achava já ter resolvido Unit Test: Nível de abstração menor Integration Build Active development Line Private sys build Smoke Test Unit Test Regression test Introdução
Unit Test “Verifique os contratos” Classificação: Workspace Smoke Tests não são suficientes para verificar que um modulo funciona em um nível menor de detalhes. Como verificar que um modulo continua funcionando após a mudança? Muitas vezes, Smoke Tests não são suficientes para testar uma mudança em detalhes. Principalmente se for novo código. Este padrão mostra como testar em detalhes mudanças no código para garantir a qualidade do codeline Introdução
Unit Test (Contexto) Integração identifica problemas, mas é dificil para isolar problemas Necessidade de isolar questões de integração de questões de mudanças locais das unidades Testar o contrato de cada elemento localmente Estratégia incremental: a parte, depois o todo Introdução
Unit Test (Solução) Desenvolva e execute testes unitários Verificando se um componente obedece seu contrato Bons testes unitários são: Simples para rodar Granularidade fina. Cada método significativo da interface de uma classe deve ser testado Automáticos com auto-avaliação. Olha-se para os testes somente quando houver uma falha Isolados. Um teste unitário não interage outros testes detalhado de um componente isolado do sistema Introdução
Unit Test Testes unitários devem ser executados: Boas práticas: Enquanto o software é codificado; Antes de um check-in e após atualizar seu workspace com a versão corrente do software Boas práticas: Uso de um framework para escrever testes (Junit, CPPUnit, etc) Redução da quantidade depuração em prol dos testes unitários. Ganhos de produtividade Introdução
Regression Test “Teste as mudanças” Classificação: Workspace Smoke Tests são bons mas não abrangem todos os casos Como garantir que um código não deteriora ao longo do tempo? Smoke Test é uma solução rápida para verificações mais triviais É preciso uma estratégia para garantir que modificações no software não deteriore sua qualidade ao longo do tempo Introdução
Regression Test (Contexto) Abranger todos os casos leva tempo É uma boa estratégia adicionar testes à medida que erros são encontrados Quando um antigo erro reaparece: você quer estar apto a identificar quando isto acontece provar que o software não apresenta problemas dos passado Introdução
Regression Test (Solução) Desenvolva uma bateria de testes de regressão baseado em casos de testes que o sistema falhou no passado Prefira testes que envolvam entradas do sistema Rodar a cada check-in pode custar caro Unit Tets podem ser mais baratos Rode Regression Tests sempre que quiser validar a estabilidade o sistema Antes de um build de release Antes de uma alteração de alto risco Podem ser casos de teste de : Problemas reportados em um processo de pre-relase Problemas reportados por clientes Testes de Sistema baseado nos requisitos Porém, Unit Test também podem ser adicionados Adicione testes a medida que encontrar problemas Introdução
Private Versions “Histórico Privado” Classificação: Codeline Uma Active Development Line ficará inconsistente se commits forem realizados no meio de uma tarefa. Como realizar tarefas complexas e ainda ter os benefícios de um gerenciamento de versões? Smoke Test é uma solução rápida para verificações mais triviais É preciso uma estratégia para garantir que modificações no software não deteriore sua qualidade ao longo do tempo Introdução
Private Version (Contexto) Algumas vezes deseja-se criar um checkpoint durante passos intermediários de uma tarefa longa e complexa. Checkpoint é mecanismos oferecido por sistemas de gerenciamento de versões Você não deseja publicar passos intermediários Usar ferramentas já utilizadas e conhecidas pela sua empresa Introdução
Private Version (Solução) Forneça aos desenvolvedores mecanismos com checkpointing mudanças Com uma interface simples Na granularidade que eles estejam comfortáveis Pode ser implementado como Private History Private Repository Private Branch Você poderia até tomar uma atitude Ad-hoc (Private History) e criar uma estrutura de diretorios onde você copiasse backups de seus arquivos periodicamente. Porem, no final, vc estaria apenas simulando um sistema simples de G.C. Private Repository e Private Branch podem ser implementados se vc tiver uma ferramenta que implemente isto Introdução
Task Branch “Lidando com tarefas de longa duração” Classificação: Codeline Algumas tarefas possuem passos intermediaários que prejudicariam o ritmo de uma Active Development Line Como um time pode realizar múltiplas tarefas de longa duração em uma codeline sem comprometer sua integridade? Smoke Test é uma solução rápida para verificações mais triviais É preciso uma estratégia para garantir que modificações no software não deteriore sua qualidade ao longo do tempo Introdução
Task Branch (Contexto) Às vezes somente parte da equipe está trabalhando em uma tarefa A tarefa pode incluir vários passos Exemplo: Grandes refactorings não são facilmente realizados em estágios. Ex.: novo mecanismo de persistência Trabalhos para o futuro
Task Branch (Solução) Use Branches para isolamento da Mainline Crie um branch em separado para cada atividade que tiver mudanças significantes para a codeline. Use como um mecanismos para reduzir riscos Para facilitar o merge final do branch, integre constantemente mudanças na codeline Você precisa estar seguro que mudanças na mainline continuam funcionando com suas mudanças no branch. Ao final: Merge na codeline apropriada. Ou, notifique ao dono da codeline informações necessárias para a integração. Introdução
Release Line “Desenvolvimento Não-Linear” Classificação: Codeline Você quer manter uma Active Development Line. Como manter uma versão de release sem interferir no trabalho corrente? Você possui uma Active Development Line com versões de release que precisam ser mantidas e evoluídas e uma base código que deve permanecer estável. Introdução
Release Line (Contexto) Tudo não pode ser evoluído na mainline Release precisa de uma política com mais estabilidade Precisa-se evitar estruturas complexas O trabalho corrente na main line não deve ser interferido Introdução
Release Line (Solução) Divida manutenção/release a desenvolvimento ativo em codelines separadas. Mantenha cada release em uma release line independente para possibilitar a correção de bugs Branch cada release line de sua mainline.
Release-Prep Codeline “Evite congelar o código” Classificação: Codeline Você quer manter uma Active Development Line. Como estabilizar uma codeline para um release iminente ainda permitindo que novas tarefas continuem na codeline ativa? Contexto: Você está terminando um release e também precisa continuar com o desenvolvimento para o próximo release. Problema: Como estabilizar uma codeline para um release eminente enquanto novos trabalhos estão sendo realizados um sua active codeline? Introdução
Release-Prep Codeline (Contexto) A codeline precisa ser estabilizada para que o release seja terminado Congelar novos trabalhos na codeline é penoso Uma Release Line pode ser custosa, se apenas uma pequena parte do time está trabalhando em um novo release Release line antecipada
Release-Prep Codeline (Solução) Crie um novo branch quando o código estiver se aproximando da qualidade desejada do release. Finalize o release neste branch, e torne-o o Release Line Congelar o código funciona normalmente em no máximo 2 dias. Após isto é um caos. Introdução
A relação entre os padrões Mainline Task Branch Active dev. line Release-Prep Code Line Private Workspace Private sys build Release Line Integration Build Private Versions Repository Task level commit Smoke Test CodeLine Policy Regression test Unit Test Introdução
Disciplina de Gerência de Configuração e Ambiente Introdução
Objetivos Definir Recursos de hardware e software Política de atualização destes recursos Estruturação de diretórios e repositórios Plataforma de desenvolvimento Política de utilização do ambiente As atividades de Gerência de Configuração que deverão ser realizadas e em que momentos do desenvolvimento Introdução
Responsáveis Gerente de Configuração e ambiente Responsável pela definição dos equipamentos e softwares utilizados e suas configurações Define o ambiente, regras de uso do mesmo e política de mudanças Define os papéis dos membros da equipe responsáveis pelas atividades de gerência de configuração Estabelece as atividades de gerência de configuração que serão realizadas Introdução
Artefatos Documento de Definição de Ambiente Plano de Gerência de Configuração de Software Documento de Definição de Ambiente Plano de Gerência de Configuração de Software Introdução
Artefatos – Documento de Definição de Ambiente 1. INTRODUÇÃO <Descreva os objetivos do documento> 2. INFRA-ESTRUTURA 2.1. FERRAMENTAS <Descreva que ferramentas serão usadas por todos os envolvidos no projeto durante o seu desenvolvimento, fornecendo uma breve descrição de cada uma e a quantidade de licenças disponíveis> 2.2. EQUIPAMENTOS <Descreva que equipamentos serão usadas durante o desenvolvimento do sistema, detalhando suas configurações> 3. ORGANIZAÇÃO FÍSICA <Forneça uma breve descrição da estrutura física do local onde o sistema será desenvolvido> Introdução
Artefatos – Documento de Definição de Ambiente 4. PADRÃO DE NOMENCLATURA DE ARTEFATOS <Descreva qual será a convenção utilizada para nomear os artefatos, em inglês ou português> 5. AMBIENTE LOCAL 5.1. ESTRUTURA DE DIRETÓRIOS 5.2. INFORMAÇÕES ADICIONAIS 6. AMBIENTE DE HOMOLOGAÇÃO E TESTES 6.1. ESTRUTURA DE DIRETÓRIOS 6.2. INFORMAÇÕES ADICIONAIS 7. AMBIENTE DE PRODUÇÃO 7.1. ESTRUTURA DE DIRETÓRIOS 7.2. INFORMAÇÕES ADICIONAIS 8. ARQUIVOS DE CONFIGURAÇÂO <Descreva os arquivos utilizados para configuração e uso do sistema> Introdução
Artefatos – Documento de Definição de Ambiente 9. PROMOÇÂO ENTRE AMBIENTES E BACKUPS <Defina a política para promoção dos artefatos entre os ambientes e realização de backups> 9.1. AMBIENTE LOCAL AMBIENTE DE HOMOLOGAÇÃO E TESTES <Descreva o procedimento que deve ser usado para transferir arquivos do ambiente local para o de homologação e testes 9.2. AMBIENTE LOCAL AMBIENTE DE PRODUÇÃO <Descreva o procedimento que deve ser usado para realizar a transferência de arquivos entre o ambiente de homologação e testes e o ambiente de produção> 10. POLÍTICA DE BACKUP <Descreva o procedimento que deve ser usado para realização de backups em cada um dos ambientes> 11. AVALIAÇÃO E REVISÃO DO AMBIENTE <Descreva as modificações que serão necessárias no ambiente para o desenvolvimento do projeto> 12. REFERÊNCIAS Introdução
Artefatos – Plano de Gerência de Configuração de Software 1. INTRODUÇÃO <Descreva os objetivos do documento, forneça definições de termos necessários para o entendimento do mesmo e liste algumas referências interessantes.> 2. GERENCIAMENTO DA GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 2.1. ORGANIZAÇÃO <Deve ser descrita nesta seção a estrutura da equipe de GCS e como ela se encaixa na estrutura da organização com relação a outras equipes> 2.2. RESPONSABILIDADES <Defina nesta seção os deveres e responsabilidades daqueles que estiverem envolvidos com as atividades de GCS.> 2.3. RELAÇÃO COM AS FASES DO DESENVOLVIMENTO E OUTROS FLUXOS DE ATIVIDADES <Nesta seção são relacionadas as atividades de GCS com as diferentes etapas do ciclo de vida do desenvolvimento de software.> Introdução
Artefatos – Plano de Gerência de Configuração de Software 3. ATIVIDADES DA GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 3.1. IDENTIFICAÇÃO DA CONFIGURAÇÃO <Esta seção descreve como identificar, nomear e adquirir os itens de configuração do sistema.> 3.1.1. Identificação de itens de configuração 3.1.2. Nomeação dos itens de configuração 3.1.3. Aquisição e armazenamento de itens de configuração 3.1.4. Gerenciamento de baselines 3.2. CONTROLE DA CONFIGURAÇÃO <Nesta seção deve ser descrito o processo de gerência de mudanças. Normalmente, essa informação é colocada em um documento a parte chamado Documento de Políticas de Mudanças. Aqui deve apenas ser incluído um apontador para esse documento.> Introdução
Artefatos – Plano de Gerência de Configuração de Software 3.3. REGISTRO DO STATUS DA CONFIGURAÇÃO <Esta seção lida com os detalhes de registrar o status de cada item de configuração e apresentar essa informação aos indivíduos que precisam saber sobre ela.> 3.1.1. Identificação das necessidades de informação 3.1.2. Mecanismos de coleta de informações 3.1.3. Relatórios, seus conteúdos e frequências 3.1.4. Acesso a dados de registro de status 3.4. AUDITORIA DA CONFIGURAÇÃO <Esta seção descreve os tipos de auditoria que serão realizados, o procedimento de auditoria, a freqüência e qualquer outra informação relevante.> 3.1.1. Auditorias que devem ser realizadas 3.1.2. Procedimentos de auditoria Introdução
Artefatos – Plano de Gerência de Configuração de Software 4. AGENDA DA GERÊNCIA DE CONFIGURAÇÃO <Esta seção descreve a seqüência de atividades de GCS, suas interdependências e a relação com o ciclo de vida do projeto.> 5. RECURSOS DE GERÊNCIA DE CONFIGURAÇÃO <Indique nesta seção as ferramentas de software, técnicas, equipamentos, pessoas e treinamentos necessários para a implementação das atividades de gerência de configuração especificadas.> 6. MANUTENÇÃO DO PLANO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE <Esta seção descreve as atividades que são necessárias para manter o plano atualizado durante o ciclo de vida do projeto.> Introdução
O Fluxo de Atividades Introdução Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração Introdução
Definir Ferramentas e Equipamentos Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração Introdução
Definir Ferramentas e Equipamentos(continuação) Objetivos Definir ferramentas de suporte ao desenvolvimento, controle de versões e softwares em geral Definir hardwares e suas configurações Definir regras para atualizações de hardware e software Responsável Gerente de configuração e ambiente Introdução
Definir Ferramentas e Equipamentos(continuação) Entradas Documento de requisitos Lista de riscos Estudo de viabilidade Saídas Documento de definição de ambiente Plano de gerência de configuração de software Introdução
Passos para Definir Ferramentas e Equipamentos Passo 3 – Definir Equipamentos e suas Configurações Escolha dos equipamentos (hardware) que serão utilizados para o desenvolvimento e teste do sistema Devem ser explicitadas Configurações das máquinas Periféricos necessários As máquinas devem ser compatíveis com as plataformas escolhidas e ter, pelo menos, as configurações mínimas necessárias para o uso das ferramentas Introdução
Passos para Definir Ferramentas e Equipamentos Definir plataformas de desenvolvimento Definir ferramentas Definir equipamentos e suas configurações Introdução
Passo 1 – Definir Plataforma(s) de Desenvolvimento Escolha da plataforma sobre a qual o sistema será desenvolvido Deve ser levada em consideração também a plataforma na qual o sistema rodará Introdução
Passo 2 – Definir Ferramentas Escolha das ferramentas que serão utilizadas para o desenvolvimento do sistema Inclui IDEs, ferramentas de teste, sistemas de gerência de configuração, SGBD, etc Devem ser fornecidas informações sobre cada ferramenta escolhida As ferramentas definidas nesta atividade que tiverem relação com atividades de gerência de configuração (controle de versões, gerência de mudanças, construção automática de builds, etc.) devem ser registradas também no plano de gerência de configuração de software, na seção chamada Recursos de Gerência de Configuração de Software. Introdução
Passo 3 – Definir Equipamentos e suas Configurações Escolha dos equipamentos (hardware) que serão utilizados para o desenvolvimento e teste do sistema Devem ser explicitadas: Configurações das máquinas Periféricos necessários As máquinas devem ser compatíveis com as plataformas escolhidas e ter, pelo menos, as configurações mínimas necessárias para o uso das ferramentas Introdução
Estruturar Ambiente Introdução Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração Introdução
Estruturar Ambiente(continuação) Objetivos Determinar a estrutura de diretórios que será adotada para o projeto Definir os diferentes ambientes desenvolvimento, integração, testes, produção Definir a política de uso do ambiente Responsável Gerente de configuração e ambiente Introdução
Estruturar Ambiente(continuação) Entradas Documento de definição de ambiente Plano de gerência de configuração de software Saídas Documento de definição de ambiente (atualizado) Plano de gerência de configuração de software(atualizado) Introdução
Passos para Estruturar Ambiente Definir estrutura de diretórios, repositórios e áreas de backup Definir política para utilização do ambiente Introdução
As seguintes áreas podem ser definidas: Passo 1 – Definir Estrutura de Diretórios, Repositórios e Áreas de Backup As seguintes áreas podem ser definidas: Área para apresentação da metodologia Desenvolvimento, testes, integração e produção Área de programas Repositórios onde são mantidos os itens de configuração Área para disponibilização de builds e releases Cada uma dessas áreas deve ter uma estrutura interna bem definida Introdução
Passo 2 – Definir Política para Utilização do Ambiente Neste passo são definidas diversas regras relacionadas à utilização do ambiente Forma de acessar o site da metodologia Forma de recuperar templates com o fim de criar artefatos Política de realização de backups do projeto Regras para recuperação e atualização de itens de configuração Políticas para a criação de branches Introdução
Planejar Gerência de Configuração Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração Introdução
Planejar Gerência de Configuração (continuação) Objetivos Definir os papéis e responsabilidades dos membros da equipe responsável pelas atividades de gerência de configuração (GC) Definir os baselines que deverão ser estabelecidos Definir o cronograma das atividades de GC Definir as políticas, procedimentos e padrões que guiarão essas atividades Identificar os itens de configuração Responsável Gerente de configuração e ambiente Introdução
Planejar Gerência de Configuração (continuação) Entradas Plano de gerência de configuração de software Saídas Plano de gerência de configuração de software (atualizado) Introdução
Passos para Planejar Gerência de Configuração Definir organização, papéis e responsabilidades Definir políticas e procedimentos para registro do status da configuração Definir esquema de nomeação para itens de configuração Identificar e registrar itens de configuração Planejar auditorias Definir baselines Definir cronograma de gerência de configuração Introdução
Passo 1 – Definir Organização, Papéis e Responsabilidades Neste passo devem ser definidos os papéis e responsabilidades da equipe responsável pelas tarefas GC A relação dessa equipe com as outras do time de desenvolvimento também deve ser descrita nesta atividade É interessante mencionar as atividades de GC que são realizadas por pessoas fora da equipe de GC Introdução
É importante especificar o modo como essas informações serão coletadas Passo 2 - Definir Políticas e Procedimentos para Registro do Status da Configuração Neste passo, devem ser descritas as informações a ser registradas durante o desenvolvimento É importante especificar o modo como essas informações serão coletadas Também são definidos os relatórios que serão emitidos a partir dessas informações Alguns exemplos de informações que normalmente são documentadas são: - O status de cada item de configuração em um determinado instante. - A lista de mudanças implantadas em cada um desses itens. - Os detalhes de cada uma dessas mudanças: quem solicitou, quem implantou, quando foi solicitada/implantada, qual o impacto que a mudança acarretou, etc. Além dos relatórios que serão emitidos a partir das informações do status da configuração, é importante também que sejam especificados no Plano de Gerência de Configuração de Software meios através dos quais seja possível obter informações além das pré-definidas. O objetivo disso é permitir que relatórios extraordinários possam ser emitidos também, quando forem necessários, sem que grande esforço tenha que ser despendido. Introdução
Passo 3 – Definir Esquema de Nomeação de Itens de Configuração Para cada item de configuração selecionado, deve ser atribuído um identificador único Para tanto, deve ser definido um esquema de nomeação Esse esquema deve permitir diferenciar versões diferentes de um item de configuração Introdução
Passo 3 – Definir Esquema de Nomeação de Itens de Configuração Um esquema de nomeação que atende aos requisitos mencionados é o seguinte: <projeto>-<tipo de item><contador>V<versão> Alguns exemplos: QIB-HW00005V1.2 QIB-SW00034V1.5 AMAZONIA-SW00035V4.1 QIB-DOC00002V5.0 Introdução
Passo 4 – Identificar e Registrar Itens de Configuração Neste passo, são selecionados os itens de configuração que fazem parte do sistema em desenvolvimento Cada item selecionado deve ser unicamente identificado de acordo com o esquema de nomeação definido As características físicas e funcionais de cada item devem ser registradas na base de dados de GC Conforme dito no início do curso, um item de configuração normalmente é estabelecido para cada pedaço de software que pode ser projetado, implementado e testado de forma independente. É muito importante ressaltar, porém, que um item de configuração não é necessariamente um programa: a documentação do sistema, dispositivos de hardware e especificações também são itens de configuração, se só puderem se modificados mediante procedimento formal. Introdução
Passo 5 – Planejar Auditorias Devem ser definidos, neste passo, os tipos de auditoria que serão realizados na configuração: Os dois tipos mais comuns são: Auditoria física da configuração Auditoria funcional da configuração Também devem ser definidos: Os momentos em que as auditorias serão realizadas Os itens de configuração que serão auditados Os procedimentos, papéis e responsáveis para cada auditoria Introdução
Passo 6 – Definir Baselines O objetivo deste passo é definir os baselines que serão estabelecidos durante o processo de desenvolvimento Devem ser documentadas as características físicas e funcionais de cada um Baselines formais são disponibilizados como versões do sistema ou parte dele para indivíduos fora da equipe de desenvolvimento. Normalmente estão diretamente associados com a liberação de releases, ou seja, poucos baselines formais são estabelecidos no decorrer processo de desenvolvimento. Baselines internos podem ser estabelecidos a qualquer momento, sempre que for necessário definir um ponto de partida para a execução de uma atividade ou manter o estado de um item de configuração considerado estável. Introdução
Passo 7 – Definir Cronograma de GC Neste passo é elaborado um cronograma das atividades de gerência de configuração, relacionando-as com as outras atividades do projeto No cronograma, devem constar informações como: As fases do ciclo de vida do projeto nas quais os diferentes baselines deverão ser estabelecidos As fases do ciclo de vida do projeto nas quais os diferentes releases que serão liberados As ocasiões nas quais serão realizadas as diferentes auditorias da configuração. Introdução
Implantar e Administrar Ambiente Gerente de Configuração e Ambiente Definir ferramentas e equipamentos Implantar e administrar ambiente Estruturar ambiente Planejar gerência de configuração Introdução
Implantar e Administrar Ambiente(continuação) Objetivos Implantar o ambiente com base na estrutura definida na atividade anterior Gerenciar a utilização do ambiente de acordo com as normas propostas Avaliar e revisar o ambiente Responsável Gerente de configuração e ambiente Introdução
Implantar e Administrar Ambiente(continuação) Entradas Documento de definição de ambiente Plano de gerência de configuração de software Saídas Documento de definição de ambiente (atualizado) Plano de gerência de configuração de software(atualizado) Entradas Documento de definição de ambiente Plano de gerência de configuração de software Saídas Documento de definição de ambiente (atualizado) Plano de gerência de configuração de software (atualizado) Introdução
Passos para Implantar e Administrar Ambiente Instalar máquinas e criar diretórios Disseminar política de utilização do ambiente Gerenciar e avaliar ambiente Introdução
Passo 1 – Instalar Máquinas e Criar os Diretórios Neste passo devem ser instalados e configurados os servidores e estações de trabalho Em cada máquina, devem ser instalados os softwares necessários, de acordo com o perfil de quem a estará utilizando A estrutura de diretórios da máquina deve obedecer ao que foi definido na atividade anterior Áreas de backup, repositórios e áreas para a disponibilização de builds são criados neste passo Introdução
Passo 2 – Disseminar Política de Utilização do Ambiente O objetivo deste passo é apresentar a política de uso do ambiente à equipe do projeto Devem ser ressaltados os benefícios e desvantagens que o uso dessa política trará Reforçar o seguimento da política Abrir espaço para feedbacks e sugestões Introdução
Passo 3 – Gerenciar e Avaliar Ambiente Acompanhamento da utilização do ambiente pela equipe do projeto; Manutenção do ambiente; Atualização de versões de softwares; Avaliação do ambiente ao fim de cada iteração. Busca de melhorias na produtividade; Re-avaliação das políticas de gerência de configuração Introdução
Relação com as Fases de Desenvolvimento e com as Outras Disciplinas Tem uma maior concentração na fase de concepção Nas iterações das fases seguintes, o nível de esforço é mantido constante Acontece em paralelo e com uma forte integração com a disciplina de planejamento e gerenciamento Algumas atividades relacionadas com a gerência da configuração ocorrem em outras disciplinas como a de implantação e a de implementação Introdução
Controle de Mudanças Introdução
Contexto Desenvolvimento iterativo/incremental Novos conjuntos de requisitos, detalhados a cada iteração Mudanças em estratégias de negócio motivadas pelas mais diversas fontes: mercado, cultura, leis, etc Introdução
Problemas Controle do escopo do projeto Modificações podem ampliar o leque de funcionalidades e aumentar significativamente o custo do projeto Atrasos em entregas planejadas Controle de consistência dos artefatos Uma mudança aparentemente localizada pode causar muito mais impacto do que o previsto Degradação da qualidade do software ex: abandono dos testes automatizados devido à inconsistência dos dados de teste Retrabalho Introdução
O que é Gerência de Mudanças? Gerência de Mudanças é o processo de avaliar, coordenar e decidir sobre a realização de mudanças propostas a itens de configuração (ICs) Mudanças aprovadas são implementadas nos itens de configuração e nos dados e documentos relacionados Introdução
Objetivos da Gerência de Mudanças Garantir que os artefatos do sistema alcançam e mantém uma estrutura definida através do seu ciclo de vida Definir procedimentos e documentação necessários para realizar modificações a ICs Prover os mecanismos necessários para conduzir mudanças de uma maneira controlada Introdução
Benefícios Controle sobre o escopo do projeto Mais produtividade cada solicitação será tratada de forma coordenada Redução dos problemas de comunicação entre membros da equipe Mais qualidade, uma vez que cada mudança, antes de ser realizada, tem seu impacto avaliado Geração de dados para o acompanhamento (tracking) do projeto É importante esclarecer o que foi dito no terceiro tópico. O sistema se torna mais robusto porque cada mudança é avaliada antes de ser realizada. Nessa avaliação, além de questões como custo/benefício e tempo para a realização da mudança, é levado em consideração também o impacto que a mudança terá nas partes do sistema que dependem da que será modificada. O objetivo dessa avaliação é garantir que essas outras partes do sistema não sejam “quebradas” pela realização da mudança. Uma vez que a mudança tenha sido aceita, ela é planejada antes de ser implementada. Um dos objetivos desse planejamento é justamente garantir que as partes do sistema afetadas pela mudança são devidamente adaptadas para que o sistema não fique “quebrado”. Com relação ao quarto item, o número de erros diminui porque o controle sobre “quem fez qual mudança” passa a ser centralizado. Se um programador tentar corrigir um erro que já foi corrigido, ele simplesmente será avisado sobre esse fato e informado sobre onde pode encontrar a solução do problema. O problema dos dados compartilhados, por exemplo, poderia ser resolvido trivialmente. Introdução
Ciclo de vida de um artefato Introdução
Ciclo de vida de um artefato Draft Aceito Manutenção Concepção do artefato Mudanças feitas de forma informal Revisão/aceitação (baseline) Mudanças via controle formal (CCB) Mudanças em manutenção Release retirado Introdução
Artefato Draft Mudanças frequentes e rápidas Demanda por agilidade Controle formal dificulta a criação do artefato Artefatos apenas gerenciados e controlados Uso de controle de versão (CVS, Clear Case, entre outros) Introdução
Artefato Aceito Artefato seguiu um processo de revisão, testes (se aplicável) e aceitação Inserido dentro do processo de controle de mudanças, tornando-se de fato item de configuração Mudanças via solicitação formal Presença do grupo gestor de mudanças (CCB) para avaliar e priorizar mudanças Introdução
Artefato em Manutenção Após a entrega de uma versão do produto, os artefatos passam para a fase de manutenção Controle de mudanças permanece formal para os artefatos de um baseline Novas artefatos podem ser desenvolvidos usando o mesmo modelo de ciclo de vida Sistema pode ser descontinuado ou removido do ambiente de produção Introdução
Comitê gestor de mudanças Change Control Board (CCB) Introdução
Responsabilidades Análise das solicitações de mudança Controlar o escopo do projeto Reuniões com freqüência adequada ao ritmo das solicitações de mudança Envolver stakeholders no processo de priorização no processo de decisão Balanço entre o nível de controle desejado e overhead suportado Introdução
Características Composição multidisciplinar SQA, gerente, cliente, arquiteto Profissionais com grande capacidade de comunicação e negociação Pode apresentar uma estrutura hierarquica dependendo do tamanho e da quantidade de stakeholders e sistemas envolvidos (integrações) Introdução
Defeitos x Solicitações de mudança Defeitos não são normalmente processados pelo CCB, salvo se envolver algum questionamento relativo ao escopo do projeto Questões menores devem ser resolvidas pelo líder do projeto junto à equipe, reduzindo o overhead do CCB Introdução
Analisando o impacto Mudanças de grande impacto devem ser comunicadas aos stakeholders envolvidos Análises de custo x benefício produzidas pelos stakeholders Priorização de mudanças Mudança pode ser rejeitada se o CCB perceber que a análise de custo será mais cara que o benefício percebido Por questões de eficiência, algumas solicitações de mudança podem ser agrupadas por tema, subsistema ou área de negócio Introdução
Importância da análise de impacto Dentro do projeto Análises inter-sistemas devem ser consideradas Exemplo: frameworks, componentes ou bancos de dados compartilhados Análise de impacto intra-projeto Requisitos A&P Componentes Introdução
Processo de Gerência de Mudanças Introdução
Sobre o Processo de Gerência de Mudanças Deve ser definido um documento padrão para que mudanças possam ser solicitadas Esse documento normalmente se chama Solicitação de Mudança (SM) A um conjunto de pessoas, deve ser dada a autoridade para decidir se uma mudança será ou não implementada O processo é necessário para garantir que apenas mudanças avaliadas e aprovadas são realizadas em ICs Introdução
Solicitações de Mudança Algumas informações que podem estar incluídas em uma SM: Identificação única Solicitante Sistema/Projeto Item a ser modificado Classificação (melhoria, correção de defeito, outra) Prioridade Descrição Situação (nova, atribuída, finalizada, verificada, fechada) Introdução
Etapas do Processo Um processo genérico pode ser dividido nas seguintes etapas: CCB 4.Negociação sobre a realização da mudança 6. Verificação da mudança 1. Requisição da mudança (mudança aceita) 2. Classificação da mudança Não entraremos nos detalhes do processo de gerência de mudança neste momento porque este tópico é visto em detalhes em outro módulo do curso, no qual é apresentado o fluxo de Gestão de Mudanças. 7. Promoção dos itens modificados para um novo baseline 3. Avaliação da mudança 5. Implementação da mudança Introdução
Correções emergenciais Em algumas situações, não há tempo para seguir os procedimentos padrão para a realização de mudanças Mesmo nessas situações, porém, é muito importante que seja criada uma solicitação de mudança O objetivo é garantir um mínimo de ordem, mesmo em uma situação caótica Introdução
Correções emergenciais Mudanças realizadas nessas circunstâncias podem comprometer a arquitetura ou inserir bugs Decisão: Desfazer correção ou Transformar a correção: refactoring, acréscimo de novos casos de teste Introdução
Geração de releases Introdução
Baseline Identificação e empacotamento de artefatos entregues ao cliente (interno ou externo) Um release implica no estabelecimento de um novo baseline, de produto Garantia de que todos os itens de configuração foram devidamente testados, avalidos, aceitos e estão disponíveis no novo baseline Introdução
Release notes Relação de solicitações implementadas e testadas Automação parcial Comentários adicionais Limitações atuais, problemas não resolvidos Id Descrição 1 Problema de performance na validação de pedido 2 Nova rotina de validação de crédito conforme normas de dezembro de 2002 … Introdução
Tipos de release Normalmente, releases estão associados aos milestones do plano de projeto Internos Controle de qualidade, acompanhamento de projeto, controle de riscos, aceitação, aquisição de conhecimento através da coleta de feedbacks, desenho da estratégia de implantação Externos Implantado e utilizado pelo cliente Introdução
Desafios Cultura organizacional Agrupamento de solicitações em releases bem definidos e estabelecidos deve ser negociado com os stakeholders do projeto Releases internos utilizados de forma efetiva como ferramenta de gestão de projeto Cultura fundamentada no pragmatismo e automação de atividades repetitivas Integração entre sistemas de controle de versão e mudanças Introdução
Discussão Introdução
Alguns Fatos Mudança é inevitável Mudar é fácil – controlar diversas mudanças simultâneas é difícil A gerência de mudanças introduz controle sobre as mudanças de maior relevância Todas as mudanças são analisadas Apenas as aprovadas são realizadas Sempre se sabe quem modificou o que, onde e quando Introdução
Tradeoffs Controle de mudanças Automação do processo Nível de controle x overhead com o CCB Defeitos de magnitude menor podem ser tratados pelo líder de projeto diretamente Uso de versões draft de forma de minimizar controle de mudanças Automação do processo Custo x benefício Aquisição de ferramentas comerciais Uso de ferramentas open source Introdução
Sistemas de Controle de Versão
Controle de versão Controle de versão “conjunto de práticas cujo objetivo principal é manter controle sobre as modificações efetuadas em um determinado (conjunto) arquivo.” Utilizadas no contexto de uma Gerência de Versões Aplicados aos arquivos de um Projeto. Gerência de Versões CONTROLE DE VERSÃO (PRÁTICAS) Projeto
Sistemas de Controle de Versão (SCV) Ferramenta de apoio ao Gerenciamento de Versões De documentos, códigos fontes, etc. Permitem Automatizar o processo de controle de versão. Gerenciar o histórico, modificações e diferentes versões; Que várias pessoas trabalhem simultâneamente em um mesmo documento; Controlar as versões através de tags; Visualizar diferenças entre as versões; merging entre versões conflituosas;
O que não um SCV é? CVS não é a solução para todos os problemas! Mecanismo para backup Ferramenta para a construção de builds Substituto para comunicação entre desenvolvedores Conflitos não são resolvidos automaticamente Ferramenta de solicitação de mudanças Não controla requisições de mudança CVS não é a solução para todos os problemas! SCVs são utilizados dentro de um contexto maior, e possuem um papel específico. Veremos outras ferramentas, com outros papeis, ainda neste curso!
Arquitetura Cliente/Servidor Servidor mantêm Repositório centralizado arquivos a serem controlados, histórico de suas mudanças, log, etc. Obs.: A maioria dos servidores armazenam apenas as diferenças (deltas) entre versões sucessivas de um determinado arquivo (as somas das diferenças é capaz de produzir a versão mais nova). Clientes mantêm Área de trabalho (Workspace) cópia dos arquivos do repositório
Principais SCV OpenSource Concurrent Versions System (CVS) padrão de facto Referência para todas as outras ferramentas subseqüentes. Porém... tem perdido espaço para outras ferramentas com novas (e largamente requisitadas) funcionalidades. Subversion (SVN) Intenção: Substituto melhorado do CVS. Novas funcionalidades: Versionamento de diretórios; Commits atômicos; Suporte a diversas camadas de rede; Uso eficiente de rede.
Tendências Grande procura pelo SVN CVS é amplamente utilizado porém ... CVS é amplamente utilizado empresas de todos os portes. Ferramentas comerciais ClearCase Visual Studio Team System continuam a ser adotadas apenas em empresas de Grande Porte. Volume de buscas por clientes CVS e SVN Volume de ofertas de emprego por CVS e SVN
Comparação entre alguns SCVs SVN ClearCase VSTS Licença Open Source Comercial Formato Repositório Arquivos RCS [1] Relational DataBase [1] Atomic Commit Não Sim Copiar e Renomear Arquivos e Diretórios Merge Tracking Tags Sim[2] Conjunto de Comandos Simples Excelente Deployment Bom Médio [3] Fraco [3] Médio Velocidade Médio[4] Muito Bom Fraco [5] Portabilidade Fraco [1] Arquivos RCS podem ser alterados manualmente quando corrompidos, porém não suportam transações. [2] Suportado através de copias. [3] O ClearCase tem uma instalação difícil. O SVN tem uma instalação fácil, porém trabalhosa. [4] Para suportar segurança, o CVS precisa ser tunelado dentro de outros protocolos. [5] Servidor e clientes precisam estar na mesma rede para se obter uma performace aceitável. *Principais Fontes: Wikipedia Comparison e Better SCM Comparison
Fluxo de Trabalho com SVC
Modelos de “Versionamento” Lock-Modify-Unlock Copy-Modify-Merge Falsa noção de segurança. Mais problemas do que parece. Você só consegue alterar um arquivo se conseguir destravá-lo. Desenvolvedores esquecem arquivos travados freqüentemente! Dificulta uso off-line. Método recomendado Mais simples e prático. menos problemático do que você imagina Desenvolvedores podem trabalhar simultaneamente no mesmo arquivo. Livremente em seu workspace Facilita o uso off-line.
Desenvolvimento ideal Desenvolvedor A update checkin checkout Desenvolvimento Repositório Desenvolvedor B
X Desenvolvimento real Desenvolvedor A Resolução de conflito update checkin X checkin Repositório Desenvolvedor B conflito
Fluxo de Trabalho Comece sem nada. Faça as mudanças. Selecione um projeto em uma codeline (branch ou raiz) e selecione Checkout; ou update com a versão mais atual do repositório se o projeto já existe localmente. Faça as mudanças. Trabalhe localmente com o projeto, salvando as mudanças apenas na sua máquina; Sincronize, quando você estiver pronto Update; Examine as mudanças, faça as alterações necessárias; Rode os Testes; Commit;
Concurrent Versions System (CVS) Rodrigo Teixeira
Vantagens Concurrent Versions System (CVS) padrão de facto Projeto Open Source (GNU); Boa portabilidade Armazenamento inteligente de arquivos (Delta) Integração com várias ferramentas de desenvolvimento; Ferramentas utilizadas em sala Servidor Clientes
Ferramentas CVS Demonstração CVSNT Server WinCVS TortoiseCVS Eclipse Servidor CVSNT Server Servidor CVS para windows Site: www.cvsnt.org WinCVS Interface gráfica standalone Site: www.wincvs.org TortoiseCVS Integração do CVS ao Windows Explorer Site: www.tortoisecvs.org Eclipse Ambiente de Desenvolvimento Site: www.eclipse.org Clientes Demonstração
Exemplo de um servidor CVS CVS tem suporte nativo em sistemas unix/linux Um servidor gratuito windows: CVSNT Disponível em: http://www.cvsnt.org Exemplo para criar um novo repositório no CVSNT
WinCVS – Tela Principal Ícone de estado Tipo do arquivo Número da revisão nome do tag arquivos módulos status
TortoiseCVS Ícone de estado operações arquivos arquivos
Eclipse [Perspectiva Repository Explorer] Código Módulos e Arquivos Histórico e Tags
Usando WinCVS Configurações Iniciais Admin > Preferences... CVSROOT – Localização do repositório :pserver:{login}@{servidor}:{caminho do repositório} Authentication (autenticação) “passwd” file on the cvs server Admin > Login... Colocar a senha...
Comandos comuns cvs [opções do cvs] comando [opções do comando] [arquivos] Granularidade: projeto checkout module Copia arquivos do repositório para o workspace. Import module Copia arquivos locais para o repositório; Mecanismo de detecção se arquivo é binário ou texto. Granularidade: arquivo commit selection submete arquivos para o repositório. update selection atualiza a cópia de trabalho com o repositório. add e remove selection Adiciona e remove um arquivo ao repositório, respectivamente; Necessita posteriormente de um commit. Introdução
Comandos Comuns Rótulos e linhas de desenvolvimento Consultas Create a Tag - Rotula arquivos facilitar futuros updates e checkouts Comum em términos de uma iteração/release Atua diretamente no repositório Create a Branch Cria uma nova linha de desenvolvimento Análogo a tags Somente os arquivos selecionados e nas versões específicas do workspace é que farão parte do branch Consultas status e log Mostra o status e histórico de arquivos, respectivamente. diff Compara arquivos de trabalho com suas versões no repositório ou versões dentro do repositório
Exercício Simular a trabalho colaborativo e simultâneo de uma equipe de desenvolvimento. Dividir a sala em equipes de 2 ou 3 participantes; Eleger um participante como “líder”. Criar um novo repositório para um grupo de equipes; Exercitar os principais comandos CVS no WinCVS: Import de um módulo (líder); Checkout do modulo (demais participantes); Commit e Update; Adição de arquivos e Release de arquivos; Criar Tag e Branchs ; Merge entre codelines. Utilizar flags de edição (edit, reserved edit, etc) [opcional]
Subversion (SVN) Rodrigo Teixeira
Vantagens Subversion (SVN) Ferramentas utilizadas em sala Sucessor natural do CVS “Subversion has expanded beyond its original goal of replacing CVS” Novas funcionaldades: “Versionamento” de diretórios Commits atômicos Acesso via HTTP Open Source Boa portabilidade Integração com várias ferramentas de desenvolvimento; Site: http://subversion.tigris.org/ Ferramentas utilizadas em sala Servidor Clientes
Ferramentas CVS Demonstração VisualSVN RapidSVN TortoiseSVN Eclipse Servidor VisualSVN Servidor CVS para windows Site: www.visualsvn.com/server RapidSVN Interface gráfica standalone Site: rapidsvn. tigris.org TortoiseSVN Integração do SVN ao Windows Explorer Site: tortoisesvn.tigris.org Eclipse Ambiente de Desenvolvimento Plugins : subclipse.tigris.org www.eclipse.org/subversive/ Clientes Demonstração
Exercício Simular a trabalho colaborativo e simultâneo de uma equipe de desenvolvimento. Dividir a sala em equipes de 2 ou 3 participantes; Eleger um participante como “líder”. Criar um novo repositório para um grupo de equipes; Exercitar os principais comandos SVN no Eclipse: Import de um módulo (líder); Checkout do modulo (demais participantes); Commit Atômico e Update de vários arquivos; Synchronize View; Adição, release e rename de arquivos; Criar Tag e Branchs ; Merge entre codelines.
Referências Ferramentas CVS Windows Ferramentas SVN Servidor - CVSNT (www.cvsnt.org) Cliente - WinCVS (www.wincvs.org) Cliente - Tortoise (www.tortoisecvs.org) Diff/Merge - WinMerge (www.winmerge.org) Ferramentas SVN SubVersion (http://subversion.tigris.org) Livro - http://svnbook.red-bean.com/ Servidor - VisualSVN (http://www.visualsvn.com/server/) Cliente - Tortoise (tortoisesvn.tigris.org) Cliente - RapidSVN (rapidsvn. tigris.org) Plugin Eclipse (subclipse.tigris.org)
Integração Continua Introdução
Qual é o motivo destes problemas? Projetos de TI continuam ineficientes e imprevisíveis ... Qual é o motivo destes problemas? Introdução
Imaturidade no Desenvolvimento Por várias razoes, e em sua maioria, … Desenvolvimento de software continua imaturo. Ele atribui mais responsabilidades ao indivíduo para que ele tenha maior liberdade para exercer sua criatividade. Porem … Os desafios atuais exigem o desenvolvimento seja balanceado com uma abordagem mais automatizada e estruturada que otimize a produção e suporte a melhoria continua do produto e do processo." Introdução
Atividades de integração A integração de partes de um sistema normalmente é apenas perto de sua implantação Problemas são detectados tardiamente. em geral, é feita em freqüência inversamente proporcional à complexidade do sistema Dificuldade em rastrear as causas dos problemas É uma tarefa trabalhosa e sujeita a erros Quanto maior o sistema, mais difícil "Integração é uma das tarefas de desenvolvimento que pode se beneficiar, e muito, de um processo automatizado e estruturado." Introdução
Há alguns problemas, porém... Integração Contínua Geração freqüente (pelo menos diária) de builds do sistema partes do sistema integradas constantemente problemas de integração encontrados logo que introduzidos, na maioria dos casos Considerada uma das "melhores práticas" no desenvolvimento de software Usar o quadro para mostrar um cenário exemplo de integração contínua: Desenvolve de dia A noite gera um build e faz os testes De manha conserta erros e desenvolve mais Há alguns problemas, porém... Introdução
Builds construção complexa Introdução
Os Problemas na Geração de Builds Fazer builds do sistema manualmente pode ser muito demorado; é difícil de manter; não provê reuso entre equipes Gerências de builds builds não são disponíveis para toda a equipe. problemas em builds anteriores são ignorados; Dependências dos builds Pode ser difícil saber quais as versões "corretas" dos arquivos utilizados no build; Os pedaços do sistema podem estar em diversos locais diferentes; Alguns arquivos podem ser esquecidos Introdução
Sistema de Integração Contínua As Soluções Sistema de Controle de Versões (CVS, por exemplo) Manter todos os arquivos em um repositório central Controlar o acesso a esse repositório, de modo a garantir a consistência dos artefatos Automatizar o processo de geração de builds Gerenciar a execução dos builds e distribuir seus resultados. Build Script executa observa Sistema de Integração Contínua Introdução
ferramentas de build [Evolução] tendência Gerência de configuração de projetos Gerência de dependências de projetos Obs.: Cronologicamente o maven foi criado anteriormente ao Ivy. Porém o primeiro release do Ivy e do maven2 foram lançados na mesma época. Introdução
Comparação Maven vs Ant + Ivy Critério Ant + Ivy Maven Instalação Muito fácil Iniciar um novo projeto 5 min 15 min Nova funcionalidade 10 min para cada novo alvo 2 min para cada nova meta Aprendizado para um novo desenvolvedor 30 min. Facilidade para se entender e ferramental 2 horas. Pode ser confuso no início. Layout padrão? Não (pode ser bom, pois pode alterá-lo como quiser) Sim (pode ser bom, pois padroniza todos os projetos) Suporte a múltiplos projetos? Sim, mas você tem que criar toda a lógica p/ tratá-los. Sim, nativo com o Maven Reactor. Geração de documentação Nativamente, não, mas existem plug-ins. Sim Integração com IDEs? Sim e muito boa Sim, mas básica Gerência de dependências? Sim, através do plug-in Ivy Sim, nativo produtividade suporte Introdução
Ant Introdução
Ant Ferramenta para construção automática de builds Características: Open source/Java Facilmente extensível Build scripts escritos em XML Integração com diversas ferramentas de desenvolvimento e gerência de configuração Aumento sensível de produtividade Introdução
O que o Ant pode fazer por você... Copiar, apagar, mover arquivos e diretórios Acessar o CVS Compilar os arquivos fontes Gerar um JAR Executar uma bateria de testes Enviar um e-mail com os resultados dos testes Fazer um upload do build via FTP para o servidor de produção Mostrar um cenário pro pessoal ficar bem estimulado: Baixar do CVS Compilar Gerar um JAR Executar uma bateria de testes Fazer um figura mostrando esse cenário. Introdução
Buildfiles Buildfiles são scripts a partir dos quais o Ant gera builds Escritos em XML build.xml Ant Arquivos Executáveis Introdução
Estrutura de um buildfile <project> <property 1/> <property n/> <target 1> <task 1/> </target> <target n> <task n/> </project> O buildfile é composto de um projeto . . . O projeto pode possuir propriedades O projeto possui um conjunto de alvos . . . Cada alvo é formado por tarefas Colocar elementos de path aqui! Introdução
Projetos (projects) Elemento mais externo de um buildfile Cada projeto contém um conjunto de alvos Um projeto tem os seguintes atributos: Atributo Obrigatório name Não default Sim basedir Introdução
Projetos - Exemplo <project name="Projeto1" default="dist" basedir="."> (tarefas agrupadas em alvos...) </project> Introdução
Olá Mundo <?xml version="1.0" encoding="UTF-8" ?> <project name="ProjOla" default=“ola" basedir="."> <target name=“OlaMundo" > <echo message=“Ola, Ant trabalhando!" /> </target> </project> Introdução
Propriedades (properties) Um projeto pode ter um conjunto de propriedades Essas propriedades podem ser criadas através da tarefa property ou fora do Ant Propriedades podem ser usadas como valores para atributos de tarefas Isso é feito colocando-se o nome da propriedade entre "${" e "}" no valor do atributo Introdução
Propriedades - Exemplos <property file="build.properties"/> <property name="src" value="."/> <property name="dist" value="distribuicao"/> <property name="build" value="build"/> Definição <javac srcdir="${src}" destdir="${build}"/> <mkdir dir="${dist}/lib"/> <jar jarfile="${dist}/lib/build.jar" basedir="${build}"/> Uso Introdução
Propriedades Pré-Definidas Ant permite acesso às propriedades do sistema operacional Funciona como se as propriedades tivessem sido definidas com uma tarefa property As propriedades disponíveis estão listadas no javadoc de System.getProperties Além dessas, Ant possui algumas propriedades pré-definidas: basedir ant.file ant.version ant.project.name ant.java.version Introdução
Alvos (targets) Um alvo é um conjunto de tarefas que se quer executar Representa um objetivo a ser alcançado Exemplos: Criação dos diretórios usados no processo de geração do build Compilação dos arquivos-fonte Empacotamento dos arquivos compilados Introdução
Dependências entre Alvos Um alvo pode depender de outros alvos Se um alvo B depende de outro alvo, A, A será processado antes de B Uma dependência é indicada através do atributo depends de um alvo Exemplo: <target name="A"/> <target name="B" depends="A"/> <target name="C" depends="B"/> <target name="D" depends="C,B,A"/> Cada alvo é executado apenas uma vez! Introdução
Exemplo Check-out no CVS Criar estrutura de pastas Compilar arquivos fonte Fazer a instalação Executar bateria de testes Enviar e-mails com resultados dos testes Registrar resultado dos testes Introdução
Execução Condicional de Alvos É possível especificar que um alvo só será executado se: Uma propriedade estiver setada Uma propriedade não estiver setada Exemplos: <target name="construa_o_modulo_A" if="modulo_A_presente> <target name="construa_o_modulo_A_falso" unless="modulo_A_presente> Introdução
Atributos de um Alvo name Um alvo tem os seguintes atributos: depends Obrigatório name Sim depends Não if unless description O conteúdo do atributo description é exibido quanto o Ant é invocado com a opção –projecthelp. Introdução
Tarefas (tasks) Um pedaço de código que pode ser executado Unidades básicas de um buildfile Uma tarefa pode ter diversos atributos A distribuição do Ant já inclui um conjunto básico de tarefas Um pacote com tarefas adicionais também está disponível Introdução
Tarefas - Exemplos copy – Copia um arquivo ou conjunto de arquivos jar – Empacota um conjunto de arquivos em um arquivo .jar cvs – Executa comandos do CVS javac – Compila um conjunto de arquivos fontes Java mkdir – Cria um novo diretório Introdução
Tarefa tstamp Guarda informação temporal referente a quando a tarefa foi executada DSTAMP – Formato aaaammdd TSTAMP – Formato hhmm TODAY – Formato mês dia ano Permite formatação da data Exemplo <tstamp/> Introdução
Tarefa copy Copia arquivos e diretórios Um arquivo é copiado apenas se o arquivo fonte é mais novo que o destino (caso este último exista) Sobre-escrita pode ser explicitada Introdução
Tarefa copy (exemplos) 1. <copy file="meuArq.txt" tofile="minhaCopia.txt"/> 2. <copy file="meuArq.txt" todir="../algum/dir"/> 3. <copy todir="../novo/dir"> <fileset dir="dir_fonte"/> </copy> 4. <copy todir="../novo/dir"> <fileset dir="${dist}" casesensitive="yes"> <patternset> <include name = "**/*.java" /> <exclude name = "**/*Test*" /> </patternset> </fileset> FileSets são usados também em outras tarefas como delete, rename e move. Introdução
Tarefa delete Apaga arquivos e diretórios Exemplos: 1. <delete file="/lib/ant.jar"/> 2. <delete dir="lib"/> 3. <delete> <fileset dir="." includes="**/*.bak"/> </delete> 4. <delete includeEmptyDirs="true" > <fileset dir="build" /> Introdução
Tarefa echo Escreve uma mensagem no console do usuário ou em um arquivo Exemplos: 1. <echo message="Alo mundo!"/> 2. <echo> Essa mensagem é bem maior, ocupando mais de uma linha. </echo> 3. <echo file="build.log" append="true"> Esta mensagem será escrita em um arquivo! Introdução
Tarefa cvs Lida com módulos contidos em um repositório CVS Exemplos: 1. <cvs cvsRoot=":local:/arquivos/cvspublico" package="qib" dest="${build}" /> 2. <cvs dest="${dist}" command="update"/> 3. <cvs command="-q diff -u -N" output="difs.txt"/> 4. <cvs command="update -A -d"/> A tarefa CVS precisa do CVS para rodar? Introdução
Tarefas mkdir e mail mkdir - Cria uma árvore de diretórios mail - Manda uma mensagem de e-mail via STMP sem anexos <mkdir dir="${dist}/lib/temp"/> <mail from="suporte@qualiti.com.br" tolist="admin@qualiti.com.br" subject="Resultados do build noturno" files="build.log"/> Introdução
Tarefa javac Compila uma árvore de arquivos fonte Java É possível escolher um compilador diferente através da propriedade build.compiler Filesets podem ser usados para definir os alvos da compilação classic modern jikes jvc gcj sj Introdução
Tarefa javac (exemplos) 1. <javac srcdir="${src}" destdir="${build}" classpath="bib.jar" /> 2. <javac srcdir="${src}" destdir="${build}" includes="meupacote/p1/**, meupacote/p2/**" excludes="meupacote/p1/pacotetestes/**" 3. <javac destdir="${build}" classpath="bib.jar"> <src path="${src}" /> <src path="${src2}" /> <include name="meupacote/p1/**" /> <include name="meupacote/p2/**" /> <exclude name="meupacote/p1/pacotetestes/**" /> </javac> Introdução
Tarefa java Executa uma classe Java na máquina virtual atual ou inicia outra, se especificado Exemplos: 1. <java classname="teste.Principal" /> 2. <java classname="teste.Principal" > <arg value="-h"/> <classpath> <pathelement location="\test.jar" /> <pathelement path="${java.class.path}" /> </classpath> </java> Introdução
Tarefa jar Cria um arquivo .jar contendo os arquivos especificados <jar jarfile="${dist}/lib/app.jar" basedir="${build}/classes" /> 2. <jar jarfile="${dist}/lib/app.jar" basedir="${build}/classes" excludes="**/Test.class" /> 3. <jar jarfile="${dist}/lib/app.jar"> <fileset dir="${build}/classes" <fileset dir="${src}/resources" /> </jar> Introdução
Execução de vários test cases Tarefa <junit> Permite a execução de testes JUnit; Opcionalmente, cria dados (xml) para a geração posterior de relatórios Exemplo: <junit printsummary="yes" haltonfailure="true"> <classpath refid="test.classpath"/> <formatter type="xml"/> <test name="org….HtmlDocumentTest"/> <batchtest todir="${test.data.dir}"> <fileset dir="${test.dir}” includes="**/*Test.class” /> </batchtest> </junit> Saída XML Tags <test> executão somente uma classe de teste. Tags <batchtest> podem executar mais de uma. O parâmetro hatonfailure interrompe todos os testes quando ocorrer a primeira falha. O todir em <batchtest> é usado para indicar a saída dos testess (neste caso arquivos do tipo XML). Execução de vários test cases Junit
Tarefa <junitreport> Permite a geração de relatórios HTML de testes JUnit realizados anteriormente. Exemplo: <junitreport todir="${test.data.dir}"> <fileset dir="${test.data.dir}"> <include name="TEST-*.xml"/> </fileset> <report format="frames” todir="${test.reports.dir}" /> </junitreport> EntradaXML Usa XSLT para gerar páginas HTML a partir de XMLs de saída de testes já realizados. Pode ser customizado para que os relatórios possuam Ou não frames. Junit
Exemplo de relatório <junitreport>
Um Exemplo de Buildfile <project name="MeuProjeto" default="dist" basedir="."> <property name="src" value="."/> <property name="build" value="build"/> <property name="dist" value="dist"/> <target name="init"> <tstamp/> <mkdir dir="${build}"/> </target> <target name="compile" depends="init"> <javac srcdir="${src}" destdir="${build}"/> Introdução
Um Exemplo de Buildfile (continuação) (...) <target name="dist" depends="compile"> <mkdir dir="${dist}/lib"/> <jar jarfile="${dist}/lib/ MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean"> <delete dir="${build}"/> <delete dir="${dist}"/> </project> Introdução
Executando o Ant Sintaxe padrão: Opções ant [opções] [alvos] -help -projecthelp -version -quiet -verbose -debug -emacs -logfile arquivo -logger nomeClasse -listener nomeClasse -buildfile arquivo -find arquivo -Dpropriedade=valor Introdução
Exemplos ant Executa o Ant usando o buildfile build.xml no diretório atual, a partir do alvo padrão Executa o Ant usando o arquivo test.xml no diretório atual, a partir do alvo padrão ant –buildfile test.xml Demonstração Introdução
Exemplos (continuação) ant –buildfile test.xml dist Executa o Ant usando o arquivo test.xml no diretório atual, a partir do alvo dist ant –buildfile test.xml –Dvar=classes dist Executa o Ant usando o arquivo test.xml no diretório atual, a partir do alvo dist, setando o valor da propriedade var para classes. Introdução
Exercício Escrever um script build.xml de uma aplicação exemplo que: Compile o código fonte java principal da aplicação Gere Javadoc do projeto Compile o código fonte java de teste do aplicação Execute o código de teste Empacote a aplicação em um arquivo jar
Boas Práticas Projete seus scripts Aumentar produtividade e reuso Padronize e simplifique scripts (Keep It Simple Sir) Aumentar produtividade e reuso Dentro e entre projetos <macrodef> permite que você defina "métodos privados" com parâmetros, chamados atributos <import> pode ser usado para realizar "herança" entre scripts (definir um script genérico para todos projetos) Gerencie dependências com bibliotecas Gerenciar de dependências: Ivy Introdução
Exemplo de reuso com <macrodef> <target name="compile"> <compilecode srcdir= "${source.java.dir}" classpath="classpath.main"/> <compilecode srcdir= "${unit.test.source.dir}" classpath="classpath.test“ includeant="true" /> </target> <macrodef name="compilecode"> <attribute name="srcdir"/> <attribute name="includeant" default="false"/> <attribute name="classpath"/> <sequential> <javac srcdir="@{srcdir}" destdir="${compile.dir}" classpathref="@{classpath}" includeAntRuntime="@{includeant}" debug="${compile.debug}" debugLevel="${compile.debugLevel}" deprecation="${compile.deprecation}" optimize="${compile.optimize}" /> </sequential> </macrodef> Demonstração Introdução
Exemplo de reuso com <element> e <macrodef> <doTests fork=”no”> <whatToTest> <test fork="yes“ haltonerror="false" haltonfailure="false“ name="@{className}" todir="${junit.report.dir}"/> </whatToTest> </doTests> <macrodef name="doTests"> <attribute name=”fork” default=”no”/> <element name="whatToTest" optional="no"/> <sequential> <junit printsummary="on" fork="@{fork}" showoutput="true" haltonfailure="false“ failureproperty="test.failed" errorproperty="test.failed"> <sysproperty key="app.root.dir" value="${app.root.dir}"/> <sysproperty key="fromant" value="yep"/> <classpath refid="runtest.classpath"/> <formatter type="xml"/> <formatter type="brief" usefile="false"/> <jvmarg value="-Demma.coverage.out.file=${coverage.dir}/metadata/coverage.emma"/> <jvmarg value="-Demma.coverage.out.merge=true"/> <whatToTest/> </junit> </sequential> </macrodef> Qualquer coisa pode ser inserida no macrodef utilizando <element> Uso do Macrodef Definição do Macrodef Introdução
Exemplo de reuso com <import> generico-build.xml build.xml <?xml version="1.0"?> <project name="master" > <target name=“clean" > <echo >Limpa Geral</echo> </target> <target name="compile" depends="init"> <echo >Compila Geral</echo> </project> <?xml version="1.0"?> <project name="cr" basedir=".." > <import file="master-build.xml"/> <target name= "clean" > <echo> Limpa Especifico</echo> </target> <target name="deploy" depends="compile"/> <target name="init" depends="clean" /> </project> ant deploy Buildfile: build.xml clean: [echo] Limpa Filho init: compile: [echo] Compila Geral deploy: BUILD SUCCESSFUL Saída Observações: Clean é sobreescrito em build.xml Init não é definido em generico-build.xml deploy utiliza compile em generico-build .xml Demonstração Introdução
Exercício Refatore o build.xml da aplicação utilizando: A tarefa <macrodef> para promover reuso; Extrair tarefas comuns à vários projetos para um build “genérico” Utilizar a tarefa <include>
Onde encontrar o Ant http://ant.apache.org/ Site oficial do projeto Documentação extensiva Diversas versões disponíveis Pacotes com tarefas adicionais http://ant-contrib.sourceforge.net/ Projeto Sourceforge com vários ant tasks úteis Apresentação de boas práticas em scripts Ant Writing Better Ant Scripts: Techniques, Patterns and Antipatterns, Douglas Bullard. www.pjug.org/docs/ant.pdf Introdução
Instalando o ANT Download do Ant 1.7.1 ou superior http://maven.apache.org/download.html Baixar e descompactar o arquivo: apache-ant-1.7.1-bin.zip No diretório ${INSTALACAO} Criar a variável ANT_HOME apontando para o diretório ${INSTALACAO}. Adicionar o diretório ${ANT_HOME}/bin à variável PATH. Verificando instalação: $>ant -version Apache Ant version 1.7.1 compiled on June 27 2008 Introdução
Gerenciando Dependências com Ivy Introdução
O que é mais descritivo? Algo assim ... <fileset dir="${global.lib.dir}"> <include name="commons-beanutils.jar"/> <include name="commons-collections.jar"/> <include name="commons-digester.jar"/> <include name="commons-logging.jar"/> <include name="commons-validator.jar"/> <include name="commons-resources.jar"/> <include name="jakarta-oro.jar"/> <include name="struts.jar"/> <include name="struts-el.jar"/> <include name="commons-lang.jar"/> <include name="jstl.jar"/> <include name="standard.jar"/> <include name="commons-pool.jar"/> <include name="displaytag.jar"/> </fileset> Introdução
O que é mais descritivo? ... Ou assim ... <dependencies> <dependency org="org.hibernate" name="hibernate" rev="3.2.0.ga" conf="dist-ear,source,javadoc"/> <dependency org="org.apache" name="log4j" rev="1.2.8" conf="dist-ear"/> <dependency org="org.apache" name="struts" rev="1.3.8" conf="dist-ear"/> <dependency org="org.apache" name="struts-el" rev="1.3.8" conf="dist-ear"/> <dependency org="org.springframework" name="spring" rev="2.0" conf="dist-ear"/> </dependencies> Introdução
Por que um Gerenciador de Dependências? Sistemas dependem cada vez mais e mais de componentes complexos Precisamos gerenciar conflitos entre versões Garantir a reproducibilidade dos builds Não reinvente a roda: reuse Sistemas modularizados e flexiveis são fáceis de desenvolver e manter Gerenciar Dependências: Metodologia Ágel Introdução
Ivy + Ant Ivy projeto Apache |Site: http://ant.apache.org/ivy/ Gerência de dependências similar Maven2 (Ant + Ivy ~= Maven2) Permite que controlemos quais versões estão disponíveis Versões diferentes podem ser usadas em diferentes projetos Suporta dependências transitivas [dependências das dependências, ..., etc] Download das dependências do projeto, e daquelas que elas dependem Dependências são descritas em um arquivo específico Funcionamento: ibiblio Maven2 Empresa repositório empresa repositório local dir. /lib do projeto 1. download 2. armazena Introdução
Exemplos de repositórios: Local e Remoto Introdução
Instalando Ivy O Ivy normalmente é utilizado como um plugin ANT Você colocar seu jar no diretório lib do ANT_HOME Ou, criar um target para fazer o download sob demanda <target name="install-ivy" description="--> install ivy"> <mkdir dir="${ivy.jar.dir}"/> <get src="${ivy.download.url}" usetimestamp="true" dest="${ivy.home}/${download.ivy.binaryfile}" /> <untar src="${ivy.home}/${download.ivy.binaryfile}" dest="${ivy.home}" overwrite="false" compression="gzip" /> <taskdef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpath="${ivy.jar.file}"/> </target> Introdução
Dependência Inline Para recuperar dependencia com Ivy: basta adicionar uma tarefa Ivy (inline) no build build.xml <ivy:retrieve organisation="org.apache.struts" module="struts2-core" revision="2.0.5" inline="true"/> Notice the inline=« true » attribute, which tells Ivy that dependency is declared directly in the task. This is not the most common way to use Ivy (see second example), but it’s the easiest. When you launch this task, Ivy look for the dependency declared in maven 2 repository (http://repo1.maven.org/maven2) and uses maven 2 poms to get dependency metadata and get transitive dependencies. gera Demonstração Managing your dependencies with Ivy - Apache Con EU 2007
Arquivos Ivy Ajudam a separar declarações de dependências dos scripts de build build.xml <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]"/> utiliza ivy.xml gera Demonstração Introdução
Arquivos Ivy <ivy-module version="1.5"> <info organisation="org.apache.ivy" module="ivy-demo-2" /> <configurations> <conf name="runtime"/> <conf name="test"/> </configurations> <dependencies> <dependency org="org.apache.struts" name="struts2-core" rev="2.0.5" conf="runtime->default"/> <dependency org="junit" name="junit" rev="3.8.1" conf="test->*"/> </dependencies> </ivy-module> Introdução
<ivy:report todir="report"/> build.xml <ivy:report todir="report"/> Introdução
Entendendo as dependências Introdução
Dependências entre projetos Ivy pode ser usado para resolver: Dependências externas (com bibliotecas de terceiros) Dependências internas (entre projetos) project A local repository publica recupera recupera project B shared repository Demonstração
Arquivo Ivy <ivy-module version="1.5"> <info organisation="org.apache.ivy" module="ivy-demo-3-B" /> <configurations> <conf name="runtime"/> <conf name="test"/> </configurations> <dependencies> <dependency org="org.apache.struts" conf="runtime->default" name="struts2-core" rev="2.0.5" /> <dependency name="ivy-demo-3-A" rev="latest.integration" /> </dependencies> </ivy-module> The only change in the ivy file compared to previous example is the use of « latest.integration » version constraint, instead of a static revision. Many version constraints can be used out of the box with Ivy, like 1+ to get the latest version starting with 1, or version ranges, following the same notation as maven 2 one. See http://incubator.apache.org/ivy/doc/ivyfile/dependency.html for details. Managing your dependencies with Ivy - Apache Con EU 2007
Exercício Crie um arquivo ivy.xml para gerenciar as dependências da aplicação.
Onde Você pode encontrar o Ivy http://incubator.apache.org/ivy Site oficial do projeto Documentação Plugins Eclipse http://ant.apache.org/ivy/ivyde/ Introdução
Maven2 Introdução
Maven2 Maven2 reúne: que: novas idéias, padrões e software (suporte); Assim como o Ant, o Maven também é uma ferramenta de build. Mas não é só isso... Maven2 reúne: novas idéias, padrões e software (suporte); que: facilita a gerência de configuração e facilita o trabalho colaborativo. Introdução
Principios Maven Baseado em padrões e boas-práticas "patterns help create a shared language for communicating insight and experience about problems and their solutions" (Christopher Alexander) Introdução
Projeto Maven A configuração do produto de software é descrita por modelo: POM - Project Object Model (arquivo .pom) Conceitos que interagem com esse modelo Motor de build Plugins Repositório de artefatos pom.xml Artefato Motor Maven 2 Plugins Introdução
Princípios Convenção sobre configuração (convention over configuration) Reutilização da lógica de build Ciclo de vida padronizado, mais flexível Execução declarativa Gerência coerente de dependências Introdução
Convenção sobre configuração Estrutura de diretórios padronizadas Estrutura semenhante para todos os projetos Artefatos Maven Apenas um artefato principal por projeto Padrão para nomes de artefatos Introdução
Artefatos Artefatos geralmente são empacotados na forma de bibliotecas Java (JAR). Cada artefator possui um identificador único (coordenada) Group Id: Organização responsável pelo artefato Artefact Id: Nome do artefato Versão: número de versão para o artefato <project...> ... <groupId>com.minhacompanhia.contabilidade</groupId> <artifactId>contabilidade-core</artifactId> <packaging>jar</packaging> <version>1.1</version> <name>Pacote básico de contabilidade</name> com/minhacompanhia/ contabilidade / contabilidade -core/1.1/ contabilidade -core-1.1.jar Introdução
Ciclo de vida padronizado Generalização e padronização das fases da build Não reinventa a roda ! O Maven 2 vem de fábrica com 3 ciclos de vida de build default, clean e site Exemplos de fases do ciclo default Plugins agrupam tarefas relacionadas As tarefas do ciclo default dependem do valor da tag <packaging> (ex.: jar, war) Introdução
Plug-ins A maior parte das tarefas executadas pelo Maven são feitas por meio de plug-ins. Um plug-in é formado por um ou mais mojos, que são as menores unidades de execução do Maven. Alguns plug-ins estão associados a fases do ciclo de vida e são executados automaticamente. Por exemplo, o plugin maven-compile é executado para a fase compile Uma meta (goal) são tarefas no Maven. Ao executar um mojo, estamos executando uma meta. Exemplo: mvn jar:jar Introdução
Gerência de Depêndencias declarativa Abordagem declarativa “just tell me what you need” Cada projeto “declara” as bibliotecas que precisa Artefatos “versionados” são armazenados em um repositório central Dependências transitivas são resolvidas automaticamente Depêndencias internas ou externas Escopo das dependências Convenções sobre as versões X.Y.Z-qualificador SNAPSHOT - indica que projeto está em desenvolvimento. Introdução
UTILIZAÇÃO DOS PRINCIPAIS RECURSOS MAVEN Introdução
Instalando o Maven 2 Download Maven 2.0.9 ou superior http://maven.apache.org/download.html Baixar e descompactar o arquivo: apache-maven-2.0.9-bin.zip No diretório ${INSTALACAO} Criar a variável M2_HOME apontando para o diretório ${INSTALACAO}. Adicionar o diretório ${M2_HOME}/bin à variável PATH. Verificando instalação: $> mvn -version Maven version: 2.0.9 Java version: 1.6.0_07 Introdução
Criando um novo projeto Maven Plugin: maven-archetype-plugin Exemplo: mvn archetype:create -DgroupId=curso.maven -DartifactId=maven-01-base Plugin: maven-eclipse-plugin Prepara o projeto para ser importado na IDE Eclipse Comando: mvn eclipse:eclipse Introdução
Suporte no Eclipse Plugin m2eclipse provê um bom suporte para Maven criar projetos, gerenciar dependência, etc Demonstração Introdução
Plug-in Archetype Permite criar a primeira versão do POM para o projeto Existem vários modelos de projetos disponíveis Para visualizar a lista, use o comando: mvn archetype:generate Exemplo da criação de uma aplicação web: mvn archetype:create -DgroupId=curso.maven -DartifactId=exemploWeb -DarchetypeArtifactId=maven-archetype-webapp Introdução
Alterando POM Alterar a forma de empacotamento Alterar o nome e a URL do projeto Adicionar dependências Configurar plugins packaging>jar</packaging> name>Projeto Curso Maven</name> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <plugin> <artifactId>maven-compiler-plugin </artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> Introdução
Executando fases e mojos Para compilar o projeto, execute a fase: mvn compile Para testar, execute a fase test: mvn test Para empacotar o projeto (no exemplo, um JAR): mvn package mvn jar:jar para instalar a biblioteca no repositório local: mvn install Para gerar a documentação: mvn javadoc:javadoc Para resolver dependências: mvn dependency:resolve Introdução
Adicionando Plugins Plugins podem ser úteis para prover informações adicionais sobre o projeto Cobertura Mostra a cobertura dos testes unitários CheckStyle: Verifica formatação e padrão de código PMD : Verifica más práticas e locais que podem potencialmente gerar bugs. FindBugs: Similar ao PMD, porém com uma heurística diferente que gera menos falsos-positivos. Introdução
Exemplo: Adicionando plugins ao build <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.2</version>[*] <configuration> <instrumentation> <excludes> <exclude>**/*Test.class</exclude> </excludes> </instrumentation> </configuration> </plugin> </plugins> </build> [Configuração opcional] Exclui os códigos de teste da verificação Introdução
Exemplo:Adicionando Plugins de Relatórios <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-plugin</artifactId> </plugin> <plugin> <artifactId>maven-checkstyle-plugin</artifactId> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-pmd-plugin</artifactId> </plugins> </reporting> Introdução
Criando um Repositorio na Intranet Precisamos mudar o ~.m2/settings.xml para criar um mirror dos servidores externos Empresa repositório empresa 1.download 2. armazena ibiblio Nx repositório local dir. /lib do projeto Maven2 Demonstração | 316 Introdução
Deploy um Artefato no Maven pom.xml <project> ... <distributionManagement> <snapshotRepository> <id>snapshots</id> <name>Internal Snapshots</name> <url>http://servidor:8081/nexus/content/repositories/snapshots</url> </snapshotRepository> </distributionManagement> </project> mvn deploy Introdução
Exercício Criar um projeto Maven2 com suporte para Eclipse Incluir as seguintes dependências: commons-lang:commons-lang:jar:2.4:compile commons-collections:commons- collections:jar:2.0:compile org.hibernate:hibernate:jar:3.2.6.ga:compile Excluir a dependência: javax.transaction:jta Incluir os seguintes plugins na build: Cobertura Gerar o site do projeto: mvn site Incluir plugins nos relatórios do site PMD, Checkstyle, FindBugs, Cobertura Gerar novamente o site
Boas Práticas Mantenha um projeto modularizado Herança Agregação herde propriedades e compontamento de projetos pais Opção <parent> Artefato </parent> do projeto Agregação Organize projetos em vários módulos Introdução
Onde Você pode encontrar o Maven2 http://maven.apache.org Site oficial do projeto Documentação http://www.sonatype.com/book/ Maven: The Definitive Guide Open Source Book Plugins Eclipse http://m2eclipse.codehaus.org/ Introdução
Sistemas de Integração Contínua Introdução
Sistemas de Integração Continua São executadas em uma maquina de integração, Utilizam build scripts, como o ANT e Maven. Possuem boa integração com repositórios CVS e SVN Possuem vários plugins como para análise de métricas de código Exemplos de boas ferramentas gratuitas: Hudson, Continuum, CruiseControl. Dispara Procedimento 1 - Realiza um build; 2 - Executa testes; 3 – Realiza Análises; 4 - Publica resultados. Script (ANT) Observa Mudanças Repositório Central (CVS) Máquina de Integração
Boas Práticas Utilizar builds automáticos em integrações continuas Realizar Builds de Integração em todos os ambientes Manter a consistência dos scripts de builds antes de publicá-los (evitar builds quebrados) Incluir testes automáticos e abrangentes nos builds Testes de integração, sistema, funcionalidaed, etc. Garantir commit task no controle de versões Gerenciar e publicar os builds Guardar os histórico dos builds para futuras análises e otimizações Introdução
Hudson https://hudson.dev.java.net/ Site oficial do projeto Documentação Download Demonstração Introdução
Outras Leituras The Top 10 Blunders In Integration And Testing ... And How To Avoid Them, borland white paper, Março/2007 Automation for the people (Paul Duvall, developerWorks): http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=automation+people: Introdução
Bugzilla Introdução
O que é Bugzilla? Uma ferramenta para controle de defeitos (bugs) e melhorias em sistemas Pode ser usado como uma ferramenta para gerência de mudanças Pode controlar os defeitos de vários sistemas ao mesmo tempo Introdução
Vantagens Simples de usar Freeware Código aberto (open source) Poucos comandos Freeware Código aberto (open source) Permite customizações Uso pela Web Flexível no que concerne à realização de consultas Suportado por uma grande comunidade de usuários Introdução
Desvantagens Documentação pouco detalhada Segurança Login apenas para controle do processso e não controle de acesso A senha dos usuários é visível para o administrador Qualquer usuário pode criar um novo usuário Uso de cookies Limitado do ponto de vista de relatórios Queries na base MySQL Introdução
Estrutura do bugzilla Produto Componentes Software, sistema ou processo que estará sujeito ao controle de mudanças Pode ter diversas versões cadastradas Componentes Representa módulos do produto Fica sob a responsabilidade de um usuário
Status dos Defeitos Estados Abertos NEW Bug inserido por alguém (automático) Aceito a ASSIGNED Reatribuído a NEW Resolvido a RESOLVED ASSIGNED Atribuído à pessoa apropriada REOPENED Reaberto: foi constatado que ainda não tinha sido resolvido UNCONFIRMED Não confirmado que existe Confirmado a NEW Introdução
Mais Status dos Defeitos Estados Fechados RESOLVED Foi resolvido (só está esperando a homologação) Não foi resolvido a REOPENED Está ok a VERIFIED Está ok e pode ser fechado a CLOSED VERIFIED A correção foi homologada Defeito é fechado a CLOSED CLOSED O bug é tido como resolvido Introdução
Resoluções Válida apenas para estados fechados FIXED INVALID WONTFIX Foi consertado e testado INVALID O problema descrito não é bug WONTFIX O problema descrito é um bug que nunca será corrigido LATER O problema descrito é um bug que não será corrigido nessa versão do produto DUPLICATE O problema é uma duplicação de um bug já existente (é preciso registrar o número do bug correspondente) REMIND O problema descrito é um bug que provavelmente não vai ser consertado nessa versão do produto, mas pode ser que seja WORKSFORME Não foi possível reproduzir o bug e verificando o código não há indícios de que o comportamento ocorra. Se aparecerem mais informações depois, será reaberto. Introdução
Ciclo de Vida de um Bug Introdução
Tipos de usuários Não existe o conceito de tipos de usuários Os perfis dos usuários são definidos através das permissões Administrador Possui todas as permissões Cadastra usuários, produtos, configura parâmetros, etc. Desenvolvedor Permissão mínima Edita bugs para os quais ele está qualificado (owner ou reporter) Introdução
Bugzilla – Tela Inicial Introdução
Bugzilla – Menu de Operações Introdução
E agora vamos dar uma olhada no Bugzilla... Introdução
Comparação entre Sistemas de Controle de Mudanças O Bugzilla continua a ser amplamente utilizado, porém Difícil instalação Difícil integração com outros sistemas de controle de versão. Uma alternativa é o Trac, que possui Fácil integração com o CVS e o SVN Fácil Administração Criação de páginas Wiki Outra alternativa é o Mantis Simples Fácil de Instalar