Diferencia entre revisiones de «Gestión de generación estática del sitio web - 17 18 - G1»

De Wiki de EGC
Saltar a: navegación, buscar
 
(No se muestran 30 ediciones intermedias del mismo usuario)
Línea 8: Línea 8:
 
<li>Sergio Torrijos Campano </li>
 
<li>Sergio Torrijos Campano </li>
  
−
<br>
 
 
</ul>
 
</ul>
  
Línea 15: Línea 14:
 
La función principal de nuestro subsistema es crear un botón que permita la generación estática del portal. Evitando con ello brechas de seguridad debidas a la parte dinámica de la página.
 
La función principal de nuestro subsistema es crear un botón que permita la generación estática del portal. Evitando con ello brechas de seguridad debidas a la parte dinámica de la página.
 
Consiste en eliminar dicho dinamismo de la página cuando lo desee el administrador (normalmente se utiliza al finalizar el evento).
 
Consiste en eliminar dicho dinamismo de la página cuando lo desee el administrador (normalmente se utiliza al finalizar el evento).
 +
 +
== Documento explicativo acerca de la gestión del equipo ==
 +
 +
<h4>Herramientas de comunicación</h4>
 +
 +
• Las comunicaciones entre los integrantes del propio equipo se realizarán a través de ‘WhatsApp’, principalmente para avisos y dudas concretas.
 +
 +
• Para la resolución de dudas importantes y reuniones, en caso de no poderse realizar de forma presencial, se harán a través de los programas ‘Skype’ o ‘Discord’.
 +
 +
• A la hora de compartir documentos se utilizará la rama ‘documentation’ creada en ‘GitHub’ para que todo el equipo tenga acceso.
 +
 +
• El documento subido debe constar de un título que informe de forma concisa de su contenido. Y debe tener un comentario que profundice más en dicho contenido para el correcto entendimiento del mismo.
 +
 +
<h4>Planificación de las reuniones</h4>
 +
 +
• Dos días antes del milestone se realizará una reunión (no presencial, via Skype/Discord) para revisar el contenido a mostrar en el transcurso del mismo así como plantear los problemas surgidos.
 +
 +
• Las reuniones presenciales se realizarán 30 minutos después de la finalización de cada milestone. Es decir, si el milestone finaliza el jueves a las 12:40, la reunión comenzará a las 13:10.
 +
 +
• Las reuniones extraordinarias entre los miembros del equipo para resolver dudas concretas se comunicarán via ‘WhatsApp’ al resto de miembros y se ha de contar con al menos el 60% del equipo, es decir, 3 de 5 miembros (En caso de ser urgente, se puede hacer una excepción y que se realice con 2 de los 5 integrantes)
 +
 +
== Documento explicativo acerca de las branches a utilizar ==
 +
 +
El acuerdo al que se ha llegado por parte de todos los miembros del grupo es de crear una ‘branch’ personal para cada uno de los integrantes. Esto es, por ejemplo, para Sixto Díaz Llacer existirá la ‘branch’ llamada “sixdialla”, es decir, el nombre de la misma será el UVUS del miembro del grupo en cuestión.
 +
 +
Disponemos de la rama general "master" donde se subirán los resultados finales.
 +
 +
<h4>Para una mayor organización nuestro repositorio constará de dos ‘branches’ complementarias:</h4>
 +
• La primera de todas será la dedicada a almacenar la documentación del grupo, llamada “documentation”.
 +
 +
• La segunda tendrá el nombre “release”, contendrá el código en el periodo previo a su lanzamiento y será utilizada para realizar pruebas sobre la funcionalidad del sistema.
 +
 +
<center>
 +
[[Archivo:Diagrama_De_Branches.png|1000px]]
 +
</center>
 +
 +
== Procedimiento de gestión de tareas, cambios e incidencias ==
 +
Para la gestión de las incidencias, se usarán los "Issue" que GitHub permite gestionar en cada repositorio, haciéndose de la siguiente manera:
 +
 +
Cada Issue representará una tarea o problema encontrado por algún miembro del grupo.
 +
 +
♦ Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre tres fases:
 +
 +
• TO DO: cuando el Issue está sin empezar
 +
 +
• In progress: cuando se esté trabajando sobre el Issue
 +
 +
• Done: cuando el Issue está terminado y cerrado.
 +
 +
Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.
 +
 +
Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Done se su proyecto correspondiente. Esto debe hacerse automáticamente si el Issue se cierra con un commit.
 +
 +
♦ Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo.
 +
 +
<h5>Tipos</h5>
 +
 +
• Change/Upgrade
 +
 +
