Zenit Aerospace
Repositório do projeto
editarO repositório do projeto está disponível na aplicação do GitHub https://github.com/ZenitAerospace/gestao-pessoas
Plano de Gerenciamento de Software
editarFinalidade
editarEste documento é para definir os objetivos a serem cumpridos com o plano de gerenciamento e configuração de software, assim como definir o que será contemplado neste planejamento para gerenciar as mudanças e configurar o software e ambiente, ferramentas utilizadas, as datas importantes e papéis do projeto.
Escopo
editarO escopo do projeto de gerência de configuração de software é melhorar quesitos de configurações do projeto da Zenit Aerospace para facilitar o seu desenvolvimento e manutenção. Para tanto, é definido quatro objetivos:
- Desenvolver uma política para criação, deleção e merge de branch e versionamento do produto.
- Manual para instalação das ferramentas e configuração do ambiente
- Melhorar a configuração da integração contínua já existente
- Configurar um deploy contínuo
Definições, Acrônimos e Abreviações
editar- GCS - Gerência e Configuração de Software
- 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
- Merge - No gerenciamento de versões de software, trata-se de mesclar duas branch do mesmo repositório ou não.
Visão Geral
editarEste documento está organizado de forma a deixar claro o que e como será feito juntamente com os resultados da configuração proposta no projeto. Logo, este estará seccionado em:
- Introdução - Visão geral e definições de termos sobre o que será tratado no documento.
- Ferramentas - Descreve as ferramentas utilizadas para a gerência de configuração.
- Cronograma - Datas importante para a execução do plano de GCS no projeto escolhido.
- Pessoas - Contém os principais papéis e uma breve descrição.
- Projeto - Seção que descreve as informações de como será feita a gerência e configuração de software.
Ferramentas
editarNo projeto para um website, são utilizadas diversas ferramentas tanto para a produção do software, quanto para o monitoramento da produção, da qualidade e para realizar a entrega do produto final ao cliente. Dessa forma as ferramentas envolvidas nestas atividades serão:
| Ferramentas | Descrição |
|---|---|
| Travis CI | Ferramenta web que realiza a integração contínua do código gerado pelos times de desenvolvimento, com o código já existente |
| Code climate | Ferramenta web que faz análise do código estável ou não, presente na branch definida pela equipe verificando algumas métricas de acordo com a linguagem usada, e gera um valor de resultado indicando a qualidade do código no intervalo de 0 - 4. Usado juntamente com a ferramenta de integração contínua Travis CI. |
| Vagrant | Possibilita a criação e configuração de um ambiente de produção em uma máquina virtual, no qual estará pronta para ser utilizada por um desenvolvedor. |
| Gem | É o gerenciador de pacotes da linguagem do projeto, ruby. Facilita a instalação de dependências do software e resolução de dependência entre pacotes. |
| Capistrano | Automatiza o processo de deploy da build gerada de um projeto. Desta maneira, quando acontecer a integração de uma branch, a build será automaticamente enviada para o servidor de produção. |
| Git | Gerenciador de versões utilizada pela equipe de desenvolvimento. |
| Github | Source forge onde está presente o repositório do projeto, no qual contribuidores e interessados podem ver o código do software. |
| VirtualBox | Ferramenta de virtualização de computadores, permite instalação de vários sistemas operacionais e outros softwares. |
Ferramentas de Comunicação
editarComo ferramentas de Comunicação, serão utiliza
| Ferramenta | Descrição |
|---|---|
| Gmail | ferramenta utilizada para comunicação via e-mail |
| ferramenta utilizada para comunicação via mensagens de texto |
Pessoas
editar| Papel | Descrição e responsabilidades | Responsáveis |
|---|---|---|
| Desenvolvedor | Pessoa que fará a implementação do código, logo fará uso da configuração de ambiente, da integração contínua e obedecerá às políticas de branch definidas. | Contribuidores do projeto. |
| Gestor de configuração | Define quais itens de configuração serão feitos para o projeto, baseado nas necessidades dele e quais as melhores ferramentas a serem usadas. | Marcelo Ferreira e Mateus Furquim. |
| Auditor de configuração de software | Faz a verificação e validação do plano de GCS e sua consistência. | Renato Sampaio. |
Cronograma
editarNo projeto para um website, são utilizadas diversas ferramentas tanto para a produção do software, quanto para o monitoramento da produção, da qualidade e para realizar a entrega do produto final ao cliente. Dessa forma as ferramentas envolvidas nestas atividades serão:
| Release | Milestone | Sprint | Período | Atividade | Status |
|---|---|---|---|---|---|
| 1 | Planejamento | 1 | 20/09 ~ 26/09 | Redigir Plano de GCS | Feito |
| 2 | 27/09 ~ 03/10 | Pesquisar ferramentas | Feito | ||
| 2 | Política de Branch | 3 | 04/10 ~ 10/10 | Pesquisar e escrever políticas de Branch | Feito |
| 3 | Manual de Instalação e Configuração | 4 | 11/10 ~ 17/10 | Pesquisar ferramentas e escrever manual | Feito |
| 5 | 18/10 ~ 24/10 | Criar máquina virtual | Feito | ||
| 4 | Integração Contínua | 6 | 25/10 ~ 31/10 | Analisar atual estado de CI | Feito |
| 7 | 01/11 ~ 07/11 | Implementar melhorias na configuração de CI | Feito | ||
| 5 | Deploy automatizado | 8 | 08/11 ~ 14/11 | Estudar ferramenta de deploy (Capistrano) | Feito |
| 9 | 15/11 ~ 21/11 | Implantação e teste do deploy | Feito | ||
| 21/11 | Possível apresentação do projeto | ||||
| 5 | Deploy automatizado | 10 | 22/11 ~ 28/11 | Feito | |
| 28/11 | Possível apresentação do projeto | ||||
| 5 | Deploy automatizado | 11 | 29/11 ~ 05/12 | Feito | |
| 05/12 | Possível apresentação do projeto | ||||
Política de uso do repositório
editar
A ferramenta utilizada para o gerenciamento de versões do software é o git, no qual o repositório é publico e está disponível no forge GitHub.
Commits
editarAos contribuidores que desejarem ajudar no projeto, deverão seguir o seguinte padrão para realizar os commits.
- Primeira letra do título e corpo (se houver) devem ser maiúsculas;
- O título e corpo do commit deverão estar em inglês;
- O tempo verbal utilizado deverá ser o presente (e.g. Add class; Modify method; Remove element from home page);
- Commits que fecham issue, deve ser indicado no corpo do commit com os comandos aceitos pelo GitHub.
- Commits de merge devem indicar os arquivos que ocorreram conflitos.
Estrura básica
editarA estrutura básica do repositório terá duas branchs principais.
Branch master: Esta branch contém o código dos pontos de entrega, ou seja, o código fonte da aplicação que será enviado para produção. Esta branch é atualizada pela branch development.
Branch development: Contém o código fonte estável produzido durante o desenvolvimento, ou seja, contém o código fonte das funcionalidades que terminaram e estão sendo integradas com as demais.
Criação de branch
editarPara a criação de novas branchs há duas principais separações, criação de novas funcionalidades e resolução de bugs.
Novas funcionalidades
editarNovas funcionalidades são específicadas de alguma forma, seja em caso de uso ou em história de usuário. Assim, o nome da branch a ser criada deve possuir a identificação da funcionalidade que está sendo implementada.
Sempre que for iniciada uma nova branch de funcionalidade, esta deverá sempre ser criada a partir da branch development da estrutura básica. Devido a isto, a nova funcionalidade conterá outras funcionalidades que ainda não estão em produção. Sendo assim, não é permitido a criação a partir de outras funcionalidades, da branch master ou issues.
| Funcionalidade | Branch |
|---|---|
| UC 01 - Manter funcionário | UC01 |
| UC 02 - Busca avançada | UC02 |
Resolução de bugs
editarPara a resolução de bugs, deverá ser criada uma branch cujo nome é o identificador da issue, ou seja, o nome da branch deverá conter o nome Issue, seguido do número identificador da issue ou nome.
Tabela
| Issue | Branch |
|---|---|
| Issue 01 - Erro da validação no formulário | Issue01 |
| Issue 02 - Nome de usuário não aparecendo | Issue02 |
| Issue - Bug ao salvar usuário sem nome | IssueBugSaveUser |
Junção de branch
editarA realização de junções de branch (merge) ou pull-request será realizado apenas na branch pai. Ou seja, se uma branch Issue01 foi criada a partir da UC01, esta deverá ser mesclada a UC01.
Configuração de ambiente automatizada
editarO vagrant é uma ferramenta bastante útil para pessoas interessadas em realizar configuração automatizada de máquinas virtuais. Realiza a configuração única de uma máquina, contendo os softwares, arquivos necessários, pacotes e configurações necessárias para que todos tenham acesso a mesma máquina sem ter que configurar manualmente.
A possibilidade de criar um ambiente homogêneo para o desenvolvimento, independentemente do Sistema Operacional utilizado (Mac OS X, distribuições Linux, Windows) no computador hospedeiro foi o maior motivador da escolha pela ferramenta. Sem precisar que cada novo desenvolvedor precise executar toda a configuração necessária.
Instalação
editarComo aplicação de emulação das máquinas virtuais, será usado o virtualbox, caso não tenha instalado é preciso fazê-lo.
sudo apt-get update
sudo apt-get install virtualbox
Para instalar o vagrant, deve ser seguido o guia de instalação. Nesta etapa foi utilizada a versão Debian 8 64 bits, sendo possível instalar de duas maneiras diferentes.
#RECOMENDADO Utilizado o gerenciador de pacotes
sudo apt-get update
sudo apt-get install vagrant
#POUCO RECOMENDADO Baixando e instalando o pacote manualmente
cd /tmp
wget https://releases.hashicorp.com/vagrant/1.8.7/vagrant_1.8.7_x86_64.deb
sudo dpkg --install vagrant_1.8.7_x86_64.deb
Configurando Box
editarUsando a box do Debian Jessie 64 bits como base para configuração do servidor e criar a pasta para o projeto
# Baixar box do debian Jessie
vagrant box add debian/jessie64 https://atlas.hashicorp.com/debian/boxes/jessie64
# Criando pasta do projeto e iniciando a imagem
mkdir ~/project_zenit
cd ~/project_zenit
vagrant init debian/jessie64
Na pasta do project_zenit será criado apenas o Vagrantfile default, este deverá ficar da seguinte forma:
# -*- mode: ruby -*-
# vi: set ft=ruby :
# Please don't change it unless you know what you're doing.
Vagrant.configure("2") do |config|
# Define the name of the box used to start the machine
config.vm.box = "debian/jessie64"
# Define a network to allow host-only access
config.vm.network "private_network", ip: "192.168.33.10"
# Configure to bind the port of host 8000 to guest 3000 used by rails
config.vm.network "forwarded_port", guest: 3000, host: 8000
# config.vm.provider "virtualbox" do |vb|
# # Display the VirtualBox GUI when booting the machine
# # vb.gui = true
# # Customize the amount of memory on the VM:
# # vb.memory = "1024"
# end
# Define a configuration script to execute and configure all necessary things
# in virtual machine in first creation
config.vm.provision :shell, path: 'gcs.sh'
end
Justificativa do uso do script sh
editarNo projeto, não tinha definido um procedimento para instalação e configuração do ambiente para desenvolvimento. Logo, este plano define um script em bash para que novos contribuidores que não desejarem utilizar o vagrant para o desenvolvimento, poderão se guiar na configuração pelo script shell. Feito para o debian e suas distribuições.
Deve ser criado um arquivo chamado gcs.sh, no mesmo diretório do Vagrantfile com o seguinte conteúdo:
#!/bin/bash
# Update index of packages and install essential softwares
apt-get update
apt-get install -y git curl
sudo -su vagrant
## Instaling RVM - ruby environment manager
# Obtain gpg key for rmv install
gpg --keyserver hkp://keys.gnupg.net:80 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
# Show progess bar while download rvm
echo progress-bar >> ~/.curlrc
# Download the installer for rvm and install the ruby stable version
\curl -sSL https://get.rvm.io | bash
# Set rvm to actual shell bash
source /usr/local/rvm/scripts/rvm && source /home/vagrant/.rvm/scripts/rvm
# Install ruby version of project
rvm install 2.2.1
# Define ruby 2.2.1 as default
rvm use --default 2.2.1
# Install Rails 4.2.4 without Documentation to speedup
gem install rails --version 4.2.4 --no-doc --no-ri
# Clone repository
git clone https://github.com/ZenitAerospace/gestao-pessoas.git
# Change the permissions of this directory to user execute too
sudo chmod -R 755 gestao-pessoas/
sudo chown -R vagrant gestao-pessoas/
# Move to repository
cd gestao-pessoas
# Install gem and dependencies
bundle install
# Configure database
rake db:create
rake db:migrate
rake db:seed
Usando a box
editarApós a criação e alteração destes arquivos, deve-se realizar a configuração e inicialização da máquina
# Inicia máquina virtual
vagrant up
# Acessa máquina virutal
vagrant ssh
Deploy Automatizado
editarEssa seção tratará sobre a configuração necessária para fazer um deploy automatizado do projeto Zenit Aerospace, utilizando o Travis CI, Capistrano e um servidor hosteado pela Digital Ocean.
Preparando Servidor
editarAntes de tudo, é preciso preparar o servidor para deploy. Para isso foi instalado o nginx e o thin para servir o website em ruby, assim como ruby e rails utilizando a ferramenta rvm.
Adicionando usuário
editarEm uma máquina com debian 8 recém instalada, adicione um usuário comum, pertencente ao grupo sudo, para não instalar tudo como root.
visudo # a linha %sudo ALL=(ALL:ALL) ALL deve estar descomentada
adduser zenit
adduser zenit sudo
Instalando ferramentas
editarInstale ruby e rails com rvm. Parte dessa instalação segue os mesmo passos que a configuração da máquina vagrant.
# Entre como usuário root, se já não estiver
su - root
# Atualize o repositório e baixe algumas ferramentas úteis
apt-get update
apt-get install -y git curl tree vim
# Adicione o script de configuração rvm a nível de sistema
echo "source /home/zenit/.rvm/scripts/rvm" >> /etc/bash.bashrc
Em uma máquina com debian 8 recém instalada, adicione um usuário comum, pertencente ao grupo sudo, para não instalar tudo como root.
# Troque para o usuário da zenit
su - zenit
# Obtenha a chave gpg para instalar o rvm
gpg --keyserver hkp://keys.gnupg.net:80 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
# Mostre a barra de progresso enquanto baixa rvm
echo progress-bar >> ~/.curlrc
# Baixe o instalador e execute no bash
\curl -sSL https://get.rvm.io | bash
# Carregue as configurações do rvm adicionadas há alguns passos atrás
source /etc/bash.bashrc
# Instale a versão ruby para o projeto
rvm install 2.2.1
# Defina como a versão padrão
rvm use --default 2.2.1
# Instale Rails sem documentação para agilizar a instalação
gem install rails --version 4.2.4 --no-doc --no-ri
# Instale o servidor thin para hostear serviços Ruby
gem install thin
# Mude para usuário com poder de administrador
su - root
# Instale o servidor thin para hostear serviços Ruby
thin install
# Instale o servidor nginx para hostear serviços Web
aptitude install nginx
Configurando serviço Web
editar# Configure o serviço web
vim /etc/nginx/sites-available/gestao-pessoas
O arquivo deve ter conteúdo semelhante ao seguinte:
upstream myapp {
server 127.0.0.1:3000;
server 127.0.0.1:3001;
server 127.0.0.1:3002;
}
server {
listen 80;
server_name .example.com;
access_log /home/zenit/gestao-pessoas/log/access.log;
error_log /home/zenit/gestao-pessoas/log/error.log;
root /home/zenit/gestao-pessoas;
index index.html;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
try_files /system/maintenance.html $uri $uri/index.html $uri.html @ruby;
}
location @ruby {
proxy_pass http://myapp;
}
}
Clonando projeto
editarPara hostear o serviço da Zenit basta clonar o projeto em uma pasta que será indicado nas configurações do nginx.
# Troque para o usuário da zenit
su - zenit
# Troque de diretório e clone o projeto
cd ~
git clone https://github.com/ZenitAerospace/gestao-pessoas.git
cd gestao-pessoas
bundle install
rake db:create
rake db:migrate
rake db:seed
Inicializando serviço Web
editarHabilite o site para nginx e crie arquivos de configuração do thin. Então mude o dono do diretório e reinicie o serviço web do nginx.
ln -nfs /etc/nginx/sites-available/gestao-pessoas /etc/nginx/sites-enabled/gestao-pessoas
thin config -C /etc/thin/gestao-pessoas -c /home/zenit/gestao-pessoas --servers 3 -e development
chown -R zenit. /home/zenit/gestao-pessoas/
/etc/init.d/thin restart && /etc/init.d/nginx reload; tail -f log/*.log
Deploy com Capistrano
editarAdicione gems do capistrano no Gemfile.
vim Gemfile
Adicione as seguintes linhas no final do arquivo.
group :development do
gem 'capistrano', '~> 3.6'
gem 'capistrano-rails', '~> 1.2'
end
Instale as novas gems.
bundle install
Execute a gem para criar arquivos de deploy.
bundle exec cap install
Execute o deploy.
cap production deploy
Deploy Automático
editarTroque de usuário para zenit. Crie uma chave ssh e autorize seu acesso.
su - zenit
ssh-keygen -t rsa -b 4096 -N '' -f /home/$USER/.ssh/id_rsa \
-C "$USER@$(uname -n).$(cut -f 1 -d ' ' /etc/issue | head -n 1 | sed -e 's/\(.*\)/\L\1/')"
cat /home/zenit/.ssh/id_rsa.pub >> /home/zenit/.ssh/authorized_keys
chmod 0600 /home/zenit/.ssh/authorized_keys
cat /home/zenit/.ssh/id_rsa.pub > deploy_id_rsa.pub
Adicione os passos para deploy após o sucesso da integração contínua.
vim .travis.yml
Indique a branch de deploy para o travisCI e adicione as seguintes linhas para deploy.
branches:
only:
- master
- develop
- deploy
[...]
after_success:
- "openssl aes-256-cbc -K $encrypted_cab6a4cb5a16_key -iv $encrypted_cab6a4cb5a16_iv -in config/deploy/deploy_id_rsa.enc -out config/deploy/deploy_id_rsa -d"
- "eval $(ssh-agent)"
- "chmod 600 config/deploy/deploy_id_rsa"
- "ssh-add config/deploy/deploy_id_rsa"
- "gem install capistrano-rails"
- "cap production deploy"
Para cada pull request, TravisCI vai fazer a integração, e executar os passos de deploy automático após o sucesso desta integração. Esses passos vão permitir o acesso ao servidor, instalar a gem capistrano e realizar o seu deploy.