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.
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)
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:
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.