• Bug
 +
 +
• New, por si no tienen nada que ver con el desarrollo, que sólo se incluirán en dichos casos.
 +
 +
<h5>Temática</h5>
 +
 +
• Documentation
 +
 +
• Development
 +
 +
• Test
 +
 +
• Investigation
 +
 +
• Si fuesen necesaria alguna otra etiqueta se procedería a su creación.
 +
 +
<h5>Prioridades</h5>
 +
 +
• Critical
 +
 +
• High
 +
 +
• Medium
 +
 +
• Low
 +
 +
<h5>Estados</h5>
 +
 +
• New
 +
 +
• Accepted (sólo para cambios)
 +
 +
• Started
 +
 +
• Fixed
 +
 +
• Verified
 +
 +
• Duplicate (cambios y bugs)
 +
 +
• Wontfix (cambios y bugs)
 +
 +
Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.
 +
 +
== Gestión del código fuente ==
 +
 +
Para llevar a cabo la gestión del código fuente usaremos las herramientas Git y GitHub.
 +
 +
<h5>Estructura</h5>
 +
 +
<tipo>:<título>
 +
 +
<cuerpo>
 +
 +
<pie>
 +
 +
<h5>Tipo</h5>
 +
 +
• feat: Una nueva característica
 +
 +
• fix: Se solucionó un bug
 +
 +
• docs: Se realizaron cambios en los documentos
 +
 +
• stylo: Cambios de estilo y visuales en la página
 +
 +
• refactor: Se realizaron cambios en el código
 +
 +
• test: Se realizaron pruebas en el commit.
 +
 +
<h5>Título</h5>
 +
 +
No debe contener más de 50 caracteres, debe iniciar con letra mayúscula y no acabar con signos de puntuación. Debe ser lo más objetivo posible y, preferiblemente, en inglés.
 +
 +
<h5>Cuerpo</h5>
 +
 +
Si el commit no es muy complejo no es necesario realizar el cuerpo. Debe detallarse principalmente el que y el porqué de la realización de dicho commit y no centrarse en el cómo se ha realizado.
 +
 +
<h5>Pie</h5>
 +
 +
Este campo es opcional y se debe utilizar para referenciar a otras incidencias.
 +
 +
<h5>Ejemplo de uso:</h5>
 +
 +
Fix: Change of JavaScript buttons
 +
 +
Se ha realizado un cambio en los botones de JavaScript ya que redirigían a las vistas equivocadas.
 +
 +
Fix #123
 +
 +
== Documento explicativo acerca de la integración continua: automatización de pruebas ==
 +
 +
<h5>Automatización de pruebas</h5>
 +
 +
Para la gestión de la integración continua usaremos el host Travis CI. Para su correcto funcionamiento se han de añadir los siguientes archivos:
 +
 +
• .travis.yml: Contiene la configuración de Travis CI.
 +
 +
• phpunit.xml: En este archivo se indica la ubicación de las pruebas de Travis.
 +
 +
• composer.json: Se encarga de mantener las versiones de php y phpunit actualizadas y además se muestra la ruta de las clases que van a participar  en los tests.
 +
 +
• Carpeta “tests”: Carpeta donde se ubican los tests a realizar.
 +
  
 
== Repositorio de GitHub ==
 
== Repositorio de GitHub ==

Revisión actual del 15:52 14 ene 2018

Miembros

  • Antonio Carrasco Márquez
  • Sixto Díaz Llacer (Coordinador)
  • Francisco Javier Higueras Galván
  • Óscar Tirado Hernández
  • Sergio Torrijos Campano

Función

La función principal de nuestro subsistema es crear un botón que permita la generación estática del portal. Evitando con ello brechas de seguridad debidas a la parte dinámica de la página. Consiste en eliminar dicho dinamismo de la página cuando lo desee el administrador (normalmente se utiliza al finalizar el evento).

Documento explicativo acerca de la gestión del equipo

Herramientas de comunicación

• Las comunicaciones entre los integrantes del propio equipo se realizarán a través de ‘WhatsApp’, principalmente para avisos y dudas concretas.

• Para la resolución de dudas importantes y reuniones, en caso de no poderse realizar de forma presencial, se harán a través de los programas ‘Skype’ o ‘Discord’.

• A la hora de compartir documentos se utilizará la rama ‘documentation’ creada en ‘GitHub’ para que todo el equipo tenga acceso.

• El documento subido debe constar de un título que informe de forma concisa de su contenido. Y debe tener un comentario que profundice más en dicho contenido para el correcto entendimiento del mismo.

Planificación de las reuniones

