---
# System prepended metadata

title: Processo de desenvolvimento Bricks

---

# Processo de desenvolvimento Bricks

Este documento tem como objetivo facilitar o entendimento do processo de desenvolvimento junto ao **Bricks**, explicando o objetivo de cada fase.


## Índice

* [Bricks](#bricks)
* [Propósito](#propósito)
* [Fluxo](#fluxo)
* [Fases](#fases)
    * [Análise](#análise)
    * [Validação da análise](#validação-da-análise)
    * [Implementação](#implementação)
    * [Testes](#testes)
    * [Revisão de código](#revisão-de-código)
* [Fechamento de versão](#fechamento-de-versão)
* [Bugs encontrados](#bugs-encontrados)
* [Equipe responsável](#equipe-responsável)

## Bricks

O [Bricks](https://bricks.wssim.com.br/) é uma biblioteca que entrega um conjunto de componentes responsivos criados em **ReactJS**, tendo utilização junto à solução **Web**, a biblioteca foi criada pelo time de front-end da **WealthSystems** para dar suporte ao desenvolvimento dos aplicativos web de uma forma rápida e fácil.

## Propósito

Todas implementações antes de serem realizadas devem ser analisadas, criticadas e por fim executadas da melhor forma possível. Pontos como impacto gerado, escopo de atribuição, execução e padronização são dentre muitos, os fatores que mais afetam a manutenibilidade da biblioteca.

Com isso surgiu a preocupação de criar e manter um processo, tendo como objetivo o foco na evolução de uma forma segura, detalhada e dentro dos padrões.

## Fluxo

![](https://i.imgur.com/ePkqfJH.jpg)


## Fases

### Análise

É necessário uma tarefa de análise da implementação desejada, contendo informações detalhadas e objetivas, os pontos necessários para facilitar a **validação da análise**.

A tarefa deve conter:
 - Caso de uso que gerou a demanda ( cliente interno ou externo );
 - Análise de escopo;
    - Definição do escopo de implementação junto às soluções já existentes, levando em consideração a utilização de bibliotecas de terceiros, exclusão de soluções que contenham regras de negócio e padrões de layout;
 - Plano de desenvolvimento;
    - Ter um plano de execução da implementação, propondo a forma com que a ideia será implementada, trazendo pontos técnicos para dar fundamentação à proposta;
 - Análise e validação conjunta a UX;
    - O apoio de UX para componentes do **bricks** é primordial, visto que temos **guidelines** e a quebra disso impacta globalmente;
    - Alterações tanto relacionadas a layout ou funcionalidade já existentes devem possuir uma análise de impacto, levando em consideração a utilização do componente em soluções já implementadas;

### Validação da análise

Após a análise ser entregue pelos interessados, será feita uma validação junto à equipe responsável pelo **Bricks**. Essa validação poderá ser efetuada por um **responsável** ou pela **equipe responsável**. 

Pontos mais críticos a serem validados:
 - Validação da solução proposta para o escopo do **bricks**;
 - Auxílio na filtragem do que esta sendo proposto para implementação, ideias para bibliotecas de terceiros e formas de desenvolvimento alternativas que possam ser mais adequadas ao contexto;
 - Validações de layout, tendo como objetivo não apenas propor mudanças, mas também evitar problemas que possam ser desconhecidos pela equipe de análise;
 - Auxílio na quebra de código e estruturação;

### Implementação

Tendo a validação concluída, todo material que possa ter sido gerado é atualizado junto à análise, a implementação será realizada pela equipe interessada, tendo a total liberdade de procurar os responsáveis para sanar qualquer dúvida ou alteração que possa surgir no processo;
 - Implementação do componente;
 - Implementação do show case + documentação;
 - Implementação de testes;

### Testes

Todas as implementações realizadas dentro do **Bricks** devem ter a maior cobertura de testes possível, os testes devem ser validados no mínimo em cenários como:
 
- Testes relacionados ao componente no escopo **bricks**, sendo validado propriedades, funções, layout, callbacks, etc. Garantindo o funcionamento do componente e o que ele se propõem a entregar;
 
- Testes que visam ter uma validação de componentes já utilizados e de comportamento esperado, validando assim, se houve quebras, bugs ou qualquer efeito colateral junto a utilização do mesmo;

- Testes envolvendo a figura de um QA ao processo, o mesmo garantirá os cenários acima citados, testando o componente no show case, validando a documentação e caso for uma alteração ou adição de funcionalidade, testando no midgard todos os cenários onde o componente já é utilizado, garantindo a compatibilidade e funcionamento;

### Revisão de código

A revisão do código pode ser feita por qualquer desenvolvedor, porém é obrigatório o aceite de pelo menos um membro da **equipe responsável** pelo **Bricks**. Sem este aceite, não será possível a continuação do processo;

## Fechamento de versão

O fechamento de versão poderá acontecer tanto pela equipe responsável pelo **Bricks**, quanto pela que está responsável pela implementação. Seguindo o fluxo do processo definido, principalmente dos merges que geram code review.

## Bugs encontrados

Caso sejam encontrados bugs ou problemas em um componente, na qual a versão do **Bricks** já foi fechada, seguindo o fluxo definido ambos os times poderão realizar a correção e fazer o fechamento de uma nova versão.

## Equipe responsável

 - Eduardo Rodrigues Reichert - eduardo.reichert@totvs.com.br
 - Guilherme Anderzen Polido - guilherme.anderzen@totvs.com.br
 - Luiz Felipe Weber - luiz.weber@totvs.com.br
 - Sanderson Cristian Silva - sanderson.cristian@totvs.com.br