Release y Deploy

Release

Para sacar una nueva versión del producto hay que seguir los siguientes pasos (para hotfixes ver las aclaraciones abajo).

1. Si corresponde porque hay novedades grandes, escribir los cambios de interfaz para la gente de a pie en las novedades de wordpress como dice acá (en texto lindito y con gifs!). Usar la fecha tentativa del deploy.
2. Versionar package.json y taggear desde develop. Para eso usamos npm run release (o el que corresponde) que resuelve ambas cosas.

Nota: El comando conviene realizarse con el origin clonado por ssh. ¿Por qué? Porque hace 2 push sucesivos, entonces pide user/pass 2 veces, y el segundo prompt del nombre está escondido, no se nota que te está pidiendo user y pass.

Si sucedió error, antes de pasar al siguiente punto asegurarse de que estén pusheados todos los commits.

3. El script de release te da un link que crea un release en Github con la descripción detallada de los commits. Darle "Publish" a ese release para que queden esos cambios registrados.
4. Cuando Github Actions se encuentra con un tag nuevo, y los tests corren, arma los ejecutables/instaladores y los sube a un release de Github que está asociado a ese tag creado en el punto anterior. Ver que se hayan subido los ejecutables al release luego de que corran las actions.
5. Si corresponde porque hay novedades grandes, Mandar un mail avisando al equipo de Program.ar para que nos ayuden a testear la app y que no hay problemas. La idea es que se descarguen desde releases y prueben la nueva versión en distintos Sistemas Operativos (Huayra, Mac, Windows) y que anden los nuevos features. Si no corresponde, al menos bajarse los instaladores de windows y debian y probarlos.
6. Luego de todo esto, no olvidar hacer un merge de develop -> main para tener en master lo mismo que estará deployado.

Deploy

1. Deploy según el instructivo de containerization.
2. No olvidar actualizar los links en el php del wordpress.

Sobre hotfixes

Hacemos hotfixes cuando queremos hacer un cambio especifico rápido, como un fix de un bug importante. Por esto, nos salteamos partes de la burocracia del proceso de release y deploy al hacer un hotfix. En general:

• El cambio del hotfix se hace directamente sobre main, no sobre develop.
• No importan las notas de version para la gente
• No se le envia un mail avisando al equipo de Program.ar para que prueben.
• Sigue siendo importante probar los instaladores en local!