Manual interno de procedimientos
El objetivo de este manual es documentar diversas confusiones y errores que hemos tenido en el transcurso del desarrollo para intentar que no vuelvan a suceder.
Todos los archivos HTML se encuentran al día de hoy dentro del directorio sitio ya que ese directorio será el que se suba al servidor para poder tener el sitio online. Cualquier archivo que no esté dentro de ese directorio (o algunos de sus directorios internos) no será publicado y por consiguiente no podrá ser accedido por el usuario final.
Los nombres de los archivos html serán en minúsculas y sin espacios, en lo posible de una palabra de longitud o tal vez dos palabras si hubiese una confusión respecto al uso. Algunos servidores web diferencias mayúsculas de minúsculas, por consiguiente www.example.com/pagina podría ser accedido pero www.example.com/Pagina no, por consiguiente es importante que siempre se utilicen las minúsculas. Por otro lado los espacios pueden crear problemas con los servidores por lo que para ahorrar problemas no se utilizarán. Tampoco se pueden utilizar símbolos que tienen significado especial en archivos en disco o sitios web, por ejemplo :, /, #, ?, etc.
A partir de una historia de usuario (de una necesidad del usuario final) se crean tareas las cuales, una vez completadas, harán que la historia de usuario esté finalizada. La historia de usuario es una guía sobre lo que hay que hacer y el que se asigna una historia de usuario toma responsabilidad por que se finalice la historia, sin embargo los que se asignan las tareas individuales son los responsables de terminar esas tareas.
En backlog están las tareas que quedaron para el próximo Sprint, no se deben hacer ahora. En To Do están las tareas que el equipo se comprometió a finalizar durante el Sprint actual. In Progress tiene las tareas que ya están siendo trabajadas por alguno de los miembros del equipo, y en Done quedan las tareas finalizadas.
- Asignarse la tarea (no la historia de usuario) que esté en estado To Do. Con eso se toma responsabilidad de terminar esa tarea.
- Cuando se empieza a trabajar en la tarea, cambiarla a estado In Progress para indicarle al equipo que en este momento está trabajando en eso.
- Crear una rama utilizando la opción de Github para esa tarea. Una rama no es un directorio, seguir las instrucciones de Github.
- En la máquina local no es necesario crear directorios, simplemente se trabaja viendo cómo debería quedar los archivos al final. El trabajo es del equipo completo, no individual por consiguiente no es necesario separar lo que hace cada uno en directorios individuales o por tareas.
- Al finalizar realizar un push de la rama.
- Luego del push al entrar a Github les dirá que hubo cambios y que pueden crear un pull request.
- Hacerlo, pueden asignar como reviewer a Roberto o a alguien más para que verifique que el código está correcto y realice la mezcla o mergeo con la rama dev.
- Recién después de que el código haya sido aceptado y mergeado borrar la rama local en su máquina.
- Jamás subir código directamente a main, jamás usar file upload ya que se pierde el historial local de cambios, y en lo posible utilizar pull requests en lugar de pushear directamente a dev para poder tener code review (revisión de código) sobre los cambios a través del pull request.