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.

1. Gestão de Projetos

• Práticas
• Issues e Boards

2. Gestão de Código

• Git
  • Criando uma nova feature
  • Code Review e Merge

3. Linguagens e Frameworks

• Ruby
• Rails

4. Práticas e Metodologias

• Continuous Integration
• Test-Driven Development
• Testes e Coverage

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

• 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 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.

• Collective Ownership: Todos são ao mesmo tempo responsáveis e donos do projeto e sua arquitetura.

• Code Review: Colocando em prática o Collective Ownership. Todo código é revisado pela equipe antes de ser colocado em produção.

• Deploy Contínuo: Realizamos diversos deploys por dia.

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

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

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

A cada nova feature, criamos uma branch chamada feature/something, com um nome descritivo da funcionalidade que estamos desenvolvendo (em inglês). Essa branch deve ser criada a partir da master.

git checkout master
git checkout -b feature/something
git push -u

Escreva o código e faça seus commits. Procure fazer commits logicamente separados para facilitar o entendimento da evolução do código. Você pode utilizar o git add -p para adicionar apenas partes das suas alterações ao índice, antes de fazer seu commit.

git add -p
git commit

Nossas mensagens de commit são sempre no presente, em inglês. A mensagem deve conter na primeira linha um resumo do commit, em no máximo 50 caracteres, separada por uma linha em branco e os detalhes da mudança. Todas as linhas devem possuir no máximo 72 caracteres.

Notify users about their status.

* More details about this commit.
* Much more details about this commit.

https://github.com/sumoners/my-project/issues/123

Sempre que algo novo surgir na master, você precisar fazer um git rebase na sua branch. Dessa forma a arvore de commits do repositório permanecerá sempre linear.

git fetch origin
git rebase origin/master

Ao finalizar suas alterações, caso tenha executado diversos commits, organize-os em commits lógicos e completos com um git rebase interativo. Você não deve ter commits como "Fix rubocop issues".

git rebase -i origin/master

Caso você já tenha enviado suas alterações para o servidor anteriormente, você precisará forçar o envio após executar qualquer rebase. Isso acontece pois a árvore de commits foi alterada.

git push -f

Com tudo pronto, faça um Pull Request novamente para a branch master. Lembre-se de utilizar um título descritivo, bem como uma descrição do que foi realizado, para facilitar o Code Review. Na mensagem do Pull Request inclua um link para o issue (caso exista).

Copie o link do pull request e cole no Slack, mencionando os pontenciais revisores para o seu código.

Se você foi chamado para revisar uma feature, tente fazer o quanto antes. Você não precisa parar tudo o que está fazendo para fazer o Code Review, mas no primeiro intervalo que tiver, faça. Lembre-se, logo mais será você que precisará ter seu código revisado.

Não procure revisar a sintaxe do código, para isso temos o CI. O objetivo no code review é analisar a abordagem ao problema, entender como a solução aplicada se relaciona ao restante da aplicação, procurar falhas de segurança que podem ser exploradas, verificar pontos que não foram cobertos por testes e principalmente absorver o conhecimento desse novo trecho que código, para que você também possa modificá-lo no futuro.

Caso encontre problemas, comente no código. Caso esteja tudo OK, comente no Pull Request, sinalizando que está tudo certo e o Merge pode ser realizado.

Após receber a confirmação de que está tudo OK, realize o merge e apague sua branch.

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 CI ou no Code Review :)

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)
  • JSHint

• Todos os testes acima são executados automaticamente pela plataforma de integração contínua CircleCI.

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

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 master, 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, utilizamos o sprint planning para debater o problema e tentar definir a melhor abordagem para ele.

Criamos testes de integração para APIs utilizando RSpec Api Documentation e para aplicações web com Capybara. Para testes unitários, procuramos testar models e qualquer outra classe de serviço que a aplicação venha a ter (Service Objects, Workers, etc.)

Com excessão de testes mais complexos, procuramos fazer o menor uso possível de mocks, mesmo que isso leve diversos testes a quebrarem com apenas uma mudança. O objetivo é procurar diminuir a dependência dos testes de uma implementação específica e simplificar a leitura dos testes.

Utilizamos o modelo de quatro etapas para a escrita dos testes:

• Configuração: Criamos os objetivos de que dependem os testes.
• Teste: Executamos o teste.
• Verificação: Verificamos se os resultados dos testes foram os esperados.
• Limpeza: Limpeza dos dados criados para o teste. (normalmente executada automaticamente, através do Database Cleaner).

Miramos em 95% de coverage no código.