Pentaho Mondrian

Fonte: Wikiversidade
Saltar para a navegação Saltar para a pesquisa

1. Introdução[editar | editar código-fonte]

Esta página descreve o plano de Gerência de Configuração do Pentaho Mondrian, desenvolvido na disciplina de Gerência de Configuração de Software

1.1 Finalidade[editar | editar código-fonte]

Esse documento tem por finalidade planejar a execução do processo de Gerencia de Configuração, com o intuito de garantir um controle maior do projeto ao longo de todo o processo.

1.2 Escopo[editar | editar código-fonte]

Este documento está estruturado de forma que descreva como cada etapa da gerência de configuração irá acontecer no decorrer do projeto. A Descrição da equipe de gerencia de configuração do projeto, os itens de configuração, o controle de mudança e a formação do comitê de mudanças.

1.3 Definições, Acrônimos e Abreviações[editar | editar código-fonte]

Termo Significado
GCS Gerência de Configuração de Software
Baseline Conjunto de itens de configuração que se encontram em uma versão estável.
Compilar Cria um arquivo executável a partir do código fonte.
Build Uma versão ou parte de um software composto por um ou mais itens de configuração.
Teste Verifica se os itens se comportam da maneira esperada.
Deploy Disponibilizar o sistema para produção

1.4 Referências[editar | editar código-fonte]

  • Template de Plano de Gerência de Configuração, IBM.

1.5 Visão Geral[editar | editar código-fonte]

Este plano contempla as diretrizes utilizadas no processo de gerência de configuração, são elas Organização, Responsabilidades e Interfaces e Ferramentas, Ambiente e Infraestrutura, Métodos de identificação dos itens de configuração, Baseline de Projetos e estruturas de repositórios, Processamento e controle de solicitações de mudança, Estrutura do repositório de versões, Padrões e procedimentos, Treinamento e recursos e as auditorias de configuração.

2. Gerenciamento de Configuração de Software[editar | editar código-fonte]

Organização, Responsabilidades e Interfaces[editar | editar código-fonte]

Pedro Tomioka e Lucas dos Santos: Responsável pela criação das tags e baselines dos artefatos de projeto; Gestor de Configuração; Integrante do comitê de controle de mudanças CCB; Auditoria de Configuração; Desenvolvimento

2.1 Ferramentas, Ambiente e Infraestrutura[editar | editar código-fonte]

Ferramenta de Controle de Versão:

ID Ferramenta Objetivo
01 GIT Ferramenta de repositório para controle de versão para todos os tipos de documentação do Projeto. Necessário disponibilizar um repositório e definir permissões de acesso à leitura, escrita e exclusão definida no Plano de Gerência de Dados e Comunicação do Projeto. De forma distribuída.

Ferramenta para controle de solicitações de mudanças e acompanhamento do projeto:

ID Ferramenta Objetivo
01 GITLAB[1] Ferramenta utilizada para identificar tarefas, solicitações de mudanças, ativos reutilizáveis, defeitos e não conformidades encontradas durante as avaliações de produtos e processos.


Ferramentas para virtualização:

ID Ferramenta Objetivo
01 Vagrant [2] Ferramenta que cria e configura ambientes de desenvolvimento de acordo com scripts de configuração.
02 Virtual Box 4.2[3] Ferramenta que serve para criar e hospedar máquinas virtuais com diferentes sistemas operacionais.
03 Puppet 3.8 [4] Ferramenta que automatiza a instalaçãod de pacotes num ambiente virtualizado.

3. O Programa de Gerenciamento de Configuração[editar | editar código-fonte]

3.1 Identificação da Configuração[editar | editar código-fonte]

3.1.1 Métodos de Identificação[editar | editar código-fonte]

Os artefatos do projeto deverão seguir a seguinte estrutura:

Nome_do_artefato-codigo_do_projeto-Versão_do_artefato.

3.1.2 Itens de Configuração[editar | editar código-fonte]

