Release (rolling || fixed) => Git workflow

Precisamos definir algumas praticas de desenvolvimento na comunidade, a começar pelo fluxo de desenvolvimento e disponibilização de versões.

Atualmente o OpenRedu utiliza o Feature Branch Workflow para receber contribuições no código, que após revisão são integradas ao branch master, tornando-se disponíveis para deploy em produção. Uma abordagem adequada a Rolling Releases.

Considerando o atual contexto da comunidade, acredito que Fixed Releases seja uma abordagem mais adequada por permitir a disponibilização de versões mais estáveis e um planejamento mais adequado do ciclo de desenvolvimento.

Para apoiar essa abordagem, podíamos adotar algumas praticas do Gitflow no modelo de desenvolvimento.

Sugestões?

Referencia:
Comparing workflows
Workflows that work

1 Curtida

Li os links que você passou e achei muito interessante a estrutura do git-flow. Só conhecia o feature branch workflow mesmo. O git-flow é bem mais robusto que o atual feature branch workflow. Gostei principalmente da noção de tags e releases pois deixa tudo mais organizado e há uma idéia de planejamento para os releases.

Acho importantíssimo adotarmos também o versionamento do Semantic Versioning. Assim poderemos saber qual versão o Openredu está rodando em cada instância, saber quando uma nova versão não for compatível com versões anteriores, e todos outros benefícios que esse método traz.

1 Curtida

Já foi definido qual o fluxo de desenvolvimento e disponibilização de versões que será adotado para a comunidade?

Permanecerá utilizando Feature Branch Workflow ou irá adotar as prática do Gitflow?

Concordo com o uso de GitFlow e de Semantic Versioning.

Com a expansão do uso do OpenRedu, precisaremos lidar com diferentes ambientes e necessidades; dependendo do contexto, mudanças constantes de UX ou funcionalidades novas apenas funcionais - mas com baixa qualidade - podem ser prejudiciais a adoção, então o travamento em uma versão estável (branch master do GitFlow) naquele ambiente seria aconselhável.

A adoção dessas duas metodologias tem baixo custo (inclusive ferramentas como Tower e SourceTree suportam nativamente gitflow) e facilitaria o trabalho de integração contínua.

Que tal a versão resultante das contribuições da cadeira de ESE 2015.2 ser definida como 1.0.0 e, a partir dai, as duas práticas seres adotadas (e documentadas na Wiki)?

1 Curtida

Concordo em usar o GitFlow, pois organiza muito melhor, para controlar o trabalho da comunidade e também para lançar versões. Acho importante manter um branch de desenvolvimento, que contém todo o trabalho que está feito, mas não necessáriamente está em produção, deixando o branch master com a versão de produção, justamente como o GitFlow sugere. Fica muito mais fácil de corrigir bugs urgentes que devem ser corrigidos a partir da versão de produção, e não necessariamente quando for lançar uma nova versão (quando acontece o merge do branch do desenvolvimento com o master).

Eu já utilizo o Git-Flow em vários projetos, e na minha opnião é a melhor abordagem.

Pessoal, concluímos a elaboração de um Documento(wiki) de boas praticas de desenvolvimento a ser adotado pela comunidade… Tentamos abordar as sugestões aqui propostas, mas fiquem a vontade para sugerir melhorias:

1 Curtida

Está muito bom. Parabéns!