Acuerdo de Trabajo

Toda documentación de trabajo para el proyecto debe ser escrito en español. Todo código debe ser escrito en inglés.

Issues

Forma de Trabajo

• Revisión paulatina (3 dias) de issues.

Ramas

Convención del nombre

Debe coincidir con las siguientes convenciones:

• Debe iniciar con el proposito del cambio,

  • feature: nueva funcionalidad
  • fix: resuelve un problema
  • setup: instalación y/o configuración

• Debe finalizar con el número del issue,

  • Ejemplos, feature/issue-90 or fix/issue-91

Creación y proceso de fusión

• Primero que todo, todos las ramas deben tomar development como punto inicial.
• Para unir la rama a development, un pull request debe ser abierto con lo siguiente:
  1. Título, pudiera tener el número del issue.
  2. Descripción, debe ser una descripción detallada de los cambios, no solo los commit messages.
  3. 2 Revisores, para revisar el código.
  4. Opcional, puedes abrir un pull request como draft para ti mismo, para hacer un revisión de código personal antes de publicarlo.
• Para unir de development a stage,
  1. 3 Revisores deben aprobar el cambio.
• Para unir de stage a main,
  1. Cualquier mantenedor puede aplicar dicho cambio en este punto.

Tecnologías

Principales

• React
• Gatsby

Manejador de estado

• Apollo

Estilos

• Styled components
• Styled system

Analizadores de código estático

• Prettier
• Airbnb - ESLint
• Stylelint

Git Hooks

• Husky

Reglas

• pre-commit: prettier & eslint
• pre-push: jest
• post-push: gatsby build

Pruebas

• Storybook
• Jest
• React testing library

Integración continua y despliegue continuo

• Github Actions
• Amplify

Varios

• EditorConfig