Ciclo de vida do desenvolvimento na Aberto
Hoje vou trazer um pouco sobre como é o ciclo de vida do desenvolvimento que utilizamos na Aberto.
Desde o início na Aberto sempre buscamos ter a cultura da agilidade muito forte em todos os nossos processos, afinal somos uma Startup e procuramos ao máximo não burocratizar as coisas e isso não foi diferente com o desenvolvimento de software, que é grande parte do nosso Core, sempre buscamos não reinventar a roda e sim utilizar padrões de mercado que nos ajude a alcançar nossos objetivos de maneira ágil, segura e com qualidade.
Então nesse ciclo utilizamos uma série de ferramentas, frameworks e conceitos de desenvolvimento para nos auxiliar a alcançar nossos objetivos.
Git Flow
Sim, utilizamos Git para controle de versão, isso hoje é quase uma unanimidade em diversos lugares pela sua simplicidade e gama de serviços que ele nos da. Ele simplesmente chegou para tirar o nosso medo de Merges e Branches.
Ta! Mas estamos falando do Git flow, o Git flow é um conceito de fluxo de trabalho utilizando o Git, ele define as melhores práticas de como organizarmos nossas Branches e termos um controle de versão ainda mais organizado. Com o crescimento das equipes a gestão do código começa a ganhar um pouco mais de complexidade, onde começa a surgir o tal dos “conflitos”, e logo não da pra cada um seguir fazendo as coisas do jeito que bem entender, e é assim que surgem os padrões.
Basicamente o modelo se baseia em duas Branches principais:
main/master
Onde deve conter apenas o código já testado, versionado e que será de fato publicado em ambiente de produção.
develop
Aqui você deverá sempre encontrar o código mais atual de sua aplicação contemplando todas as “features” ja prontas. Todo restante do “flow” partirá desta Branch.
Branches de Suporte
Além das duas principais branches, precisamos também das branches de suporte, elas vão nos apoiar ao realizar os desenvolvimentos em paralelo sem afetar o trabalho uns dos outros e também permitir uma rastreabilidade maior das funcionalidades e releases de nossa aplicação. Vamos a elas:
Branches de Features
O próprio nome já diz Features, ou seja, será aqui que criaremos nossas branches para criar as novas funcionalidades da nossa aplicação, costumamos sempre criar uma nova “feature-branch” para cada item do nosso Backlog que iremos iniciar o desenvolvimento. Ela sempre terá origem a partir do código mais atualizado da branch de “develop” e ao finalizar o desenvolvimento desta nova funcionalidade, o código deverá ser “mergeado” de volta para a branch “develop” e está “feature-branch” passará a não existir mais.
$ git checkout -b feature/my-new-featureBranches de Releases
Aqui prepararemos nosso código para um deploy. Então quando temos nosso código de “develop” finalizado, testado e realmente pronto para um deploy, podemos criar uma branch release para iniciar a preparação, ajustar seu número de versão ou release notes por exemplo. Quando o código está pronto para o deploy o código da “release-branch” deverá retornar para a branch “main/master” e logo ser tagueado para sua devida identificação futura e por fim o código também deverá refletir na branch de “develop” para que os próximos desenvolvimentos deem sequencia ao fluxo.
$ git checkout -b release-1.2$ ./bump-version.sh 1.2$ git commit -a -m "Aumentou o número da versão para 1,2"//
$ git checkout master$ git merge release-1.2$ git tag -a 1.2//
$ git checkout develop$ git merge --no-ff release-1.2
Branches de Hotfix
As Branches de Hotfix são muito parecidas com as “releases-branches”, pois também tem o objetivo de iniciar um novo deploy para o ambiente de produção, porém um deploy não planejado rs. Sim, todo sistema terá bugs e essas branches surgem justamente para corrigir algum bug crítico que exista no ambiente de produção. Quando isso ocorre será necessário a criação de uma “hotfix-branch” a partir da tag correspondente da branch “main/master” onde o bug foi identificado. Após realizado a correção a “hotfix-branch” deverá ser “mergeada” de volta para a branch “main/master”, atualizado sua versão (tagueando-a) e por fim atualizado a “develop-branch” exatamente igual as Branches de Releases. Ah e não esqueça de remover a “hotfix-branch” pois já não é mais necessária.
$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
$ git commit -a -m "Número da versão aumentada para 1.2.1"$ git commit -a -m "Corrigido problema grave de produção"//
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1//
$ git checkout development
$ git merge --no-ff hotfix-1.2.1//
$ git branch -d hotfix-1.2.1 Branch hotfix-1.2.1
Bom tudo lindo e maravilhoso e o mais importante organizado.
— Ok mas como eu posso garantir qualidade com esse processo?
A resposta para essa questão é o famoso Code Review, que sim temos como regra aqui dentro da Aberto.
— Mas o que é o Code Review?
Code Review será justamente o próximo assunto a ser abordado aqui :) juntamente com todas as outra etapas do nosso ciclo de desenvolvimento, então fique de olho e aguarde nosso próximo post…
.
.
