Gestão de Configuração de Software Ágil

GestãoGestão de de ConfiguraçãoConfiguração de de SoftwareSoftwareSoftwareSoftware-- GCS GCS ÁgilÁgil --

ES06 – Especialização em Engenharia de Software

Prof.: Misael Santos ([email protected])

Ago/2010

Agenda� Desenvolvimento Ágil

� Manifesto Ágil� Práticas

� Metodologias Ágeis� XP

� Integração Contínua� Integração Contínua

� GCS Ágil

� Padrões de Software� Conceitos

� Tipos de Padrões

� SCM Patterns

Copyright © 2010 Misael Santos2

Gestão de Configuração de Software

Desenvolvimento Ágil� O peso dos processos de software

� Busca pela formalização das práticas mais próximas do real

� Pensamento Nike (Just-Do-It)



Desenvolvimento Ágil� Origem dos métodos ágeis

�Anos 80 (Code-and-Fix)� Processos unificados (UP)� Processos seqüenciais e burocráticosProjeto C3 (Chrysler)� Projeto C3 (Chrysler)

�Manifesto ágil�Agile Alliance (http://www.agilealliance.org/)



Manifesto Ágil“Estamos evidenciando maneiras melhores de desenvolversoftware fazendo-o nós mesmos e ajudando outros a fazê-lo.

Através desse trabalho, passamos a valorizar:

Software em funcionamentomais que documentação abrangente

Indivíduos e interação mais que processos e ferramentas;

Colaboração com o clientemais que negociação de contratos;

Responder a mudanças mais que seguir um plano.

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.”



Métodos Ágeis� Extreme Programming

� Scrum

� OpenUp

� Pragmatic Programming

� Feature Driven Development (FDD)

� Crystal

� Adaptive Software Development

� Dynamic Systems Development Method (DSDM)

� Agile Lean Development (LD)



Extreme Programming (XP)

A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer o x vermelho, poderá ser necessário excluir a imagem e inseri-la novamente.



Extreme Programming (XP)� É formado por um conjunto de valores, princípios e práticas

� Ao contrário do que os gurus pregam, o XP pode ser usado com CMM e UPs como atestam alguns estudos específicos nos últimos anosespecíficos nos últimos anos

� A preocupação não é com qualidade e sim com a saúde do sistema (Kent Beck)




� Humanidade� Economia� Benefício mútuo� Similaridade própria� Progresso� Diversidade� Reflexão

� Comunicação

� Simplicidade

� Feedback

Princípios

Valores

� Reflexão� Fluxo� Oportunidade� Redundância� Falha� Qualidade� Passos-de-bebê� Aceite� Responsabilidade

� Feedback

� Coragem

� Respeito




�Práticas Primárias (1)�Ambiente Informativo

� Build de Dez Minutos

�Ciclo Semanal�Ciclo Semanal

�Ciclo Trimestral

�Desenvolvimento Orientado a Testes (TDD)

�Design Incremental



Extreme Programming (XP)�Práticas Primárias (2)

� Equipe Integral� Folga�Histórias� Integração Contínua� Programação em Par� Sentar-se Junto� Trabalho Energizado



Extreme Programming (XP)� Práticas Corolárias (1)

� Análise da Raiz do Problema� Base de Código Unificada� Código Coletivo� Código e Testes� Continuidade da Equipe� Continuidade da Equipe� Contrato de Escopo Negociável� Envolvimento Real do Cliente� Equipes que Encolhem� Implantação Diária� Implantação Incremental



Extreme Programming (XP)� Práticas Corolárias (2)

� Pagar Por Uso� Metáforas� Refatoração (Refactoring)� Padrões de Projeto (Design Patterns)� Padrões de Projeto (Design Patterns)� 40 horas semanais� Jogo do Planejamento� Reuniões em Pé� Padrões de Codificação



Extreme Programming (XP)� Agile Change Management

�Não devemos tratar o processo de gestão de mudançascomo processo de prevenção de mundaças.

�Aceitar bem as mudanças nos requisitos, mesmo em fases avançadas do projeto.fases avançadas do projeto.



Integração Contínua� Código novo é integrado com o sistema atual em algumas horas. Na integração o sistema é “construído” e todos os testes devem ser bem sucedidos ou as mudanças serão descartadas.



Integração Contínua� Integração automatizada

� Testes automatizados

� Sempre atualizar o workspace e testar antes do “Checkin”

� Realizar “Checkin” com frequência



Integração Contínua

�Objetivo�Minimizar a existência de problemas de integração no código-base do sistema. Quanto mais cedo forem descobertos, mais fácil de identificá-los e corrigí-los.



Integração Contínua� Integração Contínua Síncrona�Apenas um par integra seu trabalho de cada vez e outros pares só são liberados para integrar ao serem informados do término da integração serem informados do término da integração corrente.



Integração Contínua� Integração Contínua Síncrona - Passos1. Assegurar que o projeto compila e todos os testes automatizados executam

com sucesso2. Conquistar a vez de integrar3. Criar um backup do projeto na estação de trabalho4. Fazer update do projeto4. Fazer update do projeto5. Assegurar que o software continua compilando e os testes executam com

sucesso6. Fazer commit do projeto7. Apagar o diretório do projeto na estação de trabalho e fazer checkout8. Assegurar que o software continua compilando e que os testes executam com

sucesso



Integração Contínua� Integração Contínua Assíncrona

� Projetos nos quais os desenvolvedores não trabalhem juntos em uma mesma sala.

� Em tais casos torna-se difícil ou impossível garantir que apenas um desenvolvedor irá integrar de cada vez. um desenvolvedor irá integrar de cada vez.



Integração Contínua� Integração Contínua Assíncrona – Passos

1. Assegurar que o projeto compila e todos os testesautomatizados executam com sucesso

2. Criar um backup do projeto na estação de trabalho3. Fazer update do projeto3. Fazer update do projeto4. Assegurar que o software continua compilando e os testes executam com sucesso

5. Fazer commit do projeto6. Realizar integração automatizada



Integração Contínua� Ferramentas:

�Hudson�Continuum (Apache)�CruiseControl� LuntBuild� LuntBuild� Bamboo (Atlassian)



Integração Contínua� Ex:�Continuum + Java + Maven + CVS



Integração Contínua

Servidor de IC(Continuum)

Notificações (Sucesso, Falha)

6 - Build de Integração

6.1 - Testes e Métricas

Publicação de Resultados

7 - Deploy

2 - Altera

Repositório(CVS)

Servidor de Relatórios

Equipe

3 - Build Privada

3.1 - Testes e Métricas

4 - Commit

5 – Update / Checkout

Resultados

1 – Checkout / Update



GCS Ágil“GCS Ágil” não é um oxímoro?

� Muitos consideram GCS como um processo pesado que impede o “trabalho real" do desenvolvimento

� Para muitos projetos GCS funciona bem� Alguns compensam evitando ferramentas e práticas que fazem com � Alguns compensam evitando ferramentas e práticas que fazem com que processo de GCS seja inerentemente limitante.

� Outros querem controlar e ter tantos processos de GCS que chegam a prejudicar a eles mesmos.



Desperdícios no Desenvolvimento de Software� Funcionalidades Extra/Não-utilizadas (Overproduction)

� Trabalho parcialmente desenvolvido não liberado para a produção (Inventory)

� Artefatos Intermediários/Não-Utilizados (Extra Processing)

� Busca de Informações (Motion)� Busca de Informações (Motion)

� Defeitos não capturados pelos testes/revisões (Defects)

� Espera (incluindo Espera do Cliente)



O que é GCS Ágil?� A aplicação pragmática de:

� Práticas e Princípios da Gestão de Configuração� de acordo com os Valores Ágeis� usando o “Pensamento Enxuto” (Lean Thinking)

para atender as necessidades de Negócios!



Requisitos da GCS Ágil�Servir aos profissionais e não vice-versa!

�Derrubar as paredes entre a GCS & desenvolvedores para que o time todo trabalhe junto para entregar software de qualidade utilizando uma abordagem ágil

�Responder às mudanças ao invés de prevení-las�Responder às mudanças ao invés de prevení-las

�Rastrear e coordenar o desenvolvimento ao invés de tentar controlar os desenvolvedores

�Se esforçar para ser transparente e automatizar o máximo possível



Características da GCS Ágil�GCS é uma responsabilidade do time inteiro

�Documentação & Rastreabilidade Enxutas

�Gerenciamento Agressivo de Dependências

�Feedback Contínuo e Visível � Sobre a Qualidade, Estabilidade e Integridade

�Coordenação e automação frequente + rápida



Respondendo à Mudanças� Gerenciar as espectativas dos interessados com comunicação próxima e poucas fronteiras � Tomadores de decisões devem estar disponíveis & acessíveis para dar respostas rápidas

� No início de cada iteração espectativas e prioridades são � No início de cada iteração espectativas e prioridades são (re)definidas e (re)calibradas

� CCB’s devem ser chamados de “encontros de replanejamento” para evitar o estigma de tentar “controlar” as mudanças

� Trabalhar somente com features da iteração corrente



Respondendo à MudançasA autorização para os desenvolvedores realizaremmudanças precisa ser instantânea:� Uma vez que o desenvolvedor foi atribuído a uma tarefa, ele não deve precisar esperar para obter os itens do repositório (checkout)(checkout)

� Se um erro “quebra” a build ou falha no teste o desenvolvimento deve ser ágil para efetivamente repará-lo sem ter que esperar pela notificação de autorização

� Nenhuma permissão adicional deve ser requerida para a refatoração (refactoring)



Automatização ApropriadaEventos automatizados que ocorrem frequentemente mudam raramente e requerem consistência.� Eventos relacionados a builds, publicação (deployment), releases formais, testes automatizados, builds de integração

� Por que?: Minimizar Artefatos & Espera� Documentar esses procedimentos via scripts, aumenta a produtividade no desenvolvimento e diminui custos de administração



As Três Builds� Private Developer Build

� Fornece uma forma consistente para o desenvolvedor construir o software (build) nos confins da sua área de desenvolvimento privada

� Team Integration Build� Sincronizar a equipe fornecendo feedback sobre a qualidade e a integridade

� Formal Release Build� Criar pacotes implantáveis

� Por que?:� Produtividade, previsibilidade, documentação, habilidade para a atividade de build sem comprometer a GC ou a qualidade.



PrivateBuild

Task

Developer

Multi-Task

Coordination

Development

Team

IntegrationBuild

Customer /

Test (V

&V)It

eration /

Release

ReleaseBuild

Task

Developer

Multi

Coordination

Development

Team

Customer /

(V&V)It

eration /

Release

The Three Builds



CMM x ÁgilCMM Ágil

O gerenciamento desempenha um papel fundamental para o sucesso do projeto

O gerenciamento é como uma função de coach, que ajuda a eliminar barreiras para o progresso do projeto

O foco é na organização (empresa) O foco é no projeto ou na equipe

O CMMI é amplamente benéfico, especialmente em mercados maduros

Métodos Ágeis tem maior benefício em mercados emergentes ou incompreendidos

O CMMI pressupõe uma visão de longo prazo

O Ágil foca no curto e médio prazo

O CMMI nasceu em domínios de falhas de alto custo

O Ágil Floresceu em domínios de falhas de baixo custo

O CMMI tem forte ênfase em “revisar enquanto desenvolve“

Métodos Ágeis pregam o desenvolvimento simultâneo



GCS Ágil e o Manifesto ÁgilValor 1

Individuals and Interactions over Processes and Tools� Processos e ferramentas de GCS devem suportar a maneira com que você trabalha e não o contrário.

“Processos não escrevem software. Pessoas sim!”




Working Software over Comprehensive Documentation� Minimizar artefatos intermediários

“Simple-size it!”“Simple-size it!”

� GCS pode automatizar as políticas e processos de desenvolvimento com conhecimento executável sobre o conhecimento documentado

“Automatização Apropriada”




Customer Collaboration over Contract Negotiation� A GCS deve facilitar a comunicação entre os interessados e ajudar a gerenciar as espectativas




Responding to Change over Following a Plan� GC diz respeito a facilitar mudanças, não prevení-las

� “Mudanças em requisitos em fases adiantadas do ciclo de vida são vantagens competitivas SE você consegue agir sobre elas!”

– Mary Poppendieck– Mary Poppendieck

� “Projetos ágeis não são controlados em conformidade com o planejamento mas em conformidade com valores do negócio.”

� Se aceitamos a noção de mudanças & turbulência constantes então planos são úteis como guias mas não como mecanismos de controle … porque eles tendem a punir ações corretas.”

– James Highsmith

“A Mudança não é o inimigo – estagnação é! Não tente prevenir mudanças! Se planeje para isso!”



Patterns

Soluções Comprovadas

Copyright © 2010 Misael Santos

Gestão de Configuração de Software42

Padrões de Software� O que é um padrão?

Um padrão é uma solução documentada para

um problema recorrente em um determinado

contexto.

Padrão (Pattern) ≠ Padronização (Standard)



Padrões de Software� Benefícios

� Aumentar a reutilização

� Documentar soluções

� Passar conhecimento para iniciantes

� Fornecer um vocabulário comum entre os desenvolvedores

� Aumentar a qualidade do produto

� ...



Padrões de Software� Padrões x Coleções de Padrões

� Padrões isolados resolvem problemas pontuais� Conjuntos de padrões podem construir um sistema inteiro, preenchendo todas as lacunas de um contexto inteiro



Tipos de Padrões de Software (1)� Atualmente existem padrões de software para as mais diversas áreas da Engenharia de Software

� Existem diversas formas de classificar os Padrões de Software.



Tipos de Padrões de Software (2)� Quanto à fase de desenvolvimento em o padrão é aplicado

� Padrões de Análise (Analisys Patterns)

� Padrões de Projeto (Design Patterns)� Erich Gamma (GoF)

Padrões de Implementação (Idioms)� Padrões de Implementação (Idioms)

� Padrões de Testes (Test Patterns)

� ....



Tipos de Padrões de Software (3)� Quanto à Tecnologia

� Padrões J2EE (Core J2EE Patterns)

� Padrões para Web

� Padrões para XML (XML Patterns)

� Padrões para Bancos de Dados

� Padrões para Ajax (Ajax Patterns)

� Padrões para Interface Gráfica (GUI Patterns)

� ...



Tipos de Padrões de Software (4)� Quanto de Processo/Metologias

� Padrões de Processo (Process Patterns)� Padrões de Gestão de Configuração (SCM Patterns)� Padrões de Segurança (Security Patterns)� ...� ...



Formato dos Padrões (1)� Componentes básicos de um padrão

� Nome� Contexto� A Descrição do Problema� Solução� Solução



Formato dos Padrões (2)� Existem diversos formatos que podem conter

� Forças

� Aplicabilidade

� Usos Conhecidos

� Consequências� Consequências

� Padrões Relacionados

� Intenção

� Racionalidade

� ...



SCM Patterns� Software Configuration Management Patterns:

Effective Teamwork, Practical Integration



SCM Patterns� Consiste em uma Linguagem de Padrões para Gestão de Configuração de Software



SCM Patterns� Consiste em uma Linguagem de PadrõesLinguagem de Padrões para Gestão de Configuração de Software

Conjunto de Padrões que se unem

para formar um “sistema”.



SCM Patterns



SCM Patterns� Objetivo

� Ajudar a entender como as partes de uma ambiente de desenvolvimento interagem entre si para que possamos utilizar de forma efetiva a gestão de configuração.



SCM Patterns� Princípio:

� Usar a Gestão de Configuração, especialmente o controle de versões, como parte de um ambiente de desenvolvimento ágil.



SCM Patterns� Workspace-Related Patterns

� Private Workspace

� Repository

� Private System Build

� Integration Build

� Third Party Codeline� Third Party Codeline

� Task Level Commit

� Smoke Test

� Unit Test

� Regression Test



SCM Patterns� Codeline-Related Patterns

� Mainline� Active Development Line� Codeline Policy� Private Versions� Private Versions� Release Line� Release-Prep Code Line� Task Branch



Mainline Pattern



Mainline Pattern� Minimizar o merge e manter um número gerenciável de linhas de desenvolvimento ativas desenvolvendo sobre a Mainline.



Mainline Pattern� O merge pode virar uma bagunça...



Mainline Pattern� Solução

� Tenha todas as outras linhas de desenvolvimento frequentemente combinadas à linha de desenvolvimento principal



Mainline Pattern



Mainline Pattern� Questões não resolvidas:

� Como manter a “Mainline” utilizável quando muitas pessoas estão trabalhando nela? (Active Development Line)



Active Development Line Pattern



Active Development Line Pattern� Manter uma linha de desenvolvimento em evolução rapidamente estável o suficiente para que seja útil na criação de “Linhas de Desenvolvimento Ativas”.



Active Development Line Pattern� Questões não resolvidas:

� Como identificar a linha de desenvolvimento estável? (Codeline Policy)

� Como isolar o trabalho dos desenvolvedores da “Linha de Desenvolvimento Ativa” (Private Workspace)?Desenvolvimento Ativa” (Private Workspace)?

� …



Private Workspace Pattern



Private Workspace Pattern� Prevenir que questões de integração distraiam você e que suas mudanças causem outros problemas desenvolvendo em uma “Área de Trabalho Privada”.



Private Workspace Pattern� Questões não resolvidas:

� Evitar inserir erros no sistema ao consolidar suas alterações no repositório (Private System Build)

� Outros padrões relacionados:� Repository� Repository

� Third Party Codeline



Repository Pattern



Repository Pattern� Configurar um novo workspace populando-o a partir de um “Repositório” que contém tudo o que você precisa.



Repository Pattern



Repository Pattern� Questões não resolvidas:

� Organizar código de terceiros utilizando o Third-Party Codeline.



Private System Build Pattern



Private System Build Pattern� Verifique se suas mudanças não “quebrarão” a build fazendo uma “integração privada do sistema” antes de consolidar as suas alterações no Repositório.



Private System Build Pattern� Semelhante ao Integration Build, todavia alguns detalhes relacionados à release e empacotamento podem ser omitidos.

� Deve incluir todas as dependências

� Deve incluir todos os componentes dependentes da mudança



Private System Build Pattern� Questões não resolvidas

� Como saber se você não está inserindo problemas à funcionalidade? (Smoke Test Pattern)

� …



Integration Build Pattern



Integration Build Pattern� Garanta que o seu código base sempre gere builds confiáveis fazendo uma Integração (Integration Build) periodicamente.



Integration Build Pattern



Integration Build Pattern� Questões não resolvidas:

� Como garantir que a build de integração é utilizável? (Smoke Test, Regression Test)



Third Party Codeline Pattern



Third Party Codeline Pattern

� Administre o código de terceiros usando uma “Linha de Desenvolvimento de Terceiros”.



Task Level Commit Pattern



Task Level Commit Pattern

� Quanto trabalho deve ser feito entre cada submissão ao controle de versões? Quanto você deve esperarpara commitar suas alterações?

� Organize as mudanças em código-fonte por� Organize as mudanças em código-fonte porunidade de trabalho “orientadas a tarefas”.



Codeline Policy Pattern



Codeline Policy Pattern� Crie uma “Política de Linhas de Desenvolvimento” para ajudar desenvolvedores a decidir onde e quando realizar o “check in” e que procedimentos devem ser seguidos antes de um checkin para cada Linha de Desenvolvimento.



Smoke Test Pattern



Smoke Test Pattern� Garanta que o sistema ainda funcione depois de suas alterações executando o “Smoke Test”

� Teste não exaustivo sobre as funcionalidades básicas da aplicação

� Verificar se a aplicação não “quebra” de forma óbvia� Verificar se a aplicação não “quebra” de forma óbvia



Unit Test Pattern



Unit Test Pattern� Verifique que um módulo ainda funciona depois das suas alterações executando um “Teste Unitário”.



Unit Test Pattern� Testes unitários:

� Deve ser automático� É isolado de outros testes� Testa o contrato do elemento� Deve ser simples de usar:� Deve ser simples de usar:

� durante a codificação

� antes de realizar checkin

� após atualizar o workspace



Regression Test Pattern



Regression Test Pattern� Garanta que código existente não piore quandoimplementadas melhorias executando um “Teste de Regressão”

� Deve ser executado para toda build de integração

� Smoke Tests não testam o software exaustivamente� Smoke Tests não testam o software exaustivamente

� Testes unitários (Unit Tests) testam as partes individualmente



Regression Test Pattern� Execute os testes de regressão no sistema quando você quergarantir uma certa estabilidade a ele

� Crie testes de regressão de casos de testes que falharam no passado (relatos de verificações de qualidade, relatos do cliente)cliente)



