/workflow

SumOne Workflow informations

Workflow da SumOne

Esse documento visa padronizar todos os elementos que compõem nosso fluxo de trabalho.

Isso permite que novos desenvolvedores entrem em nossa equipe e consigam rapidamente começar a trabalhar em nossos projetos bem como disciplina nosso modus operandi, deixando nosso tempo disponível para fazermos aquilo em que somos ótimos: criar produtos que mudam o mundo.

Conteúdo

  1. Gestão de Projetos
  1. Gestão de Código
  1. Linguagens e Frameworks
  1. Práticas e Metodologias
  1. Guias Práticos

Contribuindo com nosso workflow

O workflow só será revisto durante duas datas pré-determinadas:

  • Todo dia 15 de Junho
  • Todo dia 15 de Janeiro

Na revisão, serão abordados os issues abertos neste repositório, após passarem por um filtro prévio pela equipe de gestão, que serão levados a discussão e aprovados ou reprovados pelos presentes.

Dessa forma, quer contribuir com o workflow? Crie um issue e chame os colegas para a discussão!

Fazemos a gestão dos nossos projetos com SCRUM, mas não utilizamos todas as práticas, fazemos nosso próprio mix.

As práticas que utilizamos na SumOne são:

  • Papéis: Product Owner, Scrum Master

  • Product Backlog: Um documento que mostra as funcionalidades desejadas do produto, contendo Objetivo, Descrição e Requisitos, Definição de "feito" e Notas.

  • Features: O Product Backlog é composto de diversas features ou funcionalidades, que são levadas para o sprint planning.

  • Sprint Planning: Realizado antes de começar cada sprint, na sala de reuniões, durando no máximo 6 horas.

  • Sprint Task: Uma tarefa que foi especificada durante o sprint planning.

  • Sprint: 10 dias úteis para realizar todas as tarefas definidas no sprint planning.

  • Pontuação: Cada ponto corresponde a um dia de trabalho/homem. A pontuação mínima é 0.5 (meio dia). A pontuação de cada sprint task é definida no sprint planning, a partir do método Planning Poker.

  • SCRUM Place: Um lugar no escritório com um sofá, um quadro para discussão e a SCRUM Board com um Burndown Chart.

  • SCRUM Board: Um quadro contendo as pipelines do sprint: to do, doing, qa, done.

  • Burndown Chart: O jeito mais fácil de ver se o sprint está indo tão rápido quanto o combinado.

Todos os tópicos podem ser consultados na Wikipedia :)

Para manter o time todo atualizado do que está acontecendo no projeto e o que está por vir, usamos os issues do GitHub, para features, sprint tasks, bugs e ideas.

Usamos uma extensão do Chrome chamada ZenHub para organizar as pipelines da mesma forma que na nossa scrum board.

Utilizamos Git para fazer a gestão do nosso código.

Com relação ao Git, usamos as seguintes práticas:

  • Usamos a gem git up para dar um update no nosso repositório local.

  • Fazemos nossas mensagens de commit sempre no pretérito, usando a primeira pessoa do singular: "Fiz o sistema de gestão de notícias", "Arrumei o bug #22", "Tentei fazer ..."

  • As mensagens de commit são sempre em inglês.

  • Para organização dos branches, usamos o modelo Git Flow, com a excessão de que ao invés de fazermos um merge da feature que estamos trabalhando com a branch develop, nós criamos um pull request no GitHub para esse fim.

  • Antes de criar um Pull Request, faça um rebase da branch develop com a sua feature branch para garantir que seu código está up to date e evitar conflitos no pull request.

Para mais informações, veja o guia prático Git Workflow

Usamos o sistema Semantic Versioning 2.0.0 para controle de versão, sendo definido o seguinte:

  • Hotfixes mudam o patch: 0.0.X
  • Releases mudam o minor: 0.X.0
  • Marketing muda a major: X.0.0

Esse esquema fecha bem com os conceitos do git flow que comentamos antes.

Para cada linguagem e framework temos um conjunto de regras e boas práticas. Siga as boas práticas para não ser barrado pelo QA :)

