Jadson Santos Analista TI UFRN Amador Pahim Eng. Red Hat / Pesquisador SINFO

Tamanho: px

Começar a partir da página:

Download "Jadson Santos Analista TI UFRN Amador Pahim Eng. Red Hat / Pesquisador SINFO"

Mikaela Miranda Ferrão
8 Há anos
Visualizações:

1 Jadson Santos Amador Pahim 1 Analista TI UFRN Eng. Red Hat / Pesquisador SINFO

2 Jadson Santos Amador Pahim 2 Analista TI UFRN Eng. Red Hat / Pesquisador SINFO

3 Aperfeiçoando o Processo de Desenvolvimento

4 Erro Aprimoramento Código Fantasma Lixo SVN TRUNK Caso de Uso chapolin 4

5 Erro Aprimoramento Código Fantasma Lixo SVN TRUNK Caso de Uso chapolin Nosso Código de Produção

7 Como Melhorar Isso?

8 Proposta Novo processo de desenvolvimento da SINFO Baseado em 5 ações: 1. Uso Forte de Controle de Versão 2. Testes Automatizados (Unitários) 3. Integração contínua 4. Revisão de Código 5. Sistema de Controle de Versão Distribuído

9 Problema de Código Indevido/Inacabado no Repositório Tarefas desenvolvidas com pouco esforço ou que possuem urgência em serem atualizadas Tarefas complexas de demandam um certo tempo e esforço para serem atualizadas

10 Problema de Código Indevido/Inacabado no Repositório Conflito branch Fácil! Crie Branches para coisas que vão demorar

11 Problema de Código Indevido/Inacabado no Repositório MAIN LINE Apenas Tarefas Planejadas p/ Build em xx/yy/zzzz Merg e Branches Tarefas Urgentes / Erros

12 Problema de Código Indevido/Inacabado no Repositório MAIN LINE Branches Tags no SVN

13 Problema Falta de Testes Automatizados A arquitetura de Processadores é complexa para ser testada

14 Problema Falta de Testes Automatizados Testes Unitários Processadores do SigEventos Testes de performance do SigEleição

15 Integração Contínua Ato de constantemente juntar o que foi desenvolvido e testar, para ver se as mudanças não quebraram o sistema.

16 Integração Contínua Integrar Testar MAIN LINE Branches

17 Integração Contínua l l l l Detectar e resolver conflitos mais cedo Trazer TDD para o mundo real Reforçar a responsabilidade coletiva pelo código. CI Server - Builds agendadas - Build por eventos (ex. alterações de código) - Notificações

18 Build quebrada, como evitar? Não commit o código na branch master antes de: Revisar Verificar Build completa com testes (!!!) Gerrit! Criação de branches temporárias para revisão de código Integração com Jenkins

19 Gerrit Workflow A B- V3 master Code Review - 1 Code Review +1 Verified +1 Build Failed Code Review - 1 Code Review +1 Verified +1 Build Ok Code Review +1 Code Review +1 Verified +1 Build Ok Pull B- V1 B- V2 B- V3 refs/for/master Push Push Push A B- V1 B- V2 B- V3 local master

20 Novo Processo de Desenvolvimento Interno Fluxo Antigo: Codificação Fluxo Novo: Codificação + Testes + Revisão de Código

21 Proposta de Ambiente de Referência para as Cooperações

22 Controle de Versão Distribuído Mais adequado ao ambiente das cooperações Menos vulnerável a corrupções Permite trabalho off-line Escalável Trabalha com baixa velocidade de rede Maior colaboração entre os desenvolvedores O ambiente de cooperação é distribuído por natureza Instituições não precisam estar o tempo todo conectado a um repositório em servidores da UFRN

23 Ambiente de Referência Clone Repositório Referência Clone Repositório UFRN Repositório UFX Clone Clone Clone Desenv1 Desenv2 Desenv3 Desenv1 Desenv2 Desenv3 UFY Desenv1 Desenv2 Desenv3

24 Ambiente de Referência Ideias Principais: Que o ambiente de referência seja colaborativo, toda instituição vai poder colaborar com código e receber código desenvolvido por outra instituição No ambiente de referência só vai ser disponibilizado código que seja comum, se não a todas, a boa parte das cooperações. O código do repositório de referência de ser uma LPS, ou seja, possibilitar que sejam feitas variações nas regras e fluxos para atender a especificidades, com baixo impacto para quem precisa dessas variações

25 Clone Ambiente de Referência MAIN LINE Branches Clone Repositório UFRN MAIN LINE Branches Desenv1 Desenv2 Desenv3 Repositório Referência Clone Branches Repositório UFX Desenv1 Desenv2 Clone MAIN LINE MAIN LINE Desenv3 UFY Clone Branches Desenv1 Desenv2 Desenv3

26 Ambiente de Referência No ambiente de referência vai ser aplicado o fluxo de versionamento e integração contínua e revisão de código mostrado anteriormente Quem quiser contribuir com código de referência, terá seguir esse fluxo Para isso funcionar o processo definido deve ser rigorosamente seguindo. ( Processo a cima de tudo)

27 Planejar Integrar ConCnuamente Testar Revisar MAIN LINE Branches

28 Para o Ambiente de Referência O planejamento para o Ambiente de Referência vai ser cooperativo entre todas as instituições. Todas as instituições vão saber quais funcionalidades estão planejadas para a próxima versão do sistema que vai ser lançada daqui a x dias. MAIN LINE Planejar Branches

29 Fluxos Alterações Comuns Usou a abordagem de LPS? PULL Repositório Referência Aprovada Uso de Merge Tools FETCH + MERGE Comitê gestor técnico/ revisão revisão Desenvolve Mudança Aprovada Comitê gestor Repositório UFRN Desenv1 Desenv2 Desenv3 Mudança não Aprovada Solicitação de Mudança

30 Fluxos de Erros PULL Erro voltando Repositório Referência MAIN LINE Branches FETCH / MERGE MAIN LINE revisão Comita na MAIN LINE Comitê gestor técnico Repositório UFRN Branches revisão Commita no Branch de Erros esenv1 Desenv2 Desenv3 Erro Ocorre em Referência?

31 Andamento dos Trabalhos Testes Unitários, Testes de Performance (OK) Uso do GIT (OK) Uso do Gerrit (OK) Uso do Jenkins para fazer build contínuas e rodar testes automatizados (OK) Integração Jenkins + Git + Gerrit Treinamento das equipes de desenvolvimento Adaptações na Ferramenta IPROJECT para o novo fluxo Validação do Fluxo Disponibilização para Cooperações Testes de Integração

32 Metas Equipe do SIGRH usada como piloto para validação do fluxo Equipe receberá treinamentos: Controle de Versão com o Git Revisão de Código com Gerrit Escrita de Testes Unitários (Processadores + Classes de Domínio + Classes Utilitárias) Até o 1 semestre de 2015 aplicado a todas as equipes e sistemas da SINFO A partir desse ponto, treinamento das cooperações

33 O Seu mais novo concorrente acabou de nascer esta manhã

Documentos relacionados

PROJETO CEMEA. Um trabalho educacional

PROJETO CEMEA. Um trabalho educacional PROJETO CEMEA Um trabalho educacional CEMEA: Objetivo geral A partir de um sistema já existente, temos como missão: Melhorar suas funcionalidades; Documentar tanto o código, quanto suas funções; Acrescentar