Private Versioning Pattern



Private Versioning Pattern

�Use o “Versionamento Privado” para permitir queque você trabalhe com alterações complexaslocalmente e ainda consiga tirar vantagem dos benefícios de uma sistema de controle de versões.

�Use uma branch, um repositório local, ferramentas próprias (níveis de promoção, cvdistribuídos).



Release Line Pattern



Release Line Pattern� Mantenha as versões liberadas sem interferir no desenvolvimento corrente estabelecendo uma “Linha de Release”.



Release Line Pattern

�Branch Before Release



Release-Prep Codeline Pattern



Release-Prep Codeline Pattern� Estabeleca uma linha de desenvolvimento para uma nova liberação, permitindo que novos trabalhos continuem naslinhas de desenvolvimento ativas, fazendo o trabalho de estabilização sobre uma “Linha de Desenvolvimento de Preparação para Release”.Preparação para Release”.

� Ao invés de criar uma branch depois da release, crie umabranch antes da release, permitindo que os desenvolvedorescontinuem trabalhando na Mainline.



Release-Prep Codeline Pattern� Questões não resolvidas:

� Se apenas algumas pessoas estão trabalhando na próxima release, inicie uma Task Branch para o novo trabalho



Task Branch Pattern



Task Branch Pattern� Tenha parte da sua equipe executando uma tarefa sem forçarque o resto da equipe trabalhe em torno da mesma, usandouma “Task Branch”.