• Dos días antes del milestone se realizará una reunión (no presencial, via Skype/Discord) para revisar el contenido a mostrar en el transcurso del mismo así como plantear los problemas surgidos.

• Las reuniones presenciales se realizarán 30 minutos después de la finalización de cada milestone. Es decir, si el milestone finaliza el jueves a las 12:40, la reunión comenzará a las 13:10.

• Las reuniones extraordinarias entre los miembros del equipo para resolver dudas concretas se comunicarán via ‘WhatsApp’ al resto de miembros y se ha de contar con al menos el 60% del equipo, es decir, 3 de 5 miembros (En caso de ser urgente, se puede hacer una excepción y que se realice con 2 de los 5 integrantes)

Documento explicativo acerca de las branches a utilizar

El acuerdo al que se ha llegado por parte de todos los miembros del grupo es de crear una ‘branch’ personal para cada uno de los integrantes. Esto es, por ejemplo, para Sixto Díaz Llacer existirá la ‘branch’ llamada “sixdialla”, es decir, el nombre de la misma será el UVUS del miembro del grupo en cuestión.

Disponemos de la rama general "master" donde se subirán los resultados finales.

Para una mayor organización nuestro repositorio constará de dos ‘branches’ complementarias:

• La primera de todas será la dedicada a almacenar la documentación del grupo, llamada “documentation”.

• La segunda tendrá el nombre “release”, contendrá el código en el periodo previo a su lanzamiento y será utilizada para realizar pruebas sobre la funcionalidad del sistema.

Diagrama De Branches.png

Procedimiento de gestión de tareas, cambios e incidencias

Para la gestión de las incidencias, se usarán los "Issue" que GitHub permite gestionar en cada repositorio, haciéndose de la siguiente manera:

Cada Issue representará una tarea o problema encontrado por algún miembro del grupo.

♦ Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre tres fases:

• TO DO: cuando el Issue está sin empezar

• In progress: cuando se esté trabajando sobre el Issue

• Done: cuando el Issue está terminado y cerrado.

Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.

Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Done se su proyecto correspondiente. Esto debe hacerse automáticamente si el Issue se cierra con un commit.

♦ Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo.

Tipos

• Change/Upgrade

• Bug

• New, por si no tienen nada que ver con el desarrollo, que sólo se incluirán en dichos casos.

Temática

• Documentation

• Development

• Test

• Investigation

• Si fuesen necesaria alguna otra etiqueta se procedería a su creación.

Prioridades

• Critical

• High

• Medium

• Low

Estados

• New

• Accepted (sólo para cambios)

• Started

• Fixed

• Verified

• Duplicate (cambios y bugs)

• Wontfix (cambios y bugs)

Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.

Gestión del código fuente

Para llevar a cabo la gestión del código fuente usaremos las herramientas Git y GitHub.

Estructura

<tipo>:<título>

<cuerpo>

<pie>

Tipo

• feat: Una nueva característica

• fix: Se solucionó un bug

• docs: Se realizaron cambios en los documentos

• stylo: Cambios de estilo y visuales en la página

• refactor: Se realizaron cambios en el código

• test: Se realizaron pruebas en el commit.

Título

No debe contener más de 50 caracteres, debe iniciar con letra mayúscula y no acabar con signos de puntuación. Debe ser lo más objetivo posible y, preferiblemente, en inglés.

Cuerpo

Si el commit no es muy complejo no es necesario realizar el cuerpo. Debe detallarse principalmente el que y el porqué de la realización de dicho commit y no centrarse en el cómo se ha realizado.

Pie

Este campo es opcional y se debe utilizar para referenciar a otras incidencias.

Ejemplo de uso:

Fix: Change of JavaScript buttons

Se ha realizado un cambio en los botones de JavaScript ya que redirigían a las vistas equivocadas.

Fix #123

Documento explicativo acerca de la integración continua: automatización de pruebas

Automatización de pruebas

Para la gestión de la integración continua usaremos el host Travis CI. Para su correcto funcionamiento se han de añadir los siguientes archivos:

• .travis.yml: Contiene la configuración de Travis CI.

• phpunit.xml: En este archivo se indica la ubicación de las pruebas de Travis.

• composer.json: Se encarga de mantener las versiones de php y phpunit actualizadas y además se muestra la ruta de las clases que van a participar en los tests.

• Carpeta “tests”: Carpeta donde se ubican los tests a realizar.


Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace.

Grupo de Opera

La página del proyecto en Opera será accesible en este enlace.

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Gestión_de_generación_estática_del_sitio_web_-_17_18_-_G1&oldid=7423»