As boas práticas e regras que usamos quando usamos Ruby são as seguintes:

  • Para o estilo de código, usamos as regras do Ruby Style Guide.

  • Sempre que mexemos no Gemfile, comentamos a gem que colocamos dizendo o que ela faz e o motivo de adoção da mesma (se aplicável). Ex: "Devise - Faz a autenticação de usuários", "Ruby Geocoder - Geoencoda latitude e longitude - Coloquei para a ferramenta de polígono".

  • Para toda e qualquer frase que usamos nas views, usamos I18n

  • Atualizamos sempre. Saiu uma nova versão do Rails? No próximo sprint já vamos atualizá-lo!

  • Obedecemos ao padrão REST, sempre, incondicionalmente.

  • Não somos muito apegados a dark magic nem a práticas que fujam do padrão do Rails, mas usamos Service Classes.

  • Não hesitamos na hora de comentar código. Toda classe deve ter comentários indicando para que ela veio ao mundo. Usamos as convenções do Rails para organizar nossa documentação.

  • Uma sprint task nunca pode ser considerada feita se não passar nos seguintes testes:

    • RuboCop (Ruby Style Guide Compliance)
    • SCSS Lint
    • Brakeman (Segurança)
    • Flay (Assegura um código DRY)
    • JSHint
    • Rails Best Practices
    • Reek (Code Smell, apenas para models)

Stack

O stack padrão que usamos no Rails, para resolver cada tipo de problema está listado abaixo:

Problema Gem
Organizar as gems de assets Rails Assets
Templating ERB (está aqui só para ninguém nunca usar HAML)
Melhoria de CSS SASS
Processamento de Queues Sidekiq
Autenticação Devise
Autorização CanCanCan
Formulários Easy Breezy Simple Form
Upload Carrier Wave
Jobs Recorrentes/Cron Whenever
Paginação Kaminari
Caching Redis
Multi-Tenancy Apartment
Respostas de API Serializers
Testes RSpec
Factories Factory Girl

Todos os dias damos push no nosso código para o GitHub. Nosso servidor de CI possui um hook que roda automaticamente os testes da aplicação para verificar se você quebrou algo.

As regras são:

  • Quebrar algo numa feature branch não tem problema, se você ainda estiver trabalhando nela.

  • Se você por acaso quebrar a branch develop, você deve parar tudo o que estiver fazendo para consertá-la. (Quem quebra arruma).

Usamos a metodologia de Test-Driven Development quando é conveniente, mas não somos completamente ortodoxos: usamos quando faz sentido.

Sempre é bom, no entanto, ter uma visão geral do problema e da estrutura para evitar o retrabalho. Para isso, discutimos exaustivamente no sprint planning e antes de o projeto começar.

Como regra geral, testamos apenas Testes de Integração e de Models.

Miramos em 95% de coverage no código.

Para começar uma nova Feature associado a uma issue é necessário seguir os seguintes passos:

Criando nova Feature

Garanta que o seu repositório de Development esteja atualizado:

# acessar a pasta onde está o código fonte
gem install git-up --no-doc --no-ri # caso não esteja instalado
git-up

Criar uma nova branch:

git checkout -b nome_branch

Realizar as alterações necessárias no código, e ao final seguir os seguintes passos:

git status # para verificar quais foram as atualizações realizadas
git add -A # adicionar os arquivos alterados para efetuar o commit
git commit -m "Descrição das alterações"
git up # atuliza todos os seus branchs
git merge development # para trazer todas as alterações realizadas no development para o seu branch e evitar conflitos.
git push origin nome_branch # efetua o "push" para o GitHub

Entrar na página do repositório onde foi realizado o push e criar um Pull Request https://help.github.com/articles/using-pull-requests/ Atentar na escolha do base:, sempre selecionar development.

Na descrição do pull request criado incluir uma das palavras chave para linka-lo a Issue https://help.github.com/articles/closing-issues-via-commit-messages/

Feito isso agora é aguardar para que alguem verifique o seu request e efetue o Merge ou seja necessário efetuar algum ajuste na alteração enviada. Caso isso ocorra, quem estiver analisando vai inserir um comentário no pull request.