Os itens de configuração do projeto estão listados abaixo.

Item (Ou Tipo de Item) Responsável na Equipe Inclusão em Baseline
Cronograma do Projeto Pedro Tomioka e Lucas dos Santos Quando é modificado o número de atividades cronograma.
Código Fonte Pedro Tomioka e Lucas dos Santos Quando o código é modificado e depois testado, e sua branch está estável.
Documentação Pedro Tomioka e Lucas dos Santos Quando é modificado e revisado.
3.1.3 Baselines do Projeto[editar | editar código-fonte]

Baselines de Projeto

Gerada a cada marco definido no cronograma.

Baselines de Produto

Gerada no final de cada iteração.

3.1.4 Estrutura do Repositório de Versões[editar | editar código-fonte]

O repositório é composto na seguinte estrutura:

|-- Vagrantfile
|-- manifests
|	|modules/
|	|	|-- capabilities
|	|	|-- lib
|	|	|-- roles
|	|	|-- services
|	|-- default.pp

3.2 Controle de Configuração e Mudança[editar | editar código-fonte]

3.2.1 Processamento e Aprovação de Solicitações de Mudança[editar | editar código-fonte]

O Responsável pela alteração, solicita a liberação do item de configuração descrevendo a mudança a ser realizada. O comitê de Controle de Mudanças avalia o impacto da mudança e autoriza ou não a solicitação.

As solicitações de mudanças serão realizadas através do sistema de issues disponibilizado pelo gitlab.

3.2.1 Comitê de Controle de Mudança (CCB)[editar | editar código-fonte]

O comitê do controle de Mudanças é formado pelos membros Pedro Tomioka e Lucas dos Santos.

4. Padrões e Procedimentos[editar | editar código-fonte]

4.1 Padrões[editar | editar código-fonte]

O arquivos do código fonte devem respeitar a estrutura de pastas.

4.2 Procedimentos de Trabalhos[editar | editar código-fonte]

O trabalho de desenvolvimento consiste em fazer a automatização da instalação do ambiente de desenvolvimento do Pentaho Mondrian [5]em uma máquina virtual por meio da ferramenta Vagrant. Com a virtualização do ambiente de desenvolvimento do Pentaho Mondrian será possível compilar, fazer a build, teste e o Deploy do Pentaho Mondrian[5]. Assim facilitando o processo de desenvolvimento da aplicação, pois elimina a depêndencia de uma configuração específica do ambiente para a máquina do desenvolvedor.Isso irá permitir que o usuário desenvolva em seu ambiente padrão e compile seu trabalho na VM.

Assim para cada User Story identificada deverá ser criada uma branch para ela, e em sua conclusão o seu responsável deverá solicitar o merge dela para a master.

A master não poderá ser modificada pelos desenvolvedores, cabendo ao CCB a tarefa de resolver conflitos e de juntar as branches a ela.

5. Treinamento e Recursos[editar | editar código-fonte]

O treinamento de gestão de configuração do projeto deve ser realizado para toda a equipe, explicando como o processo acontece no decorrer do desenvolvimento. A principal fonte de material de referência será a wiki do projeto, que estará em constante evolução ao longo do projeto.

6. Auditoria da Configuração[editar | editar código-fonte]

6.1 Processo de auditoria da configuração[editar | editar código-fonte]

O processo consiste executar a auditoria para confirmar se os itens atendem os requisitos estabelecidos para eles, e se houver discrepâncias os mesmos deverão ser reportados.

7. Pentaho BI[editar | editar código-fonte]

A ideia inicial do projeto de GCS era automatizar a configuração do ambiente de produção do Pentaho BI, mas um módulo do Puppet já havia sido feito para esse fim e a dupla decidiu mudar o projeto para o Pentaho Mondrian.

O módulo do Pentaho BI para o Puppet pode ser encontrado em https://forge.puppetlabs.com/yguenane/pentaho.

