-
PROCEDIMIENTOS DE TRABAJO
2.1 Primeras tareas a realizar en el proyecto
2.2 Configuraciones de Git
2.3 Procedimiento diario
2.4 Procedimiento de trabajo con tarjetas
2.4.1 Asignarte una tarjeta de tareas
2.4.2 Trabajar en una tarea
2.4.3 Pull request
2.5 Trabajo con git
2.6 Metodología Scrum
- Pide permiso para colaborar en el proyecto
- Añade tu nombre al archivo contributors.md. Para ello:
-
Clona el repositorio de Github ita-challenges-frontend en tu sistema local:
git clone https://github.com/IT-Academy-BCN/ita-challenges-frontend.git
-
Muévete al directorio del repositorio clonado:
cd ita-challenges-frontend
-
Puedes verificar las ramas disponibles y tu rama actual ejecutando el siguiente comando:
git branch
-
Si no te encuentras en la rama "develop", muévete a ella ejecutando el siguiente comando:
git switch develop
-
Crea una nueva rama con tu nombre para realizar tus cambios:
git switch -c nombre-de-tu-rama
Sustituye "nombre-de-tu-rama" por un nombre descriptivo que indique los cambios que deseas realizar.
-
Abre el archivo contributors.md y añade tu nombre y nombre de usuario de GitHub.
-
Después de hacer un 'git add' y 'git commit', ejecuta el siguiente 'git push':
git push origin nombre-de-tu-rama
-
Abre el repositorio en GitHub. Deberías ver un mensaje que te permite crear un pull request desde tu nueva rama a la rama "develop". Haz clic en el enlace para crear la pull request.
Configuraciones de Git necesarias para prevenir problemas
-
Edita el archivo .gitignore: Ahora puedes editar el archivo ".gitignore" para incluir cualquier patrón de archivos o directorio específicos que quieras que Git ignore en todos tus proyectos. Recuerda guardar el archivo después de hacer cualquier cambio.
-
Propaga los cambios: Los cambios en tu archivo .gitignore no afectarán de manera retroactiva los archivos que Git ya haya seguido. Si quieres que Git comience a ignorar un archivo que ya seguía, primero tienes que dejar de seguir ese archivo. Usa el comando 'git rm --cached nombre_archivo' para dejar de seguir un archivo. Para que los cambios tengan efecto, tendrás que hacer un commit de este cambio.
-
Evita datos sensibles: Una buena práctica es incluir archivos que contengan datos sensibles (como archivos de configuración con contraseñas o claves API) en tu archivo .gitignore. Esto evitará que estos archivos se puedan hacer un commit accidentalmente a tu repositorio.
-
.gitignore global vs local: Recuerda, el archivo ".gitignore" global se aplicará a todos tus proyectos de Git. Si tienes archivos que hay que ignorar que son específicos de un solo proyecto, considera usar un archivo ".gitignore" local dentro del directorio de ese proyecto.
Antes de comenzar a trabajar en el proyecto, por favor revisa https://docs.github.com/es/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
-
Abre Git Bash.
-
Ejecuta el siguiente comando para configurar Git para que reciba una advertencia cuando intentas hacer un commit de un archivo con saltos de línea CRLF o cuando intentas convertir estos archivos con saltos de línea CRLF a LF:
git config --global core.safecrlf warn
-
Con esta configuración, si intentas hacer un commit de un archivo con saltos de línea CRLF, recibirás una advertencia. La misma advertencia se producirá si intentas convertir un archivo con saltos de línea CRLF a LF.
Para evitar que git monitorice los cambios de permisos de los archivos, ejecuta el siguiente comando:
git config --global core.fileMode false
Esto evitará que git marque los archivos como modificados cuando cambien sus permisos, en todos los repositorios de tu sistema. Si prefieres que no se aplique a todos, ejecuta solamente:
git config core.fileMode false
El procedimiento a seguir cada día sería este:
-
Comienza el día actualizando tu rama develop:
git switch develop git pull
-
Elige una tarjeta de tareas del tablero del proyecto que aún no esté asignada.
-
Crea una nueva rama para esta tarea.
git switch -c nombre-de-la-rama-tarea
-
Trabaja en tu tarea.
-
Cuando hayas finalizado la tarea, sube los cambios al repositorio.
git add . git commit -m "descripción de los cambios" git push origin nombre-de-la-rama-tarea
-
Crea una pull request en GitHub desde tu rama de tareas a la rama "develop".
-
Pide una revisión de tu código a alguno de tus compañeros de equipo.
-
Si se aprueba tu pull request, se puede fusionar a la rama "develop".
-
Si tienes alguna tarea más a realizar, vuelve al paso 2.
Las tarjetas de tareas están organizadas según su estado de desarrollo. Están clasificadas por niveles (1, 2, 3), siendo 1 el nivel más bajo de complejidad.
Las tarjetas se mueven de izquierda a derecha a medida que se van completando.
- Ve a la vista del proyecto en Github.
- En la columna "Backlog", selecciona una tarjeta que no esté asignada.
- Haz clic sobre la tarjeta y asígnatela.
- Mueve la tarjeta a la columna "Doing".
-
Crea una nueva rama para la tarea utilizando el formato "feature#numeroDeLaTarjeta". Se refiere al número de la tarjeta del Sprint Backlog. Por ejemplo:
git checkout -b feature#123
-
Trabaja en tu tarea. Realiza commits con frecuencia.
-
Cuando hayas finalizado la tarea, sube los cambios al repositorio.
git add . git commit -m "descripción de los cambios" git push origin nombre-de-la-rama-tarea
- Crea una pull request en GitHub desde tu rama de tareas a la rama "develop".
- Asigna a un revisor de código.
- Mueve la tarjeta a la columna "Review in progress".
- Si el revisor de código aprueba tu pull request, se puede fusionar a la rama "develop".
- Mueve la tarjeta a la columna "Done".
NOTA IMPORTANTE: Una Pull Request es una solicitud para incluir tu código en el proyecto. No esperes a que tu PR sea aceptada para empezar a trabajar en otra card
El workflow de git que seguimos en proyecto es similar a Gitflow. Para poder trabajar en el proyecto, debería conocer al menos los siguientes comandos git:
- git clone
- git merge
- git push
- git pull
- git branch
- git checkout
Puede encontrar un buen tutorial en https://www.atlassian.com/git, y hay muchos otros recursos en https://docs.github.com/en/get-started/using-github/github-flow
- Reuniones diarias para plantear dificultades y bloqueantes que tengas
- Reuniones quincenales más profundas (jueves)
- Reuniones ocasionales con el cliente
- Trabajo por Epics > Tareas (sprints)
- Clean code
- Principios SOLID
- Guía de estilo de Angular. Puntos principales:
- Utiliza una estructura de carpetas basada en características en lugar de una estructura basada en tipos. -Agrupa archivos relacionados (componentes, servicios, etc.) en la misma carpeta. -Utiliza convenciones de nomenclatura coherentes y descriptivas para archivos y carpetas, como kebab-case para nombres de carpetas y PascalCase para nombres de clases.
- Nomenclatura de Clases: -Utiliza PascalCase para nombres de clases, incluyendo componentes, directivas, servicios, etc. -Añade el sufijo "Component" a los nombres de componentes. -Añade el sufijo "Service" a los nombres de servicios.
- Nomenclatura de Propiedades y Métodos: -Utiliza camelCase para nombres de propiedades y métodos. -Evita usar los prefijos "get" o "set" para accesores de propiedades.
- Convenciones de Plantillas: -Prefija los nombres de atributos personalizados con "ng". -Prefija los selectores de componentes personalizados con "app".
- Organización del Código: -Mantén el código conciso y legible. -Agrupa las importaciones en bloques separados. -Ordena las importaciones alfabéticamente.
- Gestión de Estilos: -Utiliza la arquitectura de componentes de Angular para aplicar estilos específicos a cada componente. -Utiliza clases SCSS para estilos reutilizables y evita estilos en línea.
- Gestión de Subscripciones: -Desuscríbete de observables en componentes para evitar fugas de memoria y uso innecesario de recursos. -Utiliza takeUntil, operadores unsubscribe o DestroyRef para gestionar subscripciones.
- Gestión de Formularios: -Utiliza el módulo ReactiveFormsModule para la gestión de formularios. -Evita usar directivas ngModel en formularios complejos.
- Manipulación del DOM: -Evita manipular directamente el DOM, utiliza el enlace de datos, directivas integradas de Angular, ViewChild/ren... -Para manipulación de DOM de bajo nivel, utiliza Renderer2
- Idiomas: utiliza únicamente el inglés para el código (puedes usar otros idiomas para los comentarios)
Angular 16.0.1
Intenta no sobrecargar el proyecto con librerías innecesarias.
- Bootstrap: 5.2
- ngBootstrap: 15.0.0
- "jasmine-marbles": "^0.9.2",
- Jest: "jest-jasmine2": "^29.5.0", "jest-preset-angular": "^13.1.1"
- JWT:
- Node.js: Asegúrate de tener Node.js instalado en tu sistema. Puedes descargarlo desde el sitio web oficial de Node.js.
- Git bash: lo necesitarás para contribuir al proyecto.
-
Abre una terminal o una línea de comandos.
-
Navega hasta el directorio raíz del proyecto.
-
Ejecuta el comando
npm install
(o 'npm i') para instalar todas las dependencias del proyecto especificadas en el archivo package.json.
--
Para propósitos de desarrollo, utiliza el comando
ng serve
para iniciar el servidor de desarrollo. Esto compilará el proyecto y lo servirá localmente, permitiéndote ver e interactuar con él en tu navegador.
--
Para ejecutar testing, utiliza el comando
npm test
Esto ejecutará el conjunto de pruebas y proporcionará retroalimentación sobre los resultados. Si prefieres ejecutar las pruebas en modo de vigilancia, que reejecuta automáticamente las pruebas cuando un archivo cambia, utiliza el comando
npm run test:watch.
Si necesitas alguna referencia sobre testing en Angular, puedes consultar https://angular.io/guide/testing.
También està disponible una guía sobre testing en https://martinfowler.com/articles/practical-test-pyramid.html
--
El desarrollo del proyecto es desplegado en un servidor de desarrollo mediante integración continua. No es necesario realizar un deploy manual. Todas las features desarrolladas, cuando son aprobadas, se despliegan en el servidor de desarrollo. Cuando termines de desarrollar la feature correspondiente (asegúrate de que la branch tenga la nomenclatura correcta), sigue los siguientes pasos:
- Según las normas de versionado semántico (https://semver.org/), actualiza el número de versión en el archivo package.json.
- Actualiza también el número de versión de la propiedad MICROSERVICE_VERSION en el archivo .env.CI.dev. Ten en cuenta que debes dejar una línea en blanco al final del archivo.
- Asegúrate de que ambas versiones coinciden.
- Introduce las anotaciones necesarias en el archivo CHANGELOG.md. No olvides poner el número de issue al que pertenece la nueva versión.
- Realiza el push de la branch a la que pertenece la feature.
- Realiza la PR correspondiente.