Templates docs

README_TEMPLATE.md

Nome do produto

Descrição curta sobre o que seu projeto faz.

De um a dois parágrafos sobre o que é seu projeto e o que ele faz.

Instalação

OS X & Linux:

npm install my-crazy-module --save
apt-get install $(cat requirements.apt)

Mac: (caso exista peculiaridades de SO)

npm install my-crazy-module --save
brew install $(cat requirements.brew)

Windows:

edit autoexec.bat

Exemplo de uso

Alguns exemplos motivamentes e úteis sobre como seu projeto pode ser utilizado. Adicione blocos de códigos e, se necessário, screenshots.

Ambiente

Configure as variáveis de ambiente de acordo com o ambiente .env-development, .env-stage e .env:

API_URL=https://myawesome.api
SENTRY_DSN=https://sentry.com

para acessar as variáveis:

import config from '../config/env';

config.api.url
config.sentry.url

Configuração para Desenvolvimento

Descreva como instalar todas as dependências para desenvolvimento e como rodar um test-suite automatizado de algum tipo. Se necessário, faça isso para múltiplas plataformas.

npm test

Histórico de lançamentos

• 0.2.1
  • MUDANÇA: Atualização de docs (código do módulo permanece inalterado)
• 0.2.0
  • MUDANÇA: Remove setDefaultXYZ()
  • ADD: Adiciona init()
• 0.1.1
  • CONSERTADO: Crash quando chama baz() (Obrigado @NomeDoContribuidorGeneroso!)
• 0.1.0
  • O primeiro lançamento adequado
  • MUDANÇA: Renomeia foo() para bar()
• 0.0.1
  • Trabalho em andamento

Meta

Seu Nome – @SeuNome – SeuEmail@exemplo.com

Distribuído sob a licença XYZ. Veja LICENSE para mais informações.

https://github.com/yourname/github-link

api.md

Templates

Readme

Issue

Pull Request

Changelog

Contributing

Para aplicar os templates de forma automática basta criar na raiz do projeto a pasta .github e copiar os arquivos.

CHANGELOG.md

Changelog

Unreleased

1.11.0 - 2018-03-26

Added

• Tela de Garantia e Proteções
• Visualização de Danfe e download de XML

Changed

• Refactoring Orders API
• Refactoring Services API
• Refactoring ProgressBar UI
• Refactoring Timeline UI

1.10.4 - 2018-03-08

Fixed

• Add float unset to img-all-menus

1.10.3 - 2018-02-09

Fixed

• Front-end tests

-- The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

CONTRIBUTING.md

Fluxo de desenvolvimento

Convenções

1. Utilize as iniciais do seu nome e o tipo de alteração que sua branch representa como prefixo ao nome do branch que for criar. Exemplo: mo-fix-queue

Bug fix: mo-fix-

Funcionalidades: mo-feature-

Débitos técnicos: mo-enhancement-

Regras

1. Sempre

• Faça fork!
• Desenvolva apenas em seu branch.
• Faça rebase com o master antes de criar pull requests.
• Se esforce para manter o master o mais limpo possível.
• Faça rebase do master em seu branch diariamente, se possíevl mais de uam vez por dia.
• Faça commits pequenos, que descrevem alterações únicas. (Leia: Commit Guidelines)
• Faça squash dos seus commits que não estão completos (Work In Progress)

2. Nunca

• Desenvolva direto no master.
• Faça merge de branches no master antes que o código seja revisado.
• Revise pull requests que:
  • Não estejam atualizados com o master.
  • Tenham testes quebrando.

Processos

Desenvolvimento

Bug fixes

Para trabalhar em bug fixes, utilize o branch master como base.

1. Faça o fork do projeto: git clone https://github.com/luizalabs/projeto
2. Faça um fetch e checkout do master:

• git fetch --all
• git checkout master

3. Crie seu branch:

• git checkout -b mo-fix-queue

4. Enquanto estiver desenvolvendo

• Diariamente:
  • git checkout master
  • git pull upstream master
  • git checkout mo-fix-queue
  • git rebase master
• Eventualmente - possivelmente mais de 1 vez por dia: git push origin mo-fix-queue

5. Após terminar o desenvolvimento

• Disponibilize seu branch para teste da funcionalidade - seja em um sandbox ou no ambiente local. Se a funcionalidade não for validada, volte ao passo 4.
• Conserte os testes que estiverem falhando.
• Atualize o versionamento do projeto (no padrão de versionamento semântico).
• Preencha o CHANGELOG.md com as alterações realizadas em seu branch.
• Faça push do seu branch para o repositório: git push --force origin mo-fix-queue
• Crie o pull request branch: master.
• Notifique que o pull request foi criado no canal do slack de sua equipe.
• Interaja com o revisor de seu pull request quantas vezes forem necessárias.
• Após o Pull Request aprovado:
  • Considere fazer squash de alterações pontuais que tenham sido feitas durante a revisão.
  • Faça rebase com o master, caso seu branch esteja desatualizado.

