Workflow GIT para o desenvolvimento do SIGA

Workflow GIT para o desenvolvimento do SIGA

- in Development
28
0

O SIGA é desenvolvido por uma equipa cada vez crescente de desenvolvedores. Para garantir a fácil integração das alterações no código-fonte, várias ferramentas são usadas, incluindo: Git, Github, Phabricator, etc. Neste artigo, pretendo descrever o Workflow de desenvolvimento e integração que é usado no desenvolvimento do SIGA.

O workflow usado no desenvolvimento do SIGA é uma combinação das seguintes fontes:

https://gist.github.com/sekimura/6367366

http://blog.dcycle.com/blog/81/setting-phabricator-review-code/

http://nvie.com/posts/a-successful-git-branching-model/

Repositório de código-fonte

O código-fonte do SIGA está alojado num repositório privado do Github(https://github.com/backstageel/opensga).  Existe também um mirror(espelho) deste código no Phabricator(http://projectos.infomoz.net/diffusion/1/) que também é privado. Todas as alterações são feitas usando o repositório do Github, que por sua vez é sincronizado automaticamente com o mirror do Github.

Branches

O repositório do SIGA possui 4 branches principais: master, stable, v3-master e v3-stable.  os branches master possuem sempre a versão mais recente do SIGA, e geralmente não são estáveis o suficiente para serem enviados para o servidor de produção. Só depois de todos testes serem feitos, é que estes branches são sincronizados com o stable e a partir do stable, são enviados para o servidor de produção.

Além disso, cada desenvolvedor cria vários branches locais na sua máquina de desenvolvimento, de acordo com a funcionalidade que está a desenvolver. Esses branches nunca são enviados para o Github, pois servem apenas para o desenvolvimento local de uma funcionalidade, e são apagados assim que a funcionalidade estiver completa e integrada no branch master. branches locais também podem ser descartados sem ser integrados, caso a funcionalidade se prove desnecessária.

Review das alterações no código

Antes das alterações feitas localmente serem integradas no branch master e enviados para o github, elas devem passar por um processo de revisão, que pode ser feito por um ou mais developers da team. O Review do código é feito usando o Differential, uma ferramenta do Phabricator específica para esta actividade.

Depois da revisão ser aceite, as alterações são enviadas para o branch master, que é depois integrada ao stable, após todos testes serem feitos. A partir do stable, as novas funcionalidades ou alterações são enviadas para o servidor de produção.

Testes Unitários e Testes de Integração

Cada desenvolvedor deve garantir que as alterações feitas no branch local não quebram as outras funcionalidades existentes no SIGA. para tal, antes de solicitar a revisão da funcionalidade, deve executar todos testes unitários do projecto. Assim, a revisão do código consiste apenas na revisão da lógica, optimização e sintaxe do código, uma vez que testes unitários já terão garantido que  as alterações não quebram nenhuma funcionalidade do sistema.

Depois da integração da funcionalidade no branch master, ou seja, depois do review ser aceite, o desenvolvedor também irá executar testes unitários no branch master, para garantir que a integração também não quebrou nenhuma funcionalidade. Só depois disso é que o repositório no Github é actualizado.

Deployment do SIGA

Para deployment do SIGA, usamos o Rocketeer. O Deploy para o servidor de produção é feito a partir do branch stable. Assim, garantimos que a qualquer momento o deploy pode ser feito, uma vez que o branch stable está sempre pronto para produção.

Além do servidor de produção, é feito um deployment para o servidor de testes, sempre que  o branch master é actualizado.

 

Resumo

De uma forma resumida, um desenvolvedor do SIGA executa as seguintes tarefas durante o desenvolvimento:

1. Actualizar a sua cópia local de desenvolvimento

git pull origin

ou

git clone https://github.com/backstageel/opensga.git

2. Cria um branch de acordo com a funcionalidade na qual pretende trabalhar. O branch deve ser criado usando o master como base.

git checkout -b cancela-renovacao-matricula

3. Trabalha sobre a funcionalidade, faz quantos commits quiser no branch criado e no fim executa testes unitarios

4. Envia as alterações para modificação usando Arcanist(deve ser instalado na maquina local e devidamente configurado segundo o link http://blog.dcycle.com/blog/81/setting-phabricator-review-code/)

 arc diff master

Com o comando acima, o código a ser enviado para revisão será o diff entre o branch local da funcionalidade e o branch master. O desenvolvedor indica tambem quem irá fazer o review

5. Um review faz o review usando a interface do Phabricator. Esta review pode ser aceite, mudanças podem ser solicitadas ou então pode ser rejeitada. Nos últimos dois casos, volta-se ao ponto 3. E em caso da review ser aceite, passa-se para o ponto 5.

6. Após a review ser aceite, faz-se o merge do branch da funcionalidade com o branch master, usando o comando que se segue:

arc land

O comando acima faz o commit das mudanças, faz o merge do branch com o master e envia o master actualizado para o repositório.
 

 

(Visited 17 times, 1 visits today)

About the author

Elísio Leonardo é um empreendedor digital, Especialista de Novas Mídias e criador do Porta Infomoz.net. Suas áreas de interesse são Marketing Digital, Gestão Empresarial e produção de conteúdos de qualidade para Internet

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

You may also like

Reprovação por Faltas e por Fraude no SIGA-UEM

O regulamento pedagógico da UEM prevê que um