Gerência de Configuração

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 rel_1_fix tag 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 ( ) 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

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

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

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.> Identificação de itens de configuração Nomeação dos itens de configuração Aquisição e armazenamento de itens de configuração 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

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.> Identificação das necessidades de informação Mecanismos de coleta de informações Relatórios, seus conteúdos e frequências 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.> Auditorias que devem ser realizadas Procedimentos de auditoria Introdução

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

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

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: WinCVS Interface gráfica standalone Site: TortoiseCVS Integração do CVS ao Windows Explorer Site: Eclipse Ambiente de Desenvolvimento Site: Clientes Demonstração

Exemplo de um servidor CVS
CVS tem suporte nativo em sistemas unix/linux Um servidor gratuito windows: CVSNT Disponível em: 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 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: Ferramentas utilizadas em sala Servidor Clientes

Ferramentas CVS Demonstração VisualSVN RapidSVN TortoiseSVN Eclipse
Servidor VisualSVN Servidor CVS para windows Site: 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 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 ( Cliente - WinCVS ( Cliente - Tortoise ( Diff/Merge - WinMerge ( Ferramentas SVN SubVersion ( Livro - Servidor - VisualSVN ( 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 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 s 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 via STMP sem anexos <mkdir dir="${dist}/lib/temp"/> <mail 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 destdir="${compile.dir}" 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“ todir="${junit.report.dir}"/> </whatToTest> </doTests> <macrodef name="doTests"> <attribute name=”fork” default=”no”/> <element name="whatToTest" optional="no"/> <sequential> <junit printsummary="on" 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 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. Introdução

Instalando o ANT Download do Ant 1.7.1 ou superior
 Baixar e descompactar o arquivo: apache-ant 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 compiled on June 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 ( 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 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
Site oficial do projeto Documentação Plugins Eclipse 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 ou superior Baixar e descompactar o arquivo: apache-maven 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> </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
Site oficial do projeto Documentação Maven: The Definitive Guide Open Source Book Plugins Eclipse 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): 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

Gerência de Configuração

Apresentações semelhantes

Apresentação em tema: "Gerência de Configuração"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Gerência de Configuração

Apresentações semelhantes

Apresentação em tema: "Gerência de Configuração"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback