Utilizando o fluxo Git Flow

Este artigo tem o intuito de expor uma abordagem de como trabalhar utilizando o fluxo git flow.

Se você já trabalha com o git como principal ferramenta de controle de versão, já deve ter visto várias abordagens de como utilizar e controlar branchs em um cenário de produção ou pessoal.

E se você é novo com git, este fluxo irá te ajudar a ter maior familiaridade de como empresas, projetos opensource costumam utilizar seus fluxos de trabalho.

É muito comum vermos pessoas utilizando somente um branch para fazer commits em projetos pessoais. Isto não é errado, é muito tranquilo de se controlar tudo em uma branch quando se está desenvolvendo sozinho, mas o cenário muda bastante quando temos que interagir com mais desenvolvedor ou contribuidores, seja em um projeto opensource ou privado.

Nessas horas é suma importância que se tenha total controle do que está sendo produzido por sua equipe, onde, ao mesmo tempo são corrigidos falhas, implementado novas funcionalidades e ter o seu código de produção com total funcionamento entregue ao seu cliente.

É ai que o fluxo de git flow nos ajuda, vem com o cabrito olhar a imagem abaixo para entender melhor:

Git Flow Model Nvie

A master irá contér todo código já testado, versionado que será entregue ao cliente e a develop é onde todo fluxo de trabalho irá ocorrer antes de fazer o release versionado que será feito merge na master.

A develop deve sempre conter o código mais atual, onde as branchs de features serão ramificadas tendo ela como base.

Exemplo, suponhamos que você precise criar um feature que mudará todo o fluxo e interface de um componente, como fariamos para criar nossa branch ?

Certifique-se de que a branch develop existe no seu repositório remoto listando suas branchs locais e remotas:

1
$ git branch -a

Caso não esteja, faça a sincronização do seu repositório remoto, faça o checkout criando sua branch develop e envie para seu repositório remoto:

1
$ git fetch origin && git checkout -b develop && git push origin develop

Após ter criado a develop, onde irá acontecer todo desenvolvimento, crie a branch respectiva a sua implementação, lembre-se de manter um padrão de nomenclatura para facilitar o entendimento como é sugerido no git flow:

feature: para novas implementações

release: para finalizar o release e tags

hotfix: para resolver problema crítico em produção que não pode esperar novo release

Neste caso, como já estamos na develop:

1
$ git checkout -b feature/novo-componente

Após criado, você trabalha em sua modificação localmente, caso seja necessário que outra pessoa trabalhe nesta mesma implementação você deve compartilhar para seu repositório remoto:

1
$ git push origin feature/novo-componente

Show, implementação feita, agora é hora de fazer o merge deste feature com a develop, para isto, faça o checkout para a branch develop, faça o merge da feature e atualize o remoto:

1
$ git checkout develop && git merge feature/novo-componente && git push origin develop

Caso não ocorra nenhum conflito, beleza, estamos prontos para fazer o release desta implementação e submeter ao repositório remoto, para isto, crie a branch de release e envie:

1
$ git checkout -b release/v1.0.1 && git push origin release/v1.0.1

Após feito os ultimos testes, você já pode fazer a tag da versão:

1
$ git tag -a v1.0.1 “Release do novo componente”

Lembrando, que se foi identificado algum bug durante o processo, você deve tratar este bug na branch de release, enviar para a master e para a develop também, fazendo que a develop sempre contenha as correções.

Nas hora de inserir a tag, gosto de utilizar tag anotadas, pois ela registra informações de quem fez a tag, data, hash, caso não queira estas informações, simplifique:

1
$ git tag v1.0.1

Agora vamos conferir se a tag foi criada e enviar para o repositório remoto:

1
$ git show v1.0.1 && git push v1.0.1

Se tudo correu bem, sua tag será criada e estamos aptos a fazer o merge com a master deste pequeno release na master:

1
$ git checkout master && git merge release/v1.0.1

Xablau GIF

Prontinho, desta forma, obtemos informações de todas as etapas do desenvolvimento, além de padronizar a nomenclatura das branchs facilitando na hora de puxar um log maroto.

Dica: Existe um plugin para facilitar a criação e organização do seu repositório utilizando o fluxo do git-flow, se liga nesse plugin massa!

Nvie Plugin Git Flow

Resumindo, aprendemos como controlar nossas branch separadas por suas responsabilidades, não impactando na master que é onde nosso código estável se mantém fiel, utilizamos tags para versionar nossas releases e ter um controle bem mais flexível.

Caso tenha faltado algum conceito em si, deixe seu comentário que assim que possível faço a correção marota, belezura?

Abraços do cabrito.

90 Dias de Ilegra

Neste post tenho objetivo de falar sobre os desafios que encontrei durante os primeiros 90 dias de Ilegra, empresa ao qual trabalho como Front End, sendo assim, vamos lá.

Para começar, tive o prazer de fazer todo o processo seletivo online através de testes no github e entrevistas via hangouts, o que facilitou muito minha vida.

Na primeira semana foi tudo muito novo para mim. Não tinha tanta experiência com metodologia ágil, micro serviços, o que me deixou meio fora dá casinha no início, mas logo o pessoal me situou e foi aí que veio a parte legal do trabalho.

Nunca tinha trabalhado com uma arquitetura de micro serviços, muito menos tinha esbarrado pelo conceito de BFF — Back For Front End .

Nunca tinha trabalhado em um projeto que de fato implementassem testes unitários e integração no front end. Sabia os malefícios da ausência destes testes, alguns desses:

  • Problemas difíceis de se rastrear
  • Menor integridade do código
  • Responsabilidades inchadas

No início tive um pouco de dificuldade para entender o que de fato deveria testar dentro de um serviço, o que de fato seria testar uma unidade, etc.

E foi aí que de fato aprendi a testar meus códigos, como estruturar meus testes para garantir a integridade entre meu controller e meu spec, o que me trouxe maior segurança quanto as modificações e seus efeitos colaterais.

Uma das coisas iradas que tive contato neste período foi a oportunidade de ler muito código alheio através dá prática de code review por pull request, onde o seu código é avaliado por outras duas pessoas desenvolvedoras antes de entrar de fato no repositório.

Aprender a ter apreço pelo design pattern, respeitar o style guide adotado pela equipe que compõem a sua aplicação foi uma das coisas mais importantes que aprendi. Independente dos seus gostos de configurações de editor, formas de se fazer tal coisa, lembre-se. Seus costumes e ferramentas JAMAIS devem influenciar na produção alheia, isto é o mínimo.

Durante este processo, tive contato com tantos profissionais geniais, reduzi muito minha curva de aprendizado, foi muito além do que eu esperava.

Esta semana completo meus 90 dias de Ilegra, sinto orgulho em vestir a camisa numa equipe de profissionais tão competentes.

Em geral gostaria de agradecer a todos que me ajudaram de forma direta e indireta neste meu processo evolutivo.

Um agradecimento especial ao Felipe Diogo, Cristiano Altmann, Victor Cesar, Marcello Mello, por mostrarem os aspectos negativos dos meus não patterns e acreditarem no meu potencial, foi graças a vocês essa evolução monstra!

Bora dale, por que cair, só se for pra cima.

I3 Window Manager

Tutorial de introdução ao i3

Este tutorial tem como objetivo apresentar o conceito usual de utilização de i3 como interface de janelas no Gnu/Linux. Levando em consideração que este tutorial foi testado para distribuição Debian Jessie – Ubuntu 14.04 .

Falando um pouco sobre o projeto original o i3 é um gerenciador de janelas muito leve, que suporta vários monitores, sendo possível colocar cada àrea de trabalho em uma tela automaticamente.

A movimentação dentro do sistema tem como base os atalhos de teclado, podendo também utilizar o mouse, porém com o tempo você se adapta e esquece que existe mouse :}.

Como os usuários Gnu/Linux sabem, a maioria de suas configurações são feitas por arquivos de configuração, no i3 não será diferente, sendo muito fácil de modificar e personalizar de acordo com o seu gosto.

Página oficial do projeto
Screenshot

Screenshot i3

Você irá encontrar inúmeros vídeos e howto no youtube para modificar sua interface de acordo com o que for achando necessário.

Sem mais, para a instalação em ambos sistemas é como qualquer outro programa:

1
$ sudo apt-get install i3

Após fazer a instalação do pacote, você deverá sair de sua sessão atual e escolher a interface do i3 para o login, após a o login ele irá lhe perguntar se você deseja gerar o arquivo de configuração no diretório ~/.i3/config que é o seu padrão, para aceitar basta dar Enter.

Irá surgir uma tela parecida perguntando se você deseja que a tecla MOD (Tecla Super, “aquela com a bandeirinha do Windows :}”) seja a tecla principal para as combinações de teclado, caso você queira trocar esta tecla, é somente apertar a tecla que deseja e apertar Enter, caso concorde com a MOD de enter (recomendo).

Para entender um pouco melhor sobre o que a tecla MOD faz, vamos tomar como exemplo o modo para abrir uma tela em fullscreen, neste caso, MOD + f e assim sucessivamente serão os outros atalhos, podendo você criar seus próprios atalhos para programas mais usados e tudo mais.

Sendo assim, segue a imagem que contém os esquemas básicos de atalhos:

Keyboard Map i3 - 1

Keyboard Map i3 - 2

Minha opinião sobre tal interface? Melhor impossível, tenho flexibilidade para trabalhar com inúmeros terminais e áreas de trabalho de forma prática, rápida e eficiente!

Detalhe muito importante é o seu consumo de memória que não passa de alguns Mbs.

Xablau GIF

Essa foi uma dica que me foi passada a muitos anos pelo Gustavo RPS.

Processo de Coaching

Fala pessoal, tudo numa boa? Haha, é isso!

Hoje estou aqui para falar um pouco sobre meu processo de coaching com o coach Jonathan Lamim.

Antes de falar de fato, gostaria de explicar o por que busquei o auxílio de um profissional de coaching.

Como todos da minha área, não fui diferente, estudando sempre sobre tecnologias que gostaria de trabalhar, visando boas práticas, com o uso de style guide, testes e o que a de melhor nos processos de desenvolvimento front end que tive envolvimento.

Foi ai que olhei pra mim, fiz uma breve análise, vi que estava completamente insastifeito determinadas atitudes na minha vida, uma delas é estar não estar envolvido num mercado forte para o meio tecnologico que curto.

Foi quando eu decidi ter um auxílio de um profissional que pudesse me orientar quanto me organição de processos e atividades pessoais, foi ai que a coisa mudou.

Durante as primeiras sessões já identifiquei inúmeras mudanças necessárias de comportamento para atingir o que almejo.

Trabalhamos bastante no meu perfil, até identificar que eu precisava estar em um ambiente de trabalho mais liberal, que me desse a liberdade de ter responsabilidades.

Definimos varios objetivos, acompanhamos semanalmente minhas métricas e formas de melhorias. Melhorei MUITO quanto a organização pessoal e isso me fez ter alto perfomance com auxílio de métricas ainda!

Utilizei algumas ferramentas de controle como Toggl para controle de tempo de minhas tarefas, o bacana é que consigo integrar ele com o Trello, dar start nas tarefas nos próprios cards e para dar um gastada nas métricas uso o Wakatime no VS Code para ver o que to utilizado de tecnologia :]

Resumindo, além de ter muito clareza em identificar os processos errôneos no meu cotidiano, consigo medir minha produção e aproveitar mais meu tempo para lazer e blá blá blá.

É isso! Até uma outra hora.

E po, comenta ae se você achou meio bosta, bacana e tal, valeu? :P

Abraço.