Skip to content

Latest commit

 

History

History
182 lines (113 loc) · 7.7 KB

CONTRIBUTING.pt-br.md

File metadata and controls

182 lines (113 loc) · 7.7 KB
Raw

Contribuindo para o Design System da Natura

Antes de começar

Recomendamos criar uma issue para trazer a sugestão e estimular conversas.

Note que temos um Código de Conduta. Por favor, siga as suas regras em todas as interações com as pessoas, documentação, código e discussões do projeto.

Como é o processo de criação de um componente para o Design System?

  1. Uma pessoa de uma squad puxa um card no nosso board (no card vai ter a especificação do que precisa ser implementado, como as variantes, propriedades, e os critérios de aceitação);

  2. A gente cria uma PR no GitHub com o nome do card, e lá a pessoa (ou o grupo de pessoas) da squad pode ir codando e enviando as alterações. Sempre tem uma pipeline rodando pra conferir se tem testes, se não tem problemas de código, etc.;

  3. Uma vez pronto, o código passa por validação (code review) e o componente passa por validação visual (usando as histórias que forem criadas no Storybook). A gente vai acompanhando as pessoas desenvolvedoras à medida que sugerimos ajustes, até a aprovação;

  4. Quando tudo estiver OK, o código é integrado com a branch principal, e é lançada uma nova versão do natds-web com o novo componente.

Passo-a-passo de contribuição

Como preparar meu ambiente de desenvolvimento para contribuir?

Node.js

Garanta que o seu ambiente tenha o Node.js instalado. Recomendamos pelo menos a versão 10.16.3 do Node.js. Idealmente, prefira versões superiores a 12.17.0.

Yarn

Utilizamos o recurso de Espaços de Trabalho (Workspaces) do Yarn. Por isso, é essencial instalar o yarn globalmente. Recomendamos pelo menos a versão 1.19.1. Idealmente, prefira versões superiores a 1.22.4.

Qual é a estrutura básica do projeto?

Como utilizamos lerna para gerenciar o versionamento dos pacotes do monorepo. Estes são os pacotes atuais do projeto:

  • packages/styles: Biblioteca com tema e estilos do Design System para a web;
  • packages/web: Biblioteca de componentes para a web.

Conheça o ABC do fluxo de contribuição

Antes de começar

Estas recomendações são válidas apenas para pessoas contribuidoras da organização Natura.

Se este não é o seu caso, realize um fork do repositório para propor melhorias.

Branches

Contribuições com o Design System devem ser criadas a partir de uma branch no formato DSY-0000. O nome da branch será o código de uma tarefa do JIRA que representa essa contribuição.

Isso é válido para novas features, hotfixes e melhorias na documentação.

Para obter um código de tarefa do JIRA, basta procurar a squad de Design System no Slack ou Teams.

Continuous Integration

Utilizamos o Jenkins como pipeline de integração contínua. É responsabilidade do Jenkins realizar o teste e bumping de versões dos pacotes.

Atualmente, novos releases só são publicados quando realizamos um merge para o branch principal.

O que aconteceu com os branches de feature e milestone?

Antes de 20 de junho de 2020, utilizávamos os padrões ^feature/(.+)$ para feature branches e ^v\d+.\d+.\d+$ para milestone branches, bem como hotfix/ e docs/.

Abandonamos este formato antigo em favor de utilizarmos CI/CD, garantindo um fluxo mais enxuto. Por isso, desde essa data, a pipeline ignora branches nesse formato.

Além disso, o novo formato viabiliza a possibilidade de, em breve, permitirmos que pushes para branches no formato DSY-000 gerem pre-releases, o que facilitaria o teste e validação das contribuições.

Design Validation

Quando um pull request é aberto, a pipeline do Jenkins se encarrega de gerar uma nova versão do storybook. Quando isso acontecer, inclua a url gerada à card no board do Jira, no campo Link para validação funcional

A url gerada será algo como https://storybook-web.natura.com.br/[SUA-BRANCH]/index.html

4. Comece a contribuir

Clone o repositório no seu ambiente de desenvolvimento:

$ git clone https://github.com/natura-cosmeticos/natds-js

Navegue até o diretório do repositório recém-clonado e faça o checkout para a sua branch:

$ cd natds-js
$ git checkout DSY-000 # sendo DSY-000 o nome do seu branch

Por fim, faça a instalação das dependências e um build inicial, para garantir que está tudo pronto:

$ yarn
$ yarn build:libs

Tarefas de linting e testes

Use o eslint para verificar se o seu código está de acordo com o code style:

yarn lint

Como muitos dos nossos componentes são wrappers de outros já testados, usamos muitos testes de snapshot. Quaisquer linhas adicionais de código escritas dentro dos próprios componentes precisam ter 100% de cobertura de teste.

Use o jest para verificar se os testes passam:

yarn test

Consulte a seção scripts no arquivo package.json para conferir a lista completa de tarefas disponíveis.

Posso alterar alguma definição de tema?

Os nossos componentes e temas utilizam o Material UI como base. Os temas são criados na biblioteca @naturacosmeticos/natds-styles. Esse pacote realiza um parse dos temas do Material UI.

Qualquer alteração no contrato do tema ou componentes existentes deve ser comunicada ao time Design System. Assim, iremos avaliar se a alteração é aplicável, e se não causa breaking changes.

5. Faça commits semânticos

Em vez de utilizar git commit, por favor, use este comando:

$ yarn commit

Este comando aciona o Commitizen, já instalado no projeto, que lhe ajudará na criação de uma mensagem de commit.

Os commits serão ser feitos no formato Conventional Commits. Graças a esse formato, é possível definir se a próxima versão será um patch, minor ou major release.

A partir de 20 de junho de 2020, commits feitos fora deste formato poderão ser recusados.

6. Crie um pull request

Ao criar um pull request, não se esqueça de:

  • Documentar, na descrição do pull request, se houve alguma modificação nas dependências do projeto;
  • Informar, também na descrição do pull request, quais mudanças foram realizadas;
  • Atualizar o README.md, caso haja mudanças que afetem a instalação ou utilização da biblioteca;

Um pull request só será mesclado com a branch principal se:

  • O código foi aprovado por pelo menos duas pessoas contribuidoras;
  • As alterações passam em todos os checks, incluindo:
    • Codecov: a cobertura de 100% deve ser mantida;
    • Commitlint: todas as mensagens de commit seguem o Conventional Commits;
    • Mergeable: as alterações e a descrição do pull request não ferem nenhuma das políticas do Mergeable;
    • Travis CI: nenhum build quebrou e todos os testes passaram;
    • Typo CI: não há nenhum typo que prejudique o entendimento ou leitura do código;
    • Snyk: não há versões obsoletas ou com vulnerabilidades conhecidas;

Quando o seu branch for mesclado com a branch principal, uma nova versão das bibliotecas deste projeto será lançada.

Agradecemos por contribuir com este projeto

Esperamos que todas as pessoas contribuidoras leiam o nosso Código de Conduta, inspirado no Contributor Convenant.

Bom trabalho!