Funcionalidade

Para trabalhar em novas funcionalidades, utilize o branch canary como base.

1. Faça o fork do projeto: git clone https://github.com/luizalabs/projeto
2. Crie seu branch com base no canary:

• git checkout -b mo-feature-queue

4. Enquanto estiver desenvolvendo

• Diariamente:
  • git checkout canary
  • git pull upstream canary
  • git checkout mo-feature-queue
  • git rebase canary
• Eventualmente - possivelmente mais de 1 vez por dia: git push origin mo-feature-queue

5. Após terminar o desenvolvimento

• Disponibilize seu branch para teste da funcionalidade - seja em um sandbox ou no ambiente local. Se a funcionalidade não for validada, volte ao passo 4.
• Conserte os testes que estiverem falhando.
• Atualize o versionamento do projeto (no padrão de versionamento semântico) com o o sufixo -canary.x.
• Preencha o CHANGELOG.md na seção de unreleased com as alterações realizadas em seu branch.
• Faça push do seu branch para o repositório: git push --force origin mo-feature-queue
• Crie o pull request branch: canary.
• Notifique que o pull request foi criado no canal do slack de sua equipe.
• Interaja com o revisor de seu pull request quantas vezes forem necessárias.
• Após o Pull Request aprovado:
  • Considere fazer squash de alterações pontuais que tenham sido feitas durante a revisão.
  • Faça rebase com o master e canary, caso seu branch esteja desatualizado.
• Crie uma tag e pre-release no github.

Revisão

Guidelines:

Pull request

1. Garanta que a descrição PR esteja seguindo o template e descrições claras e objetivas.

• Sempre informe como monitorar a alteração que o PR está implementando.
• Solicite print ou maiores informações na seção Outras informações

2. Seja duro, fará bem a todos: não faça revisões caso as regras descritas acima não tenham sido cumpridas. Se não forem, avise o desenvolvedor para que ele possa cumprir os requisitos e atualizar o branch dele - um novo pull request pode não ser necessário.
3. Se você não entender o código que está lendo, pergunte. Faça perguntas mesmo que achar ou tiver certeza que elas são ingênuas ou simples demais, esse comportamento trará transparência e incentiva os outros desenvolvedores a agir da mesma forma - os encorajam a perguntar sempre que tiverem dúvidas.
4. Sugira melhorias, use o bom senso e entenda o padrão do projeto antes de sugerir possíveis perfumarias.
5. Se o pull request for claramente ruim, recuse.
6. Antes de realizar o merge:

• Ao menos 2 revisores são necessário para o PR ser apto ao merge
• Ao menos 1 revisor precisa ser proficiente na linguagem do projeto

7. Exclua o branch após realizar o merge dele no master.

Changelog

Escreva o changelog como se estivesse descrevendo quais mudanças foram introduzidas no release para um colega de time. Adicione o changelog ao projeto no Hub, em português e com uma linguagem mais geral e abrangente (sem muitos detalhes técnicos).

Úteis

• Alias para rodar git lg com log colorido e com níveis de merge/branches explícitos:
  • git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

Recomendações

Arquivos

Plugins

• Instale o editorconfig em seu editor de código favorito.
• Intale o commitizen cli para auxiliar nas mensagens dos commits.
  • Use git cz ao invés de git commit

ISSUE_TEMPLATE.md

### É um relatório de erros?
Sim

### Comportamento atual
e.g. Em pedidos de modalidade retiraloja não está aparecendo os dados do cliente que vai retirar o produto.

### Reprodução do comportamento
e.g. No `https://meuespaco-debug.magazineluiza.com.br/pedidos` e pesquise pelo pedido `xxxxxxxx`. Ao detalhar o pedido os dados do cliente que vai retirar não aparece no box de entrega.

### Comportamento esperado
e.g. Exibir os dados do cliente que vai buscar o produto na loja.

### Funcionou em versões anteriores?
e.g. Sim, na versão 1.0.2 estava aparecendo os dados do cliente.

PULL_REQUEST_TEMPLATE.md

**Qual o tipo de alteração que esse PR introduz? (Bug fix, feature, docs update, ...)**
e.g. Feature.

**Qual é o comportamento atual? (Você pode conectar a uma issue ou um chamado aqui)**
e.g. A aplicação não possui chat.

**Qual é o novo comportamento?**
e.g. Foi implementado um novo chat.

**Será que esse PR introduz alguma alteração de quebra?**
e.g. Não.

**Outras informações:**

Observações, prints, ou qualquer outro tipo de informação que queira colocar