8. Cronograma[editar | editar código-fonte]

Semana Período Atividade
1 (06.05 - 13.05) Elaboração do Plano de GCS e Criação do Repositório
2 (13.05 - 20.05) Instalação do Ambiente Puppet e vagrant
3 (20.05 - 27.05) Criação dos scripts vagrant e puppet
4 (27.05 - 03.06) Criação dos scripts vagrant e puppet
5 (03.06 - 10.06) Teste da configuração
6 (10.06 - 17.06) Ponto de Controle 1
7 (17.06 - 24.06) Ponto de Controle 2
8 (24.06 - 01.07) Revisão Geral
9 (01.07) Entrega da versão final

9. Andamento[editar | editar código-fonte]

As atividades realizadas no projeto com informações do progresso até o dia 01/07/2015 encontram-se na tabela abaixo:

Número Atividade Progresso
1 Elaboração do Plano de GCS e Criação do Repositório 100%
2 Instalação do Ambiente Puppet 100%
3 Criação dos scripts puppet 90%
4 Instalação do Vagrant 100%
5 Criação dos scripts do Vagrant 100%

9.1. Scripts do Puppet[editar | editar código-fonte]

A tabela abaixo mostra as issues relacionadas aos scripts do puppet e o status de cada uma até o dia 01/07/2015.

Número Descrição Status
#1 Criar estrutura de arquivos para puppet Concluído
#2 Clonar repositorio do Pentaho Mondrian pelo puppet Concluído
#3 Configurar JDK 1.5 Em Progresso
#4 Configurar JDK 1.6 Concluído
#5 Configurar JDK 1.7 Concluído
#8 Configurar banco MySQL Concluído
#9 Configurar Ant Concluído
#10 Reorganizar estrutura de Pastas Concluído
#11 Coordenar script Puppet Concluído
#12 Alterar a localizacao do clone do repositorio mondrian Concluído

9.2. Instalação[editar | editar código-fonte]

O repositório usado para desenvolvimento encontra-se hospedado no gitlab em Mondrian Puppet.


Puppet Standalone[editar | editar código-fonte]

Para utilizar apenas o módulo puppet num SO Ubuntu 14.04 Trusty deve-se primeiro instalar o Puppet:


$ sudo apt-get install puppet


Logo após é necessário instalar o módulo disponibilizado no Puppet Forge [6]

Para tal é necessário rodar o seguinte comando que irá instalar a versão mais recente e todas as suas dependências presentes no repositório oficial. [6]

$ puppet module install tomiokaPedro-mondrianpuppet

Será instalada as seguintes dependências, mais detalhes em tomiokaPedro-MondrianPuppet

  1. puppetlabs-stdlib (>= 1.0.0)
  2. tylerwalts-jdk_oracle (>= 1.0.0)
  3. puppetlabs-java (>= 1.3.0)
  4. maestrodev-ant (>= 1.0.5)

Para executar o módulo é necessário o seguinte comando apresentado a seguir para cliente standalone Puppet. O processo irá baixar cerca de 300 MB referentes ao código-fonte do Pentaho Mondrian, e mais 100 MB de módulos e pacotes adicionais.

 # O modulepath é necessário caso sua instalação não encontre automaticamente onde os modulos estão instalados 
 # Geralmente os modulos do Puppet ficam instalados em /home/user/.puppet/modules
 $ puppet apply <caminho-para>/manifests/default.pp --modulepath=<caminho de Puppet modules>

Por fim deve-se fazer a extração e alocação do arquivo files/jdk-1_5_0_22-linux-amd64.bin manualmente, pois algumas tentativas de automação não foi possível até o fim da disciplina, ficando assim como uma limitação do script. Porém por ficar registrado como uma issue, deverá ser corrigido o quanto antes [7].

$ sudo ./jdk-1_5_0_22-linux-amd64.bin