� Crie uma ramificação para cada atividade que possa causarmudanças significativas sobre o sistema.mudanças significativas sobre o sistema.



Outros Padrões para GCS� Merge Early and Often

� Merge changes from a branch to its codeline as soon as the changes on the branch are completed and tested

� Bill of Materials� You can successfully build the software system today and need to be able � You can successfully build the software system today and need to be able

to build the same version in the future

� Reproducible Build� You’ve built the software system and created a build process, and need to

know that it can be reproduced



Outros Padrões para GCS� Shared Object Cache

� Allows developers to perform local builds based on extracted files and a common set of object files.

� Shared-Source Escalation� Maintain and support a common set of code used by more than one � Maintain and support a common set of code used by more than one

project.



Outros Padrões para GCS� Branching Policy Patterns

� Padrões descrevendo políticas comportamentais para estabelecer oupreservar as características físicas ou conceituais de uma linha de desenvolvimento

� Branch Creation Patterns� Padrões descrevendo quando criar um novo tipo de branch� Padrões descrevendo quando criar um novo tipo de branch

� Branch Structuring Patterns� Padrões descrevendo as colaborações entre duas ou mais branches



SCM Patterns� Os padrões podem não representar a melhor solução para o problema, mas apresentam uma solução comprovadapara o problema em um determinado contexto, dentre muitas outras que podem existir.



Referências� AMBLER, S. W. Examining Agile Manifesto, Disponível em: http://www.ambysoft.com/essays/agileManifesto.html

� APPLETON, B. Agile Configuration Management Enviroments, Chicago SPIN, Chicago, 2004.

� BECK K. et al.,Manifesto for Agile Software Development, Disponível em: http://agilemanifesto.org/http://agilemanifesto.org/

� MILFONT, C. Agile Software Development: Princípios, valores e práticas aplicados em um estudo de caso, Sun Tech Days 2006, Fortaleza, CE, 2006.

� Improve IT, Extreme Programming, Disponível em: http://www.improveit.com.br/



Gestão de Configuração de Software Ágil

Documents

Transcript of Gestão de Configuração de Software Ágil