Documentación
Esta página de la Wiki de GitHub incluye toda la documentación necesaria elaborada por el equipo de trabajo durante la realización de nuestro proyecto, en que hemos añadido varias implementaciones a la herramienta Evidentia usada para las jornadas InnoSoft. En los siguientes apartados se indica toda la información necesaria sobre nuestro proyecto, a continuación, os dejamos un pequeño índice con todos los contenidos para comodidad del lector:
- Descripción del sistema
- Visión global del proceso de desarrollo
- Entorno de desarrollo
- Gestión de incidencias
- Gestión del código fuente
- Gestión de la construcción e integración continua
- Gestión de liberaciones, despliegue y entregas
- Ejercicio de propuesta de cambio
- Lecciones Aprendidas
- Conclusiones de trabajo futuro
Pero antes de entrar en detalle con los anteriores apartados queremos explicar resumidamente lo hecho en nuestro trabajo y cómo se ha hecho. Para ello indicaremos algunos datos fundamentales que se han tenido en cuenta durante el desarrollo del proyecto y que ayudan a gestionarlo de una forma más adecuada. A continuación, exponemos los datos necesarios y algunos detalles sobre ellos:
- Miembro del equipo: Se indica el nombre completo del miembro del equipo de trabajo, para este proyecto el equipo contaba con seis integrantes.
- Horas: Se indican las horas de trabajo realizadas por cada miembro del equipo durante el desarrollo del proyecto, esto incluye todas las horas consumidas para realizar el incremento funcional (en nuestro caso contando las horas usadas para aprender nuevas tecnologías), la suma de las horas de todas las reuniones del equipo de trabajo, las horas para la realización de documentación y las horas utilizadas para otros procesos de gestión del proyecto como la creación de incidencias, la integración continua o el despliegue.
- Commits: Se indica el número de commits realizado por cada miembro del equipo de trabajo durante la realización del proyecto al repositorio del grupo.
- LoC: Se indican las líneas de código producidas por cada miembro del equipo de trabajo para realizar sus implementaciones.
- Test: Se indican las pruebas realizados por cada miembro del equipo de trabajo durante el proyecto.
- Issues: Se indica el número de incidencias gestionadas por cada miembro del equipo de trabajo.
- Incremento: Se indica brevemente el incremento funcional que ha desarrollado cada miembro del equipo de trabajo.
En la siguiente tabla se indican los resultados obtenidos para cada uno de los anteriores apartados por cada miembro del equipo de trabajo y también se muestra una estadística del número total de cada dato sumando todos los datos de los miembros del grupo. Por último, se incluyen enlaces para dejar evidencias de donde proceden los indicadores obtenidos.
| Miembro del Equipo | Horas | Commits | Líneas Código | Tests | Issues | Incremento |
|---|---|---|---|---|---|---|
| Dimitrova Penkova, Yoana | 52 | 16 | 429 | 5 | 7 | El incremento funcional ha sido añadir una agenda de contactos a cada usuario para que pueda gestionar sus comunicaciones de forma cómoda. |
| Fernández Fernández, Adrián | 51 | 11 | 943 | 5 | 6 | Realizar una planificación de reunión, accesible por los participantes |
| González García, José Carlos | 59 | 11 | 291 | 7 | 6 | El incremento ha consistido en añadir estadísticas relacionadas con las evidencias de los alumnos en el dashboard del profesor. |
| Jiménez Ponce, Tomás Alberto | 51 | 15 | 310 | 5 | 6 | El incremento ha sido la adición de dos paneles informativos sobre las reuniones y subcomités para el profesor en su propio dashboard. |
| Rodríguez Osorio, Marcos | 55 | 14 | 403 | 6 | 6 | El incremento funcional ha consistido en añadir la posibilidad de realizar valoraciones sobre un comité |
| Sanabria Alonso de Caso, Ignacio | 51 | 8 | 481 | 5 | 5 | Crear y gestionar una lista de incidencias que le puedan surgir al usuario durante la realización de las jornadas. |
| TOTAL | 319 | 75 | 2857 | 33 | 36 |
Para el desempeño de los miembros del equipo se adjuntan las siguientes evidencias:
- Dimitrova Penkova, Yoana: Informe personal de Toggl
- Fernández Fernández, Adrián: Informe personal de Toggl
- González García, José Carlos: Informe personal de Toggl
- Jiménez Ponce, Tomás Alberto: Informe personal de Toggl
- Rodríguez Osorio, Marcos: Informe personal de Toggl
- Sanabria Alonso de Caso, Ignacio: Informe personal de Toggl
A continuación se añaden evidencias de los commits e issues realizados:
Como observación, comentamos que salvo la incidencia relacionada con la propuesta de cambio indicada, todas las demás, al solucionarse se cerraron con un mensaje de solución.
Nuestro equipo de trabajo no ha llevado a cabo la integración con otros equipos durante la realización del proyecto.
En este apartado explicará el sistema desarrollado desde un punto de vista funcional y arquitectónico. Innosoft-Guadalete cuenta un proyecto desarrollado en PHP. Este proyecto consiste en mejorar la aplicación denominada Evidentia.
Evidentia es un sistema de gestión automática de evidencias de trabajos de alumnos y alumnas. Fue originalmente pensado para las Jornadas InnoSoft Days organizadas en el ámbito de la asignatura Evolución y Gestión de la Configuración.
En primer lugar, cabe decir que Evidentia, se comunica mediante llamadas HTTP y se ha desarrollado mediante un framework llamado Laravel. Laravel es un framework de código abierto para desarrollar aplicaciones y servicios web con PHP 5 y PHP 7. Su filosofía es desarrollar código PHP de forma elegante y simple, evitando el "código espagueti". Para la realización de funcionalidades en Evidentia, es necesaria la creación de modelos, esto conlleva también a realizar migraciones y seeders, enrutado, controladores y vistas.
Por ejemplo veamos la creación de la entidad Note.
En primer lugar se deberá de crear el modelo siguiendo el siguiente comando en la consola, dentro de Laravel.
php artisan make:model Note
Esto creará el modelo Note, acto seguido se deberá de completar el modelo.
class Note extends Model
{
protected $table = "notes";
protected $fillable = ["user_id", "title", "date", "description"];
public function user()
{
return $this->belongsTo('App\User');
}
}
Se debe tener en cuenta si un modelo tiene relación con un User, si es así, se deberá de reflejar en el modelo User.
class User extends Authenticatable
{
//Notas
public function notes(){
return $this->hasMany('App\Note');
}
Una vez hecho esto, se deberá de migrar el modelo a la base de datos mediante el siguiente comando.
php artisan make:migration CreateNotesTable --create=notes --path database/migrations/develop
Esto nos creará una tabla la cual tendrá los atributos que le impongamos.
class CreateNotesTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('notes', function (Blueprint $table) {
$table->id();
$table->foreignId('user_id');
$table->string('title');
$table->date('date');
$table->string('description');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('notes');
}
}
El siguiente paso es crear el seeder. Un seeder contiene un metodo por defecto, run. Este método se llama cuando se ejcuta el db:seed, comando Artisan. Dentro del método run, se puede insertar datos en la base de datos como se desee. En nuestro caso el seeder para la instancia de desarrollo se encuentra en database/seeds/DevelopSeed.php, y el ejemplo para Note es el siguiente:
DB::table('notes')->insert([
'user_id' => 1,
'title' => "Esto es un título",
'date' => "13/01/2021",
'description' => "Esto es una descripción",
'created_at' => Carbon::now()->format('Y-m-d H:i:s'),
'updated_at' => Carbon::now()->format('Y-m-d H:i:s')
]);
Hay que tener en cuenta que cada vez que se haga una modificación en las migraciones y los seeders hay que ejecutar el siguiente comando:
php artisan evidentia:reloadinstance
Este comando borra por completo las instancias y vuelve a ejecutar todas las migraciones de la carpeta Develop. Una vez realizado esto, debemos de realizar el enrutamiento, para realizar las peticiones PHP. Los enrutamientos se encuentran en routes/web.php. Aquí las rutas de Notes.
// Listar las notas
Route::get('note/list', 'NoteController@list')->name('note.list');
// Crear una nota
Route::get('note/create', 'NoteController@create')->name('note.create');
Route::post('note/new', 'NoteController@new')->name('note.new');
// Editar una nota
Route::get('note/edit/{id}', 'NoteController@edit')->name('note.edit');
Route::post('note/save', 'NoteController@save')->name('note.save');
// Eliminar una nota
Route::post('note/remove', 'NoteController@remove')->name('note.remove');
Como se puede observar, se pueden crear rutas para el listado, creación, edición y eliminación de cualquier modelo.
Se puede ver que existen dos rutas para crear, editar y solamente una para eliminar, esto se debe a que cuando se ingresa en el formulario se hace una petición Get y cuando se crea o se edita se hace una petición Post.
Cabe destacar que existe el método middleweare en las rutas, este método está en medio de la petición HTTP y cuando llega una petición, según la condición, la deja pasar o no. Aquí vemos un ejemplo de una ruta con middleweare:
// Solo visibles para profesores y presidentes
Route::middleware(['checkroles:LECTURE|PRESIDENT'])->group(function () {
Route::middleware(['checknotnull:User'])->group(function () {
Route::get('/profiles/view/{id}','ProfileController@profiles_view')->name('profiles.view');
});
Route::get('/profiles/view/{id_user}/evidence/{id_evidence}','ProfileController@evidences_view')->name('profiles.view.evidence');
});
En este caso lo que hace es comprobar si se ha iniciado sesión como profesor o presiente, y si es así, le deja pasar.
Este proceso de enrutado está en la parte del backend, en el frontend hay que implementar los componentes de Laravel que son los elementos del menú. Estos componentes se encuentran en resources/views/components/.
Veamos un ejemplo de un componente en el menú de alumno denominado menustudent, el cual se encuentra en resources/views/components/menus/menustudent:
<x-li route="note.create" icon='far fa-sticky-note' name="Crear nota"/>
<x-li route="note.list" icon='fas fa-sticky-note' name="Mis notas"/>
Ahora nos vamos a centrar en la creación del controlador. Un controlador se puede crear con el siguiente comando:
php artisan: make:controller NoteController
El controlador se creará en app/Http/Controllers.
En el controlador se crearán las funciones necesarias para las vistas, que veremos más adelante. Por ejemplo veamos la función listar de notas:
// Listar las notas
public function list()
{
$notes = Auth::user()->notes;
return view('note.list',['notes' => $notes]);
}
La función crear una nota:
// Crear una nota
public function create()
{
return view('note.createandedit');
}
public function new(Request $request)
{
$request->validate([
'title' => 'required|min:5|max:255',
'date' => 'required|',
'description' => ['required',new MinCharacters(10),new MaxCharacters(20000)],
]);
$user = Auth::user();
$note = Note::create([
'title' => $request->input('title'),
'date' => $request->input('date'),
'description' => $request->input('description'),
'user_id' => $user->id,
]);
$note->save();
return redirect()->route('note.list',\Instantiation::instance())->with('success', 'Nota creada con éxito.');
}
La función editar una nota:
// Editar una nota
public function edit($instance, $id)
{
$note = Note::find($id);
return view('note.createandedit',['note' => $note, 'edit' => true]);
}
public function save(Request $request)
{
$request->validate([
'title' => 'required|min:5|max:255',
'date' => 'required|',
'description' => ['required',new MinCharacters(10),new MaxCharacters(20000)],
]);
$user = Auth::user();
$note = Note::find($request->_id);
$note->title = $request->input('title');
$note->date = $request->input('date');
$note->description = $request->input('description');
$note->save();
return redirect()->route('note.list',\Instantiation::instance())->with('success', 'Nota actualizada con éxito.');
}
Y por último, la función borrar una nota:
// Borrar una nota
public function remove(Request $request)
{
$id = $request->_id;
$note = Note::find($id);
$note->delete();
return redirect()->route('note.list',\Instantiation::instance())->with('success', 'Nota eliminada con éxito.');
}
Una vez vistos los controladores veamos las vistas. Las vistas se guardan en resources/views, y se desarrollan en HTML. En nuestro caso, creamos dos archivos llamado list.blade.php y createandedit.blade.php.
En list.blade.php se muestran todos los datos del modelo que nos haga falta extraer de la base de datos para mostrar por pantalla.
En createandedit.blade.php se crea en pantalla las peticiones que hayamos creado en los controladores, ya sea editar, crear o eliminar.
Una vez creada esta funcionalidad pasamos a explicar su funcionamiento:
- Primero iniciaremos sesión como Alumno, una vez dentro, podemos visualizar en el menú de la izquierda la opción de crear nota.
- Accedemos a él y rellenaremos los campos establecidos para la creación de la nota.
- Una vez creada, nos redireccionará a la vista de la lista de Notas, la cual nos dará la opción de editar o borrar la nota.
Cambios en el proyecto:
- Se ha implementado una nueva función en el dashboard del profesor que consiste en mostrar evidencias relacionadas con las estadísticas de los alumnos.
- Se ha mejorado la interfaz del dashboard de profesor, en la cual ahora se visualiza un panel que muestra todas las reuniones de cada comité, y otro panel que muestra todos los subcomités que se hayan creado.
- Se ha añadido una nueva funcionalidad que consiste en la gestión de planificaciones.
- Se ha implementado un nuevo CRUD en el que el alumno puede gestionar cualquier incidencia.
- Se ha implementado un nuevo CRUD en el que el alumno puede gestionar una valoración sobre un comité.
- Se ha implementado un nuevo CRUD en el que el alumno puede gestionar una lista de contactos.
En este apartado se dará una visión general del proceso de desarrollo utilizado para realizar los incrementos junto con las herramientas utilizadas. Es importante aclarar este punto debido a que, de esta manera, podemos establecer una metodología de trabajo común para que todos los miembros podamos llevar las mismas pautas en el desarrollo. Además, facilitaría la incorporación de nuevos integrantes al grupo ya que podrían disponer de un guía de trabajo y, de esta forma, sería más amena su integración.
Posteriormente, se expondrá un ejemplo de una funcionalidad añadida al sistema y una explicación sobre cómo se abordaría todo el ciclo hasta tener el cambio en producción para tener también un caso práctico como guía.
Primero, se debe realizar la instalación del entorno de desarrollo el cuál será explicado posteriormente en el apartado “Entorno de desarrollo”. Una vez realizado el paso anterior, cada uno de los integrantes del equipo de trabajo deberán de crear una rama a partir de la rama develop donde cada uno realizará sus propios incrementos. Al estar usando GitFlow como estilo de trabajo y la rama master como producción, se integrarán los cambios en la rama develop, anteriormente mencionada, para luego poder corregir posibles errores surgidos a raíz de la unión de todas las funcionalidades desarrolladas a lo largo del tiempo y, una vez que se hayan corregido los errores originados y que esté todo listo para poder presentar el proyecto, subir el proyecto a producción.
Después de crear las ramas de trabajo, se descargará cada uno su rama en su equipo local con los comandos de Git mediante símbolo de sistema. Una vez traída la rama, se introducirá los comandos oportunos para comprobar si hay cambios en la rama develop, que a partir de ahora la llamaremos preproducción, y, en el caso de que haya cambios, traerlos a la rama de trabajo local para poder evitar cualquier tipo de desactualización.
Luego de haber realizado el proceso anterior, los desarrolladores ya estarían listos para comenzar a implementar sus tareas. En este proceso de desarrollo del código de las tareas, estas constarán del propio desarrollo de la funcionalidad, las pruebas oportunas e incidencias encontradas tanto en el código de la propia funcionalidad como en el código del sistema, y a su vez, se debe de ir realizando subidas de código de forma paulatina a GitHub mediante los comandos de Git oportunos. Este tipo de metodología de subida de código es debido a que se debe realizar una integración continua.
Una vez subido el código, se debe realizar merge con la rama de preproducción para ir uniendo el trabajo de todos los integrantes, en esta acción se lanzará una herramienta de integración continua, de la cual hablaremos posteriormente, llamada GitHub Actions. Al haberlo juntado todo, se comprobará que no exista ningún error. Después de realizar la comprobación y dejarlo todo listo para realizar el despliegue, se realizará otro merge con producción para realizar la acción de despliegue mencionada anteriormente. Para este despliegue se utilizará la herramienta Evidentia Cloud, de la cual hablaremos después.
Las herramientas utilizadas son GitHub Actions y Evidentia Cloud.
Para realizar la integración continua hemos usado GitHub Actions como variante a TravisCI ya que venía integrado en el propio proyecto. Esta herramienta se lanza cuando se realiza un merge con otra rama. Cuando se lanza, la misma herramienta realiza varias acciones, entre las cuales están la instalación de las dependencias de los composer, prepara la aplicación o recorre lo tests. En el caso de que todas las acciones que lanza la herramienta terminen con éxito, saldrá un tick verde al lado de la información del merge que nos indica que vamos realizando integración continua. En el caso de que no terminase con éxito, aparecerá una cruz roja y debemos de comprobar que ha fallado y solucionarlo.
Para llevar a cabo el despliegue hemos utilizado Evidentia Cloud, que viene preparada en el propio proyecto, como variante a Heroku propuesta para el proyecto decide. Al tener ya todo preparado en la rama de producción y la release, se accederá a la url deploy.evidentia.cloud en la cual se tendrá que hacer login con unas credenciales proporcionadas previamente.
Ya una vez con la sesión iniciado se tendrá que indicar el repositorio de GitHub que se quiere desplegar a partir de su link. Por último, se selecciona el botón “Desplegar el proyecto” y la propia herramienta comenzará a funcionar. Ya en el proceso de despliegue, la herramienta irá haciendo sus comprobaciones y, si todo ha ido correctamente, se nos indicará que todo ha funcionado correctamente y nuestro sistema quedará desplegado y listo para mostrar.
Vamos a tomar como funcionalidad la creación de una agenda. El integrante del grupo que realice la funcionalidad primero debe crear una rama a partir de develop en GitHub para poder trabajar en ella. Luego creará una rama en local con el mismo nombre y, con los comandos necesarios, la asociará a la rama creada previamente. Una vez asociada, debe comprobar si hay algún tipo de actualización en el repositorio y, en caso de que la haya, traérsela para poder trabajar con el proyecto actualizado.
A partir de este punto el proyecto está listo para ser desarrollado. El compañero comenzará a desarrollar las clases, las funciones, los controladores y las vistas necesarias para realizar su funcionalidad. Además, posteriormente, se desarrollará las incidencias y los tests pertinentes. Los test serán probados antes de ser subidos cerciorarse de que funcionen correctamente y no de fallo la herramienta de integración continua.
Como se ha mencionado en los apartados anteriores, estos incrementos deberán ser subidos paulatinamente para ir favoreciendo la integración continua y que no haya demasiados conflictos.
Cuando las tareas vayan siendo realizadas y subidas a la rama de trabajo, se debe de ir haciendo merge con la rama de preproducción para que se integren con las demás funcionalidades. En cada merge, la herramienta de integración continua se lanzará y realizará las acciones pertinentes. Si todas las acciones se realizan correctamente, la herramienta considerará que se está realizando bien la integración y mostrará un tick verde en la rama de preproducción. En el caso contrario, mostrará una cruz roja que indicará que algo ha fallado, como por ejemplo el lanzamiento de los tests, y se debe corregir.
En el momento en el que todas las tareas estén bien integradas en el entorno de proproducción y todo el sistema esté comprobado y sin errores, se subirá el proyecto a producción donde se considerará ya finalizado el desarrollo de tareas.
Cuando el proyecto se encuentre en este estado, se realizará una realease previamente al despliegue y, a continuación, se iniciará el despliegue mediante la herramienta Evidentia Cloud que seguirá el siguiente procedimiento:
Se accederá a la url deploy.evidentia.cloud, donde se tendrá que hacer login con las credenciales que se nos ha proporcionado. A continuación, se indicaría el link del repositorio de GitHub que, en nuestro caso, sería “https://github.com/yoadimpen/evidentia.git” y, para finalizar, se seleccionaría el botón “Desplegar el proyecto”. Una vez finalizado, y si todo ha funcionado correctamente, se nos proporcionará un link con el cual podremos acceder a nuestro sistema ya desplegado.
En este apartado se describirá con detalle cuál ha sido el entorno de desarrollo utilizado para la elaboración del proyecto, indicando las versiones usadas y los pasos seguidos para su instalación, haciendo funcionar el sistema por completo. También se indicará si algún miembro del equipo de trabajo ha usado alguna tecnología diferente respecto a los demás y por qué motivo.
En nuestro caso, hemos optado por desarrollar un proyecto relacionado con las jornadas InnoSoft, es decir, hemos trabajado con Evidentia en lugar de con Decide.
Para desplegar Evidentia en local en la máquina que queramos trabajar, es necesario descargar e instalar diferentes softwares previos a la instalación de Evidentia en sí. A continuación, se enumeran los softwares necesarios con una breve descripción de cómo instalarlos, ya que estos procesos de instalación no tienen dificultad alguna.
-
VirtualBox: En primer lugar, será necesaria la instalación de una máquina virtual para poder trabajar con Evidentia, la versión elegida ha sido la 6.1.16. Para la instalación de este software debemos ejecutar el archivo de instalación y seguir los pasos indicados en la misma. Enlace de descarga: VirtualBox
-
Vagrant: En segundo lugar, necesitaremos instalar Vagrant, una herramienta para la creación y configuración de entornos de desarrollo virtualizados. La versión de Vagrant utilizada es la 2.2.10. Para su instalación solo es necesario ejecutar el archivo de instalación y seguir los pasos indicados. También debemos recalcar que será necesario reiniciar nuestras máquinas después de instalar Vagrant para completar el proceso de instalación. Enlace de descarga: Vagrant
-
Git: Por último, necesitaremos usar Git como software de control de versiones, en nuestro caso la versión 2.29.2. Para su instalación, al igual que con VirtualBox y Vagrant solo necesitaremos ejecutar el archivo de instalación y seguir los pasos que nos indiquen. Enlace de descarga: Git
Una vez tengamos instalado todo el software descrito anteriormente debemos clonar en una carpeta personal el repositorio que usaremos durante el proyecto. En primer lugar, es importante recordar que se debe realizar un Fork sobre el repositorio facilitado por David Romero Organvídez (creador de Evidentia).
Repositorio facilitado por David: https://github.com/EGCETSII/evidentia.git
Repositorio del grupo obtenido al hacer Fork: https://github.com/yoadimpen/evidentia.git
Para clonar el repositorio usaremos el comando “git clone” seguido de la URL del repositorio que queramos usar. Una vez clonado el repositorio sobre el que trabajaremos podemos comenzar con la instalación de Evidentia en sí.
Los seis miembros del equipo de trabajo han usado el sistema operativo Windows para el desarrollo del proyecto, por tanto, se darán las indicaciones para instalar el software en este sistema operativo, aunque debemos indicar que Evidentia también puede instalarse en Mac y Linux. Se recomienda tener desactivado el Cortafuegos/Firewall, aunque en Windows no suele dar problemas.
El proceso de instalación de Evidentia no consta de muchos pasos, pero alguno de ellos puede conllevar un buen periodo de tiempo para su finalización como veremos a continuación, así que se recomienda tener paciencia para la instalación.
Podríamos dividir este proceso de instalación en dos partes, la primera es la más tediosa de ella debido a su duración, pero en cuanto a dificultad no debe preocuparnos. Para llevar a cabo el primer paso de la instalación debemos entrar en la carpeta evidentia, la cual se encontrará en la carpeta en la que hayamos clonado nuestro repositorio, dentro de esta carpeta debemos localizar y clicar un archivo llamado install.bat (no confundir con el archivo install.sh). Una vez hagamos click se nos abrirá una ventana de comandos en la cual debemos elegir la opción número 3, virtualbox. Luego solo debemos esperar, aunque como indicamos anteriormente este es el paso más tedioso ya que puede tardar más de 30 minutos en finalizar.
Una vez concluido el paso anterior debemos localizar el archivo host.bat en la misma carpeta evidentia del paso anterior. Una vez encontremos ese archivo deberemos ejecutarlo como administrador haciendo click con el botón derecho del ratón; esto sirve para habilitar un acceso más sencillo a través del navegador, ya que podremos visualizar Evidentia buscando en nuestro navegador evidentia.test, en caso contrario tendríamos que usar '192.168.10.10', lo cual es más difícil de recordar.
Si se ha encontrado algún problema con la instalación puede visitar está página de ayuda: https://github.com/drorganvidez/evidentia/wiki/6.-Problemas-durante-la-instalaci%C3%B3n
Una vez en evidentia.test podremos iniciar sesión con algunos usuarios creados por defecto como los siguientes:
ESTUDIANTE
Usuario: alumno1
Pass: alumno1
PROFESOR
Usuario: profesor1
Pass: profesor1
Por último, para cada vez que queramos arrancar la máquina debemos ejecutar el comando vagrant up desde la carpeta homestead dentro de evidentia. Y para parar la máquina vagrant halt de forma análoga a lo anterior.
Para finalizar este apartado nos queda por añadir que todo el equipo de trabajo decidió usar por unanimidad Visual Studio Code para editar el código necesario, en concreto la versión 1.51.1.
Para nuestro proyecto de Innosoft hemos seguido un proceso de gestión de incidencias que está recogido en el apartado de Issues de nuestro repositorio de Evidentia (GitHub). Ahí, se puede observar un conjunto de incidencias que pueden estar abiertas o cerradas. Si una incidencia está abierta significa que la incidencia está pendiente de resolver y si, por el contrario, está cerrada, significa que ya está resuelta. A una incidencia resuelta se le añade el pull request que le corresponda y un comentario de solución que, en el apartado 'Plantilla', explicaremos con más detalle.
Los pasos para resolver una incidencia son:
- Detectar la incidencia: Para realizar el primer paso, no sólo basta con detectarla, hay que entender qué es lo que está sucediendo.
- Informar de la incidencia: Cuando ya hemos entendido la incidencia, procedemos a informar al equipo de trabajo (de forma detallada). Este es el momento en el que se puede aprobar, o no, la incidencia.
- Escribir la incidencia: Una vez que la incidencia ha sido aprobada, el autor deberá escribirla en el apartado ‘issues’. Las incidencias no podemos escribirlas de cualquier manera, sino que usaremos una plantilla que explicaremos con más detalle en el siguiente apartado.
- Arreglar la incidencia: En este paso procederemos a solucionar la incidencia en nuestro entorno de trabajo.
- Aprender de la incidencia: Por último, debemos aprender de la incidencia resuelta para que no vuelva a suceder.
Con el objetivo de seguir un mismo patrón, para la creación de las incidencias hemos realizado una plantilla genérica. Esto nos ayudará a tener una mayor limpieza en cada una de ellas. La plantilla que hemos utilizado se compone de un/a:
- Título: El título contiene el siguiente formato ‘IDXXX:’ y seguido del nombre de la incidencia, donde ‘XXX’ es el número de la incidencia. Por ejemplo, ‘ID016: Las notas no tienen fecha’.
- Resumen: El resumen indica la descripción de la incidencia. Si seguimos con el ejemplo anterior, sería: ‘Es importante que las notas tengan una fecha. Al usuario, en un futuro, puede que le haga falta saber cuándo las anotó’.
- Prioridad: La prioridad se identifica con el nivel de gravedad de la incidencia. Existen tres tipos de prioridad: baja, media y alta. Para este ejemplo, como es una mejora, el nivel de prioridad es medio. El por qué, lo explicaremos en el apartado de prioridades.
- Fecha: La fecha indica la fecha en la que se ha identificado la incidencia.
- Asignación: La asignación indica qué miembro/s han realizado la incidencia.
- Etiqueta: La etiqueta se corresponde con el tipo de incidencia. Éstas pueden ser: enhancement, invalid, documentation, bug y ui. Siguiendo el ejemplo anterior, para una mejora, utilizaremos enhancement. En el apartado de etiquetas lo veremos con detalle.
- Pull request: El pull request debe estar relacionado con su incidencia correspondiente.
- Solución: La solución indica el cómo hemos afrontado esa incidencia, qué hemos cambiado…
Establecer un nivel de prioridad es esencial a la hora de conocer la gravedad de una incidencia. Pueden ser de tres tipos:
- Baja: La prioridad baja se corresponde con pequeños detalles por pulir en la interfaz de usuario. En su mayoría subjetivos.
- Media: La prioridad media se identifican con mejoras, aspectos que impiden una buena navegación y/o no informan de forma correcta al usuario, pero no afectan a la funcionalidad del sistema.
- Alta: La prioridad alta indica un mal funcionamiento del sistema.
- Crítica: La prioridad crítica significa que el sistema no puede funcionar.
Las etiquetas también son importantes porque nos sirven para detectar el tipo de incidencia. Están clasificadas en seis tipos:
- Invalid: La etiqueta invalid se corresponde con aspectos que no parecen correctos. El nivel de prioridad suele ser baja o media.
- Documentation: La etiqueta documentation, como su nombre propio indica, está relacionado con la documentación (ya sean mejoras o documentación añadida). El nivel de prioridad suele ser baja o media.
- Enhancement: La etiqueta enhancement se identifica con mejoras, ya sea de nuevas entidades o solicitudes. El nivel de prioridad es media.
- Bug: La etiqueta bug indica que algo no está funcionando bien. El nivel de prioridad es alta.
- Help wanted: La etiqueta help wanted indica que la atención a esta incidencia es necesaria. El nivel de prioridad puede ser alta o crítica.
- Ui: La etiqueta ui está relacionada con la interfaz de usuario. El nivel de prioridad puede ser cualquiera de los tres.
Con respecto a las incidencias, en nuestro equipo de trabajo hemos aprendido que:
- El cambio es inevitable, pero siempre es mejor el remedio que la enfermedad.
- Para resolver una incidencia hace falta una estrategia.
- Si una incidencia no se gestiona bien puede haber muchos problemas. Por ello, hemos establecido una plantilla acorde a éstas.
- Informar de un error/incidencia es imprescindible para un buen mantenimiento del proyecto.
Esta sección tratará de detallar de qué forma se gestiona el código fuente de esta extensión a Evidentia. Es necesario destacar la importancia que tiene la gestión de código fuente dentro de un proyecto (de cualquier índole) ya que el cambio es algo inevitable. Más difícil es la situación en la que además de cambios, el equipo encargado de realizarlos tiene un tamaño considerable. Con algunas complicaciones más, se convierte en una tarea tediosa. Por ello, se deben enunciar una serie de prácticas que deben ser respetadas para llevar adelante el proyecto de forma adecuada.
Se utilizará el presente repositorio como copia general, la cuál estará disponible tanto para el equipo de desarrollo como para toda persona ajena (solo modo consulta en este caso). Dicho repositorio surgió a partir de un fork del siguiente: https://github.com/EGCETSII/evidentia
A partir de esta copia general, cada miembro del equipo se creará una copia local, la llamada rama, en la que deberá implementará los incrementos funcionales que le corresponden siguiendo siempre las pautas que se indican en las próximas subsecciones.
Una vez implementado dicho incremento, unirá los cambios a la copia general con los comandos de git correspondientes de forma que estén disponibles para todos los demás integrantes del equipo. De esta manera se tendrán que realizar todos y cada uno de los incrementos funcionales planificados para el proyecto, así como aquellas ocasiones en los que se deberá arreglar cierta parte del proyecto en caso de haber conflictos internos.
La estrategia de gestión de ramas es una decisión muy importante al abordar un proyecto de software ya que definirá el proceso que tendrá que seguir un incremento funcional o cualquier cambio dentro del repositorio. En nuestro caso y teniendo en cuenta la experiencia que ha tenido el equipo con esta metodología el último año, hemos decidido usar GitFlow. A pesar de que sea un metodología rígida o poco flexible, se ajusta a las necesidades que tenemos en el proyecto.
A modo de resumen y sin gran extensión, constará de dos ramas principales, master y develop. La rama master será aquella rama reservada para versiones acabadas del proyecto, como por ejemplo la que se desplegará al final del proyecto. Como se ha ido llamando en la presente documentación, la rama de producción.
Por otro lado, develop es la rama dedicada al desarrollo de los distintos incrementos funcionales que se incluirán durante el desarrollo. También habrá ramas secundarias como hotfix para aquellas ocasiones en las cuales deberemos reparar o ajustar cierta parte del proyecto.
Como se comentaba, GitFlow puede parecer inflexible ya que a lo largo de un proyecto de desarrollo software puede suceder de todo pero se ha intentado encontrarle hueco a cada situación mediante esta metodología.
El propio código de la aplicación, como se ha comentado en otras secciones, es Laravel que se puede entender como un lenguaje PHP refinado, con una capa por encima. A lo largo del proyecto seguiremos la estructura de archivos ya establecida por el desarrollador de Evidentia, David Romero Organvídez.
Para consultar información de Laravel se recurrirá a páginas como por ejemplo la oficial que contiene toda la documentación disponible: Laravel v7.x
Se debe hacer especial mención a las versiones utilizadas. Laravel, al ser un framework que evoluciona con gran frecuencia, puede provocar que haya ocasiones en las cuales ocurran conflictos si se modifican los contenidos continuamente dependiendo de la versión en la que se encuentre actualmente. Por ello, y siguiendo las recomendaciones del desarrollador original, para el desarrollo de los incrementos funcionales presentes en este repositorio, se ha seguido la versión 7 puesto que es en la que se empezó a desarrollar el proyecto original.
Otro aspecto de gran importancia en el desarrollo de un proyecto software es la política de nombrado en los commits. Todos hemos intentado empezar con iniciativa pero acabamos haciendo un commit con el mensaje 'a ver si funcionaaaaa', por ejemplo. Para que no se llegue hasta ese tipo de situaciones, es recomendable establecer una política desde el principio. La nuestra es muy simple. El mensaje de cualquier commit dentro de este repositorio debe tener las siguientes características:
- Tiene que ser descriptivo. Es decir, si has implementado una funcionalidad de autenticación de un tipo de usuario en particular, el mensaje "feat: implementada la autenticación de la presidenta" es mejor que "autenticación hecha", por ejemplo.
- No debe tener faltas de ortografía. Parecerá algo obvio pero importante de mencionar ya que de lo contrario demostrará una falta de profesionalidad.
Por otro lado, el propio commit tiene que constar de un cambio sustancial del incremento funcional. De nada sirve hacer un commit al abrir un corchete o al crear una clase vacía. Se permite hacer commits cuando todavía existen errores en lo que se esté desarrollando ya que es algo normal cuando nos encontramos en proceso de desarrollo.
Por último, como parte de la gestión de código queremos incluir un ejemplo de qué pasos tendría que seguir un miembro del equipo al tener asignado una nueva tarea de incremento funcional. Por ejemplo, un CRUD de una entidad nueva. Los pasos que deberá seguir el miembro en cuestión son los siguientes:
Paso 1: Suponiendo que nos encontramos en el entorno de GitHub (ya sea en la página web o una aplicación de escritorio), lo primero que debe hacer el desarrollador es crear una rama dedicada a implementar la nueva funcionalidad.
Paso 2: Deberá tener disponible esa rama en local para poder hacer todos los cambios necesarios.
Paso 3: Una vez tenga la rama local disponible, procederá a implementar los cambios necesarios para el correcto funcionamiento del CRUD antes indicado. Durante este paso es recomendable hacer un commit por cada cambio sustancial. Por ejemplo, si el CRUD consiste de creación, lectura, actualización y eliminación de un objeto, un cambio sustancial sería la posibilidad de lectura de dicho objeto.
Paso 4: Al tener la funcionalidad implementada al 100%, el desarrollador deberá hacer un último commit indicando que el incremento ha sido realizado y está listo para juntar de nuevo con la rama develop mediante un merge. Antes de ello deberá trasladar los cambios locales al repositorio general bajo la misma rama.
Paso 5: Si todo ha ido bien hasta ahora lo único que falta sería hacer el propio merge a develop para que la funcionalidad esté disponible para todo aquel que cree una rama de desarrollo de funcionalidad nueva.
Como última observación, el desarrollador deberá haber incluido las pruebas nuevas hechas a partir del incremento funcional.
Este procedimiento se debe seguir para cualquier cambio que se requiera dentro del proyecto. Se incluye la siguiente flexibilidad: si el cambio en cuestión es menor y no afecta a la parte funcional del producto, podrá realizarse en una rama nueva a través de la página de GitHub sin necesidad de crear una copia local.
Aunque esta parte se desarrollará con más detalle en una sección próxima, hemos visto oportuno mencionar cierta parte aquí.
La razón de ello es que el proyecto de Evidentia incluía un archivo de configuración para utilizar la herramienta de integración continua GitHub Actions pero en dicho archivo había una incompatibilidad de versiones en algunos paquetes que necesitaba Evidentia para funcionar. Decidimos documentar todo este proceso como una incidencia más, en concreto la ID006, pero hemos de indicar que se ha seguido la misma estrategia de ramificación. Como ya se ha comentado, se puede encontrar más información sobre este percance en la próxima sección de 'Gestión de Liberaciones, Despliegue y Entregas'.
Con respecto a la gestión de la construcción, el desarrollo del proyecto se organiza mediante la metodología GitFlow en el repositorio único ya determinado.
Para comenzar, todos los cambios que el equipo de desarrollo pretenda realizar al proyecto deberán ser realizados en una rama del repositorio bajo la siguiente denominación 'feature-Cambio'. En esta nomenclatura, 'feature' nos diferencia que lo que se está aportando es una funcionalidad nueva a integrar, mientras que la parte de 'Cambio' es una referencia corta que mantiene cierta relación con la característica a implementar.
En el momento que las características se implementan y son probadas positivamente por los test realizados localmente y la plataforma GitHub Actions, se introducen los cambios en la rama develop realizando un pull request.
Respecto a la integración continua, haremos uso de la herramienta GitHub Actions. GitHub Actions es una herramienta especialmente dedicada a preservar la integración continua de un repositorio GitHub. Actions ofrece líneas de trabajo que puede ejecutar el código del repositorio y ejecutar automáticamente los test que se integren en este.
Es posible configurar Actions para que se ejecute cuando se produzca un evento de GitHub o periódicamente. Principalmente, nos permite conocer si nuestros commits provocan fallos en el proyecto, hacer más rápido y cortos los pull request comprobando si la rama es aceptada, certificando así que el código que pretendemos introducir en la rama es estable.
Respecto a la configuración de GitHub Actions, en primer lugar nuestro proyecto ya estaba configurado por el desarrollador original, específicamente los siguientes apartados:
- Creación de un archivo YALM en el directorio workflows.
- Configuración del archivo YALM con las especificaciones necesarias para el proyecto como pueden ser:
- Versión de SQL.
- Conexión con la base de datos.
services:
mysql:
image: mysql:5.7
env:
MYSQL_ROOT_PASSWORD: secret
MYSQL_DATABASE: homestead
MYSQL_USER: homestead
MYSQL_PASSWORD: secret
ports:
- 33306:3306
options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3
steps:
- name: Verify MySQL connection from host
run: |
sudo apt-get install -y mysql-client
mysql --host 127.0.0.1 --port 33306 -uroot -psecret -e "GRANT ALL ON *.* TO 'homestead'@'%' identified by 'secret'; FLUSH PRIVILEGES;"
- uses: actions/checkout@v1
with:
fetch-depth: 1
- name: Install composer dependencies
run: |
composer install --no-scripts
composer update
- name: Prepare Laravel Application
run: |
cp .env.ci .env
php artisan key:generate
php artisan migrate
php artisan db:seed
php artisan db:seed --class=InstancesTableSeeder
- name: Run Testsuite
run: vendor/bin/phpunit tests/
Aún así, a la hora de usarlo en nuestro proyecto, GitHub Actions parecía no estar bien configurado ya que a la hora de realizar los pull request devolvía errores en el procesado de la rama. Tras comentar dicha problemática con el desarrollador principal David Romero Organvídez, nos explicó el porqué de estos errores.
Para la correcta integración de GitHub Actions en nuestro proyecto, es necesario que se elimine el archivo composer.lock que recibimos por defecto, además de actualizar la configuración del archivo YALM anteriormente mencionado 'ci.yml' y la versión php en el archivo 'composer.json' para que se pueda soportar la versión 8.0.0. Concretamente, es necesario añadir al archivo YALM el apartado composer update en los pasos de construcción de la máquina virtual.
"name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
"framework",
"laravel"
],
"license": "MIT",
"require": {
**"php": "^7.2.5|^8.0.0",**
"barryvdh/laravel-dompdf": "^0.8.6",
"caouecs/laravel-lang": "~4.0",
"fideloper/proxy": "^4.2",
"fruitcake/laravel-cors": "^1.0",
"guzzlehttp/guzzle": "^7.0",
"intervention/image": "^2.5",
"laravel/framework": "^7.21",
"laravel/tinker": "^2.0",
"laravel/ui": "^2.0",
"maatwebsite/excel": "^3.1"
}
Las liberaciones de nuestro proyecto se gestionan mediante la misma metodología GitFlow en la cual indicamos que cada funcionalidad nueva lleva su propia rama dedicada y se van juntando en la develop. Una vez se hayan hecho todas las implementaciones, se reúne todo el código en la rama master y se prepara una release nueva. Tal como se explica en la sección Entregas de este mismo apartado, la versión actual de la aplicación es 1.1.1-innosoft-guadalete.
En cuanto a la licencia, el proyecto base del cual hicimos fork tenía una licencia GNU General Public License v3.0, la cual permite su distribución y uso propio, así como la realización de modificaciones al proyecto. Al conservar el código base, hemos optado por continuar utilizando la misma licencia de uso en nuestro repositorio, GNU General Public License v3.0.
Para el despliegue hemos optado por la alternativa más simple. Evidentia de por sí nos permite desplegar la aplicación con las mejoras incluidas a través de un portal muy intuitivo. En concreto, Evidentia Deploy
En dicho portal se necesita una cuenta propia para poder realizar el despliegue. Para obtenerla, se puede completar un formulario disponible en la plataforma pero en nuestro caso no cogimos ese camino ya que a la hora de obtener la cuenta, dicho formulario no estaba disponible y tuvimos que contactar con el desarrollador. Nos creó una cuenta personalmente él con los siguientes datos:
- Cuenta de despliegue: evidentia_ironman
- Contraseña: Contactar con el equipo de trabajo innosoft-guadalete en caso de que se requiera.
Tras obtener la cuenta pudimos acceder al panel de despliegue que se muestra en la siguiente imagen:
En dicho panel se nos ofrece la posibilidad de indicar la dirección url de nuestro repositorio, desde el cual queremos desplegar la rama master. Es la única pizca configuración que se requiere. Al introducir la dirección y guardar se puede desplegar mediante el botón 'Desplegar el proyecto'.
Como se comentó en el vídeo y se puede visualizar en la siguiente captura, podemos observar los distintos pasos por los que pasa nuestro código hasta ser desplegado:
Los pasos son bastante parecidos a los que se realizan en la herramienta GitHub Actions. Podemos ver que se clona el repositorio, se instalan las librerías y dependencias necesarias para que nuestro proyecto pueda funcionar, se configuran algunas variables de entorno, se crea y rellena la propia base de datos con todas las tablas indicadas en la carpeta 'database/migrations/instances' del repositorio y finalmente, se despliega el proyecto.
A la hora de desplegar tuvimos varios percances que fueron subsanados en cuestión de horas. Al principio recibíamos un mensaje de confirmación en el panel de despliegue comentando que la aplicación se había desplegado de forma correcta. Pero, al intentar acceder nos dimos cuenta que era una versión de Evidentia anterior a la que nosotros habíamos trabajado. Decidimos contactar con el desarrollador principal ya que resolver dicho problema estaba fuera de nuestro alcance. Nos comentó que efectivamente, a la hora de desplegar, la plataforma no estaba actuando de forma correcta.
Tras subsanar dicho error (gestionado de forma externa al equipo de trabajo innosoft-guadalete), tuvimos que iniciar la gestión de una incidencia nueva. Constaba de que al desplegar la aplicación, la plataforma estaba creando una instancia nueva, para lo cual solamente utilizaba las tablas de la carpeta mencionada anteriormente, 'database/migrations/instances'. Ya que nosotros, por recomendación de David Romero, habíamos guardado los cambios únicamente en la carpeta 'database/migrations/develop', las nuevas tablas no estaban siendo generadas a la hora de desplegar. Al solucionarlo, siguiendo la metodología GitFlow anteriormente explicada, pudimos desplegar directamente desde la plataforma de forma exitosa.
Actualmente, nuestro proyecto puede ser visto en la siguiente dirección: Evidentia innosoft-guadalete
Si se requiere utilizar un usuario concreto, los siguientes están disponibles:
username: alumno1
pass: alumno1
username: alumno2
pass: alumno2
username: secretario1
pass: secretario1
username: secretario2
pass: secretario2
username: coordinador1
pass: coordinador1
username: coordinador2
pass: coordinador2
username: coordinadorregistro1
pass: coordinadorregistro1
username: coordinadorregistro2
pass: coordinadorregistro2
username: presidente1
pass: presidente1
username: presidente2
pass: presidente2
Para las entregas hemos seguido los procedimientos indicados en la wiki de la asignatura. Conforme han ido pasanado las semanas, se han ido completando los distintos milestones indicados en la planificación de la asignatura. Para cada uno de ellos hemos tenido que enviar un formulario con algunos datos del proyecto entre los cuales se encontraba el enlace a este repositorio, que es nuestra principal fuente de trabajo. El repositorio se está utilizando tanto para almacenar código, como para almacenar la documentación necesaria en la que se puede ver reflejado el trabajo que hemos ido haciendo.
En cuanto a la documentación, como ya se ha comentado estará disponible únicamente en este repositorio y contiene todos los apartados necesarios que se nos han indicado. En nuestro caso, estaremos entregando la documentación en el milestone M3, tal como se indica al principio de nuestra wiki.
Por otro lado, el código que se vaya generando mediante la metodología GitFlow fluirá hacia la rama develop y después a la master. Tras completar las tareas se ha formulado una release nueva siguiendo la política de versionado vX.Y.Z-etiqueta_descriptiva en la que cada número indica un cambio de dimensión distinta:
- X: una edición nueva de la aplicación con grandes incrementos sustanciales.
- Y: una funcionalidad nueva añadida en la aplicación.
- Z: arreglos de bugs, cambios sustanciales,...
En nuestro caso, decidimos lanzar la versión 1.1.1-innosoft-guadalete en la cual se indica que se han añadido funcionalidades nuevas y se ha solucionado la incidencia del despliegue.
La propuesta de cambio en la que hemos pensado es completar la extensión del dashboard añadiendo información relativa a las planificaciones de reunión. Un profesor tendrá visibles el número de reuniones ordinarias y extraordinarias.
Esta tarea tiene relación con 3 del total de incrementos realizados:
- Extensión del dashboard de profesor (evidencias)
- Extensión del dashboard de profesor (reuniones)
- Implementación de las planificaciones de reunión
Para ello, se han seguido los siguientes pasos:
Paso 1: Se ha creado la incidencia ID033, siguiendo el nombrado que se ha ido adoptando durante el desarrollo del proyecto. En dicha incidencia, y usando la plantilla que se ha elaborado, se han indicado los principales aspectos en los que influirá el cambio. A modo de resumen, y sin mucha repeteción, queremos realizar un cambio en el dashboard del profesor. Ya que la gestión de incidencias se hace a través de GitHub, un navegador cualquiera será la única herramienta que se necesitará para este paso.
Paso 2: El siguiente paso que se tiene que realizar es crear una rama dedicada para la implementación de este cambio. Siguiendo la metodología GitFlow, la rama se ha creado a partir de la develop y por distinción se ha nombrado cambio-M3. Ahora lo que necesitaremos es un entorno de programación adaptado para trabajar con Laravel. En nuestro caso, a lo largo del desarrollo del proyecto hemos utilizado Visual Studio Code ya que incluye muchas extensiones cómodas dependiendo de tus necesidades personales.
La creación de la rama en sí se puede hacer de nuevo a través del navegador y accediendo al repositorio en cuestión, o por el contrario, también se puede utilizar una consola en la que introducir el comando git branch <nombre_de_la_rama> habiéndote situado en la rama develop con el comando git checkout develop.
Paso 3: Realizar el cambio en sí, la implementación de esa información nueva. Se tendrán que implementar las consultas a la base de datos correspondientes como métodos de la clase MeetingPlanning. Por otro lado, se tendrá que actualizar la vista home.blade.php en la que se disponen los contenidos del dashboard. Al realizar el cambio por completo tendremos que mover los cambios locales al repositorio remoto. Los comandos que se tienen que aplicar son los siguientes:
git add --all
git commit -m "feat: visualización de planificaciones en dashboard de profesor"
git push origin cambio-M3
Paso 4: Una vez movidos los cambios de local a remoto, tendremos que juntarlos a la rama develop y después a la master para poder hacer el despliegue. Una vez hecho el merge desde la página de GitHub en el navegador, se activará una nueva construcción con GitHub Actions. En dicha construcción no nos tendremos que involucrar puesto que los procesos están automatizados. Como se ha mencionado en la sección de 'Gestión de la Construcción e Integración Continua', GitHub Actions nos permite saber si nuestro commit ha afectado de alguna forma al proyecto. Si obtenemos el check verde podremos pasar al siguiente paso. En caso contrario, tendremos que revisar qué ha ido mal y adoptar las medidas necesarias.
Paso 5: Una vez integrado el cambio en la rama master, tendremos que dirigirnos al portal de despliegue que utilizamos, Evidentia Deploy. Ahí, si no está guardada nuestra url del repositorio desde el cual queremos hacer el despliegue, deberemos indicarla. Al guardarla procederemos a iniciar el despliegue y la plataforma tomará la responsabilidad. Al finalizar deberemos poder visualizar el cambio realizado en la misma dirección, Evidentia Desplegado.
Con ello, terminará de forma exitosa todo el proceso del cambio.
Durante el proyecto hemos ido adquiriendo habilidades que antes no estaban muy desarrolladas o directamente no formaban parte de nuestras competencias.
Por ejemplo, hemos trabajado con un framework completamente nuevo para nosotros, Laravel. La percepción que teníamos de PHP no era muy agraciada que digamos y Laravel nos ha sorprendido en cuanto a la reducción de complejidad que le añade. Por supuesto no nos hemos convertido en profesionales de Laravel pero sí que hemos adquirido competencias al respecto que nos resultaban imposibles antes del comienzo de este proyecto.
Por otro lado, varios miembros del grupo no nos conocíamos previamente. Sin embargo, hemos podido integrarnos bien y conociendo las destrezas de cada uno hemos podido organizarnos de la mejor forma posible.
Por último, en cuanto a la parte teórica de la asignatura, se nos han impartido conocimientos en los que no se había profundizado tanto en cursos anteriores. Como por ejemplo, el tema de las licencias ha sido bastante interesante de cara a lanzar un proyecto al mundo y que la comunidad lo use.
Sin duda, esta asignatura ha sido una oportunidad para ampliar nuestros conocimientos en áreas múltiples.
Una vez finalizado el proyecto podemos sacar varias conclusiones sobre el trabajo realizado por el equipo.
Por un lado, la inexperiencia puede que haya sido el factor más destacado en el desarrollo del proyecto, ya que, aunque habíamos realizado otros trabajos en grupo, nunca habíamos desarrollado uno con esta metodología a la hora de organizarnos y gestionar cada aspecto del proyecto con detalle (como por ejemplo controlar el número de commits, incidencias, pruebas). Esto nos ha servido para comprender el funcionamiento de un proyecto en el que el código era más diferente al habitual con el que habíamos trabajado en otras asignaturas.
Por otra parte, nos quedamos con la incertidumbre de cómo hubiese sido colaborar con otro grupo ya que decidimos realizar íntegramente nuestro trabajo entre los miembros del equipo. Esto ha ocasionado que hayamos realizado una integración interna, con lo que el trabajo se ha llevado a cabo en un ambiente más cómodo y familiar.
En cuanto a los conflictos, cabe señalar que no se ha producido ninguno entre los miembros del equipo de trabajo, aún así, teníamos un ‘plan de resolución de conflictos’, pero no hemos tenido que recurrir a él; esto sumado al conocimiento que teníamos de GitHub, ha facilitado, de gran forma, nuestra organización.
Además, en las reuniones ha habido buena comunicación, iniciativa, respeto y ganas de aprender por parte de todo el equipo. Implicación general en las tareas, en las que siempre se ha mostrado interés en estar al día con las últimas modificaciones del proyecto. Nos gustaría recalcar la puntualidad a la hora de asistir a las reuniones establecidas por el equipo de proyecto. Aunque ha habido alguna ausencia por causas justificadas, todos los miembros han asistido a las reuniones realizadas.
Por último, añadir el compromiso e interés común en mejorar el proyecto; los integrantes del equipo han dedicado su tiempo y esfuerzo a la hora de identificar las incidencias del proyecto y ayudar a sus compañeros cuando la situación lo requería.
Con respecto al trabajo futuro, las mejoras que proponemos aa realizar para otros grupos en posteriores cursos serían las siguientes:
- Cerrar la subida de evidencias de forma instantánea: Sería de ayuda que un profesor pudiese cerrar el periodo en el que los estudiantes suben sus evidencias sin tener en cuenta su fecha límite; siempre que esta acción esté debidamente justificada.
- Exportar evidencias en PDF: Evidentia permite exportar las evidencias de los alumnos en formato Excel, podría añadirse la funcionalidad de exportar esas evidencias en otros formatos como PDF o incluso Word, para que el usuario elija su opción más oportuna.
- Implementación de un sistema de notificaciones: Otra funcionalidad interesante, la cual no está implementada en Evidentia, sería un sistema de notificaciones que informe al alumno si la evidencia realizada es correcta o ha sido rechazada.
Aunque un poco extensa, esperamos que la documentación añadida a este proyecto haya sido informativa y cómoda de leer.