Em seguida é necessário mover a pasta padrão proposta para o Script

$ sudo cp -f <caminho-para>/jdk-1_5_0_22/ /usr/lib/jvm/

E setar $JAVA_HOME e $JAVA_HOME_15 para a jdk 1.5

$ export $JAVA_HOME=/usr/lib/jvm/jdk-1_5_0_22/
$ export $JAVA_HOME_15=/usr/lib/jvm/jdk-1_5_0_22/

Vagrant + Puppet[editar | editar código-fonte]

Os passos para provisionar uma VM com o script Puppet são mais simples, e irão instalar um box puppetlabs/ubuntu-14.04-64-puppet[8]. Primeiro a máquina host deve ter instalado o Vagrant [2] Em seguida deve clonar o repositório do projeto:


$ git clone https://gitlab.com/gcs-2015-1-g11/mondrian-puppet.git

Em seguida deve-se levantar a VM com o seguinte comando:

# ../mondrian-puppet/
$ vagrant up

Por fim deve-se seguir os passos para o JDK 1.5 como explicado no tópico anterior.

E a máquina será configurada automaticamente seguindo os script Puppet do projeto.

Build do Pentaho Mondrian[editar | editar código-fonte]

Dentro da vm e na pasta onde o projeto foi clonado deve rodar o seguinte comando:

$ ant

Dificuldades Encontradas[editar | editar código-fonte]

Devido ao fato do Pentaho Mondrian necessitar de 3 versões diferentes de JDK, encontramos muita dificuldade em instalar as três num mesmo script standalone, pois as classes dos módulos instaladores apresentam o comportamento Singleton, ou seja apenas uma instância dela poderia estar ativa na hora de executar o Script, assim foi necessário utilizar múltiplas fontes de módulos para o código, todas encontradas no forge oficial [6]

O Puppet pela sua natureza declarativa, não apresenta ao usuário um estado do progresso na execução do script na sua inteface, pois seus nodes somente reportam ao master quando chega ao fim da execução. Portanto fica difícil saber o que está acontecendo durante um Puppet Apply por exemplo. No projeto isso fica evidente quando é necessário clonar o repositório do Mondrian, que tem mais de 300MB, e pode levar o usuário a pensar que nada está acontecendo, devido ao tempo de download necessário para tal.

Apesar de ter uma extensa documentação, não foram encontrados muitos exemplos de integração entre nodes e classes para o caso standalone. Mas a literatura apresenta bons exemplos para este tipo de caso. Na sessão seguinte serão listados os livros usados como referência para esse projeto. Também foi utilizado uma máquina virtual de aprendizado do Puppet, que se encontra no site oficial da ferramenta [9].

Referências Bibliográficas[editar | editar código-fonte]

- Puppet Cookbook - Third Edition [10]

- Puppet 3 Beginner's Guide [11]

- Documentacão oficial [12]

- Wiki do Projeto [13]

  1. https://www.gitlab.com
  2. 2,0 2,1 https://www.vagrantup.com/
  3. https://www.virtualbox.org/
  4. https://puppetlabs.com/
  5. 5,0 5,1 http://community.pentaho.com/projects/mondrian/
  6. 6,0 6,1 6,2 https://forge.puppetlabs.com/tomiokaPedro/mondrianpuppet
  7. https://gitlab.com/gcs-2015-1-g11/mondrian-puppet/issues/3
  8. https://atlas.hashicorp.com/puppetlabs/boxes/ubuntu-14.04-64-puppet
  9. https://puppetlabs.com/download-learning-vm
  10. UPHILL, T.; ARUNDEL, J; Puppet Cookbook - Third Edition. Packt Publishing Ltd, 2015
  11. ARUNDEL, J. Puppet 3 Beginner's Guide. Packt Publishing, 2013
  12. http://docs.puppetlabs.com/puppet/
  13. https://gitlab.com/gcs-2015-1-g11/mondrian-puppet/wikis/home