Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua - PDF
Download "Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua"
Vitória Sanches Imperial
2 Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua Janeiro 2015 Área de Desenvolvimento Departamento de Arquitetura e Desenvolvimento
3 Agenda Processo de desenvolvimento no Instituto de Informática Ferramentas Open Source Software/Free Software Integração Contínua, Entrega Contínua e Deployment Contínuo
5 Cadeia de Valor Processo de Gestão de Entregas
6 Metodologia UP
7 Fases e artefactos Conceção Elaboração Visão Lista de Riscos Documento Arquitetura Modelo Casos de Uso Plano de Projeto Construção Manual de Deployment Manual Operaçao Batches Queries aplicacionais Modelo Dados Físico Binários, Javadocs Casos de Uso Requisitos de Negócio Storyboard Requisitos Não Funcionais Pedido de Serviços Relatórios e Ofícios Documentos VIE s Modelo de Análise e Desenho Modelo Dados Lógico Protótipo Arquitetura Plano de Testes Transição Release Notes Relatório Final de Testes
8 Departamentos e Ambientes Departamento de Arquitetura e Desenvolvimento (DEV) Departamento de Administração de Sistemas (OPS) DESENVOLVIMENT O PRÉ-PRODUÇÃO QUALIDADE PRODUÇÃO
10 Ferramentas - Overview
11 SVN O que é? SCM Software Configuration Management/Version Control Client Web based Permite versionar artefatos e controlar quem fez o quê e quando Onde aplicamos Guardar em todas as versões os artefactos produzidos Disponibilizar informação não desmaterializada Grau de integração Transversal a todas as outras ferramentas
12 O que é? Wiki 2ª geração classes + objetos + scripting Guarda informação de forma estruturada Conteúdo colaborativo Web based Onde aplicamos Construção e disponibilização de artefactos (UC s, Visão, etc) Publicação de informação de interesse para a organização Desmaterialização de documentação Grau de integração SVN Documentos ou espaços exportados da xwiki são colocados no SVN
13 O que é? Sistema de Gestão de Erros/Bugs Web based Colaborativo Onde aplicamos Reporte de não conformidades Gestão de tarefas Grau de integração Jenkins Solicita o ID da tarefa associada à entrega IDE (plugin SVN) Código commited associado a uma tarefa ou não conformidade Tortoise (cliente SVN) Cada artefacto comitted deve incluir o ID de uma tarefa
14 O que é? Ferramenta de gestão para a construção de projetos de software Baseia-se no conceito de Project Object Model (POM) Permite centralizar a produção de binários, relatórios e documentação Onde aplicamos Em todos os projetos / subsistemas novos Em alguns projetos migrados Grau de integração Utilizado em modo stand-alone numa linha de comandos Integrado no IDE (Eclipse, NetBeans, etc) Integrado no Jenkins
15 O que é? Repositório que armazena e organiza os binários de software para uso nos vários ambientes Ponto central Onde aplicamos Partilhar / disponibilizar binários a ser instalados nos vários ambientes Repositório único de third-party jars Repositório fidedigno de snapshots e releases Grau de integração Populado pelo Jenkins / Maven
16 O que é? Plataforma para gerir a qualidade do código Apresenta gráficos com métricas e estatísticas Guarda histórico e evolução da qualidade de código Onde aplicamos No processo de entrega contínua Grau de integração Jenkins invoca o Sonar via plugin para validar código IDE Via plugin do IDE pode ser invocado
17 O que é? Orquestrador de tarefas repetitivas Compilador e executor de testes de projetos contínuos Monitorização de tarefas externas Onde aplicamos Na produção de daily-builds e deliveries Grau de integração SVN Checkout das sources e commit de tags MVN Execução de vários comandos Nexus Upload dos artefactos gerados Sonar Invocado para validação do código fonte Bugzilla Regista informação em tarefa de preparação de build
18 Onde moram os nossos artefactos Conceção Elaboração Visão Lista de Riscos Documento Arquitetura Modelo Casos de Uso Plano de Projeto Construção Manual de Deployment Manual Operaçao Batches Queries aplicacionais Modelo Dados Físico Binários, Javadocs Casos de Uso Requisitos de Negócio Storyboard Requisitos Não Funcionais Pedido de Serviços Relatórios e Ofícios Documentos VIE s Modelo de Análise e Desenho Modelo Dados Lógico Protótipo Arquitetura Plano de Testes Transição Release Notes Relatório Final de Testes
20 Processo de desenvolvimento Nova Funcionalidade ou Correção Tarefa atribuída Equipa Projeto Programadores, Testers, Responsáveis de Projeto ou Ferramentas Artefactos Lança Job Obtém artefactos Insere tags C ó d i g o F ont e p ar a aná l i s e SVN Repo Binários e outros artefactos
21 Integração Contínua Porquê? Rentabilizar as maiores potencialidades de cada uma das ferramentas, garantindo uma visão integrada e atualizada de toda a informação relevante dos projetos Permitir e facilitar uma maior paralelização de trabalhos Percepcionar e evitar problemas de integração de código fonte e de outros artefactos, desenvolvidos em simultâneo por diferentes elementos da equipa Benefícios Reduzir o risco garantindo que a build compila sempre caso de falha notifica a respetiva equipa rápido feedback para a equipa Bugs/defeitos detetados mais cedo Permitindo correção imediata dos bugs introduzidos no processo de desenvolvimento Torna mais fácil gerir várias linhas de desenvolvimento
22 Integração Contínua - Build Diária svn commit Programadores svn checkout SVN Repo Servidor CI Lança maven Versionamento Gera binários Executa testes unitários Empacota os binários
23 Entrega Contínua Porquê? Necessidade de disponibilizar automaticamente uma entrega Benefícios Permite reduzir riscos em torno nas releases Beneficia os gestores do negócio pois há sempre uma release candidata Possibilita rápido feedback sobre os produtos e estratégias desenvolvidas
24 Entrega contínua Delivery Build svn checkout svn commit Programadores Invoca Sonar SVN Repo Servidor CI re le as e mvn site deploy Lança maven m vn Versionamento Gera binários Executa testes unitários Empacota os binários Cria tag Cria site c/ resources Arquiva artefactos
25 Deployment Contínuo Porquê? Permitir com um simples pressionar do botão produzir uma nova versão do produto e instala-la no ambiente de produção, disponibilizando-a rapidamente ao cliente. Benefícios Reduzir o tempo entre o levantamento de um requisito e a sua disponibilização para o cliente, permitindo: Ter mais cedo o retorno do que foi investido (Return On Investment) Feedback dos end users Dificuldades Montar infraestrutura baseada em automatismos e instrumentação Capacidade de efectuar um rollback rapidamente caso surja um problema com a nova release
26 Roadmap Onde nos encontramos Integração Contínua Entrega Contínua Deployment Contínuo
27 Conclusão Investir no processo de deployment contínuo Continuar a aposta em ferramentas OSS Alargar utilização a todos os projetos dentro processo de gestão de entregas mas também a outros processos da cadeia de valor Contribuir para a consolidação, evolução e melhoria contínua das ferramentas de desenvolvimento OSS
29 Av. Prof. Dr. Cavaco Silva, nº 17 Edifício Ciência 1 Taguspark Porto Salvo Telf
Bugzilla para além da gestão de bugs. Paulo Zenida Linkare TI
Bugzilla para além da gestão de bugs Paulo Zenida Linkare TI Paulo Zenida pzenida@linkare.com Linkare TI Tecnologias de Informação Lda www.linkare.com Bugzilla www.bugzilla.org AGENDA Linkare TI Desafio
Gestão de Configuração de Software Professor MSc Wylliams Barbosa Santos Disciplina: Projeto de Sistemas Web wylliams.wordpress.com wylliamss@gmail.com Agenda Gestão de Configuração de Software Cenário