Procesos de desarrollo v0.1
===

## Proceso de Bug en Master (empresas)
1. Se identifica un bug de funcionalidad
2. Se le entrega a Aníbal un video que reproduce el bug.
3. **Aníbal decide si el bug se prioriza o se deja en trelo**
4. Se hace el pedido a un desarrollador
5. El desarrollador saca una branch de Master con el prefijo fix-Nombre e implementa el arreglo. Entrega: 1) video con su código ejecutandose en nombre.dev.equip.cloud donde demuestra que el bug ya no está 2) Hace un pedido a Nico para que acepte el PR.
7. **Nico decide si acepta el PR o pide cambios** Basándose en los estándares de desarrollo, y en la corroboración de que se arregló el bug. Nico actualiza todas las empresas con la nueva versión y escribe un mail de actualización. Y le hace un pedido al desarrollador para que resuelva el bug en develop o en release (si existe release, release, si no, develop).
8. El desarrollador hace un PR de Master a Develop o a Release con los cambios necesarios para arreglar el bug (puede que el bug no exista en esa branch por lo que bastaría con grabar un video demostrando que el bug no está)
9. **Nico decide si lo acepta o pide cambios** Basándose en los estándares de desarrollo, y en la corrobora de que se arregló el bug.
11. Solo si en ese momento existe una branch release Nico actualiza Beta con la nueva actualización.

## Proceso de Feature
1. Hacen un pedido de feature.
2. Se saca una nueva branch desde develop con prefijo feature-Nombre y se implementa, cuando el código y el changelog están listos, se genera una imagen de docker de la app y la api y se sube a nombre.dev.equip.cloud y se graba el video de evidencia. Se entrega el video de evidencia y el PR a develop.
3. **Se corrobora funcionalidad**
4. **Se corrobora estándares de desarrollo**
5. Se hace merge a develop

## Proceso de release
1. Cuando hay al menos un feature disponible en develop que no está en master y no hay una branch release.
2. Nico crea una nueva branch llamada `release-[la versión de Master + los features a revisar]`
3. Se sube esa branch a beta
4. Se piden correcciones y reparación de bugs
5. Por cada pedido se crea una nueva branch basada de release y se hace un PR
6. El encargado de release acepta los PR y actualiza la imagen de beta

---

## Seridores-branches
- Los servidores de empresas y ejemplo siempre ejecutan una imagen de Master.
- El servidor beta ejecuta una imagen de master o una de release.
- Cada desarrollador tiene su servidor staging (ej: jhon.staging.equip.cloud) donde carga su branch feature cuando ya está listo para entregar y graba el video desde ahi.

## Automatización de imagenes
- Cuando se tagea master, se sacan imagenes docker
- Cuando se tagea release, se sacan imagenes docker