Wikalendario

Introdução

Finalidade

Este plano de gerência de configuração de software tem como objetivo especificar as práticas e ferramentas que serão utilizadas no processo de manutenção do software Wikalendário. Este, está em fase de desenvolvimento por estudantes da Universidade de Brasília no segundo semestre de 2016. O Wikalendário é uma aplicação mobile desenvolvida para dispositivos Android.

Visão Geral

Os alunos de graduação, de forma geral, tem a necessidade de se organizar para ter um controle de quais e quando vão ocorrer as atividades de cada disciplina. O Wikalendário se propõe a solucionar esta problemática. Tornando as atividades mais fáceis de serem localizadas por meio de um calendário colaborativo. Cada aluno da Universidade pode escolher as disciplinas que está matriculado e ver os eventos cadastrados pelos seus colegas. Desta forma, alguma atividade que não foi mapeada pode ser adicionado por outro aluno da mesma disciplina.

Escopo

Este projeto tem como objetivo adicionar ao projeto a(o):

1. Implantação de integração contínua;
2. Configuração de ambiente virtual de desenvolvimento;
3. Um plano para a organização e ação para com as branchs;

Todos os desenvolvedores possuem suas máquinas de desenvolvimento com versóes da distro linux Ubuntu (https://www.ubuntu.com/), logo todo o planejamento e configuração foi pensado para esse ambiente.

Repositório do Projeto

O repositório do projeto está disponível em:

https://github.com/Time5-Desenho/Wikalendario.

Definições, Acrônimos e Abreviações

Termo	Significado
GCS	Gerência de Configuração de Software
Build	Versão do software composto por um ou mais itens de configuração
Baseline	É um marco a partir da entrega de um ou mais itens de configuração
Issue	Alguma funcionalidade/problema a ser entregue
Integração Contínua (CI)	Integrar continuamente o software produzido por uma ou mais equipes
Branch (ramificação)	Termo utilizado para representar ramificações do código do software durante seu desenvolvimento e manutenção

Gerência de Configuração de Software

Ferramentas, Ambientes e Infraestrutura

Ferramentas	Descrição
Travis CI	Serviço de integração contínua distribuído usado para verificar a integridade do software automáticamente.
Docker	Ferramenta que facilita a criação e administração de ambientes de desenvolvimento isolados.
Git	Versionamento utilizado pela equipe de desenvolvimento.
Github	Serviço web hosting compartilhado que usa a ferramenta de versionamento Git.

Evolução

O Plano de Gerenciamento de Configuração deve ser mantido atualizado para refletir o planejamento corrente. Dessa forma, as seguintes situações representam gatilhos para atualização do plano e nova aprovação deste documento:

1. Mudança nos itens de configuração;
2. Mudança na identificação dos arquivos;
3. Mudança na identificação das Tags/Branches;
4. Mudança no padrão de versionamento;

Cronograma

Release	Milestone	Sprint	Período	Atividade	Status
1	Planejamento	1	20 a 30 de setembro	Redigir plano de GCS	Completo
		2	1 de outubro a 10 de outubro	Selecionar ferramentas a serem utilizadas	Completo
2	Integração Contínua	3	11 a 21 de outubro	Estudar as ferramentas Travis CI	Completo
		4	11 a 21 de outubro	Implementar integração contínua (Travis)	Completo
3	Configuração de ambiente	5	21 a 30 de outubro	Estudar a ferramenta Vagrant	Completo
		6	1 a 10 de novembro	Estudar scripts e docker	Completo
4	Configuração de ambiente e qualidade de código	7	11 a 15 de novembro	Criar imagem e subir esta no Docker hub	Completo
		8	16 a 20 de novembro	Colocar o relatório na wiki	Completo
			21 de novembro	Entrega final	Completo

Travis CI

O Travis CI é um serviço web de Integração Contínua na nuvem integrado com o GitHub. Ele é gratuito para repositórios públicos(travis-ci.org) e pago para repositórios privados(travis-ci.com). Foi desenvolvido em Ruby e seus componentes são distribuídos sob a licença MIT.

Motivação

As principais motivações para a escolha do Travis CI foram:

• Ele é gratuito para repositórios públicos;
• Ser um serviço de Integração Contínua na nuvem e ter integração com GitHub;
• Notifica o usuário (por e-mail) sobre resultados da build;
• Boa documentação;
• Rápida curva de aprendizado.

Procedimentos

Para adicionar o Travis CI, foi utilizado o tutorial desenvolvido nos lightning talks a respeito do Travis: https://pt.wikiversity.org/wiki/Travis_CI_-_GitHub .

Após várias tentativas de efetuar a configuração da integração contínua com Travis-CI, o arquivo ".travis.yml" ficou do seguinte modo:

$ language: android
$ jdk: oraclejdk8
$ sudo: require
 
$ android:
$   components:
$     - platform-tools
$     - tools
$     - build-tools-24.0.2
$     - android-23
$     - android-24
$     - sys-img-armeabi-v7a-android-23
$     - extra-android-m2repository
$     - compile 'com.google.android.gms:play-services:9.4.0'
$     - compile 'com.google.android.gms:play-services-auth:9.4.0'
$     - compile 'com.google.firebase:firebase-core:9.4.0'
 
$ before_script:
$   # Create and start emulator
$   - echo no | android create avd --force -n test -t android-23 --abi armeabi-v7a
$   - emulator -avd test -no-skin -no-audio -no-window &
$   - android-wait-for-emulator
$   - adb shell input keyevent 82 &
 
$ script: ./gradlew

Dessa forma é garantido que todo o push, independente de branch é verificado, garantindo que todos os desenvolvedores podem atualizar o local sem ter medo de dar pull em código quebrado. Até a entrega deste trabalho não foram implementados testes e nem banco de dados, por isso o arquivo ".travis.yml" não foi incrementado.

Docker

O Docker(https://www.docker.com/) é uma plataforma opensource utilizada para construir, entregar e rodar aplicações distribuídas. O Docker é composto da Docker Engine, que é uma ferramenta leve de execução e empacotamento, e pelo Docker Hub, um serviço em nuvem responsável pelo compartilhamento de aplicações e automação de fluxos de trabalho.

Motivação

• Grande comunidade, ou seja, contém muita informação para solucionar possíveis problemas
• Eliminar diferenças entre os ambientes de desenvolvimento, testes e produção.
• Integração com outros sistemas

Procedimentos

Primeiramente, foi necessário fazer a instalação do Docker em nossas máquinas. Para isso, foi feito um Shell Scritp, utilizando o tutorial desenvolvido nos lightning talks a respeito do Docker (https://pt.wikiversity.org/wiki/Docker) como referência.

$

$ echo "$(tput setaf 1)$(tput setab 7)Iniciando instalacao do Docker...$(tput sgr 0)"
$ sleep 2

$ echo "$(tput setaf 1)$(tput setab 7)Dando update...$(tput sgr 0)"
$ sleep 2
$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates

$ sudo echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" < /etc/apt/sources.list.d/docker.list

$ echo "$(tput setaf 1)$(tput setab 7)Dando update...$(tput sgr 0)"
$ sleep 2
$ sudo apt-get update

$ echo "$(tput setaf 1)$(tput setab 7)Instalando o Docker...$(tput sgr 0)"
$ sleep 2
$ sudo apt-get install docker-engine

$ echo "$(tput setaf 1)$(tput setab 7)Iniciando o Docker...$(tput sgr 0)"
$ sleep 2
$ sudo service docker start

Em seguida, após a instalação do Docker, para a configuração do ambiente de desenvolvimento do Wikalendário é necessário, somente, o Android Studio e o Git. Dessa forma, há um repositório no Docker Hub o qual já contém uma imagem com Android Studio, ao invés de gerarmos toda a imagem do Android Studio novamente, decidimos utilizar desta ferramenta. Portanto, acessamos o repositório: https://hub.docker.com/r/yongjhih/android-studio/ e demos um pull na imagem:

$ docker pull yongjhih/android-studio

Após baixar a imagem e iniciar o container, seguindo os procedimentos passados no Docker Hub da imagem. Vamos criar na pasta do usuário uma pasta chamada: bin.

$ mkdir ~/bin

$ curl -L https://github.com/yongjhih/docker-android-studio/raw/master/docker-android-studio > ~/bin/android-studio

Alterando permissões:

$ chmod a+x ~/bin/android-studio

Vamos agora executar o arquivo criado android-studio:

$ ./android-studio

Gerando um container da imagem:

$ docker run -d -i yongjhih/android-studio /bin/bash

Após verificado o sucesso dos procedimentos acima, vamos criar com base nesta imagem uma outra imagem para utilizarmos ela em nosso repositório do Docker Hub. Portanto, neste momento podemos instalar outros pacotes desejados. Note que é exibido o usuário root e o ID do container criado, este ID será utilizado para salvar e compartilhar a imagem. Para realizar o compartilhamento devemos "deslogar" da imagem com "exit" ou "control D".

$ sudo docker commit -m "Creating docker image" -a "Eduardo Nunes" e708fa0a8f05 eduardonunes/wikalendario:base

Agora iremos dar o push da imagem no repositório do DockerHub, para isso é necessário criar uma conta e criar um projeto, no qual foi criado com o nome wikalendario. Já criada a conta e o projeto criado, iremos:

$ docker push eduardonunes/wikalendario

Note que "eduardonunes" é o usuário da conta criada.

Com isso a imagem pode ser acessada neste link: https://hub.docker.com/r/eduardonunes/wikalendario/

Políticas de Branch

Além da configuração do ambiente também foi definido uma política de branch para que todas as features desenvolvidas no sistema sejam unidas sem perda de trabalho. A política de Branch ficou da seguinte forma:

• Master
• Develop
• Feature 'n'

Fluxo: Primeiramente, a branch referente à funcionalidade que deve ser desenvolvida é criada, depois do término do desenvolvimento da feature ela é mergida com a develop. A develop conterá os códigos das features desenvolvidas naquela sprint. Por fim, a branch develop é unida com a master no fim da release de acordo com os testes definidos e implementados.

752×348px

Referências

WIKIPEDIA. Gerência de configuração de software. Disponível em: GCS. Acesso em: 26 de setembro de 2016.