Diferencia entre revisiones de «Despliegue de proyectos»

De Wiki de EGC
Saltar a: navegación, buscar
Línea 35: Línea 35:
  
 
Observe en el <code>maven-metadata.xml</code> que ''release'' es la última versión actualizada que no es de desarrollo. ''lastUpdate'' es la ultima actualización, ya sea de desarrollo o no.
 
Observe en el <code>maven-metadata.xml</code> que ''release'' es la última versión actualizada que no es de desarrollo. ''lastUpdate'' es la ultima actualización, ya sea de desarrollo o no.
 +
 +
= Gestión de versiones =
 +
 +
En Maven, cuando la versión de un proyecto termina en <code>-SNAPSHOT</code> indica que esa versión aún está en desarrollo activo. Por ejemplo, un proyecto cuya versión sea <code>1.0-SNAPSHOT</code> indica que sus desarrolladores están trabajando en la versión <code>1.0</code>, pero aún no la han terminado. Esto tiene otra implicación adicional: cuando estemos desarrollando, debemos evitar añadir versiones <code>-SNAPSHOT</code> como dependencia pues están en pleno desarrollo. Lo habitual es que esas dependencias sólo se encuentren en proyectos que se están desarrollando en paralelo.
 +
 +
Cuando el equipo de desarrollo decide que es hora de sacar la versión <code>1.0</code> el proceso que se suele seguir es el siguiente:
 +
 +
# Comprobar que no hay dependencias a versiones SNAPSHOT.
 +
# Cambiar la versión del POM de x-SNAPSHOT a una nueva versión (lo ideal es utilizar [https://semver.org versionado semántico].
 +
# Ejecutar los tests con el POM modificado para comprobar que todo está funcionando correctamente.
 +
# Hacer commit de los POMs modificados
 +
# Etiquetar el código en el sistema de control de versiones con el nombre de la versión. En git se puede hacer por medio del comando <code>git tag <tagName></code>
 +
# Desplegar el proyecto con <code>mvn deploy</code>
 +
 +
Una vez desplegado el proyecto, lo normal es que queramos empezar a desarrollar la nueva versión de nuestra aplicación. Para ello, no hay que olvidar:
 +
 +
# Subir la versión del proyecto en el POM a y-SNAPSHOT.
 +
# Hacer commit del POM modificado.
 +
 +
Estos pasos se pueden hacer manualmente, aunque existe un plugin de maven especialmente diseñado para la gestión de versiones llamado [http://maven.apache.org/maven-release/maven-release-plugin/index.html maven-release-plugin].
 +
 +
'''Ejercicio:''' Sigue manualmente o con la ayuda del maven-release-plugin el proceso descrito anteriormente para hacer el release de la versión 1.0 y pasar a desarrollar la 1.1.
 +
  
 
= Uso de un repositorio remoto =
 
= Uso de un repositorio remoto =

Revisión del 00:23 4 dic 2017

Desplegar un proyecto significa enviar tu artefacto a un lugar (repositorio) para ser compartido con otros. Se establecerá un repositorio para esto.

Desplegar el proyecto y observar el resultado

mvn deploy

Especificar un lugar para los despliegues

Añada al pom.xml la configuarción para que los despliegues vayan a una carpeta de su equipo:

<distributionManagement>
    <repository>
      <id> idRepo</id>
      <name> nombreRepo</name>
      <url> file://ruta_carpeta_despliegue </url>
    </repository>
</distributionManagement>

Vuelva a desplegar

Analice el contenido

Vaya a la carpeta de despliegue y observe su contenido.

Actualize el proyecto

Abra el pom.xml de su proyecto y cambien la versión de éste. Vuelva a desplegar el proyecto.

Analice el contenido

Vuelva a la carpeta de despliegue y analícela de nuevo. ¿Que ocurre si..?:

  • La versión acaba en -SNAPSHOT.
  • La versión acaba en cualquier otra cosa.

Observe en el maven-metadata.xml que release es la última versión actualizada que no es de desarrollo. lastUpdate es la ultima actualización, ya sea de desarrollo o no.

Gestión de versiones

En Maven, cuando la versión de un proyecto termina en -SNAPSHOT indica que esa versión aún está en desarrollo activo. Por ejemplo, un proyecto cuya versión sea 1.0-SNAPSHOT indica que sus desarrolladores están trabajando en la versión 1.0, pero aún no la han terminado. Esto tiene otra implicación adicional: cuando estemos desarrollando, debemos evitar añadir versiones -SNAPSHOT como dependencia pues están en pleno desarrollo. Lo habitual es que esas dependencias sólo se encuentren en proyectos que se están desarrollando en paralelo.

Cuando el equipo de desarrollo decide que es hora de sacar la versión 1.0 el proceso que se suele seguir es el siguiente:

  1. Comprobar que no hay dependencias a versiones SNAPSHOT.
  2. Cambiar la versión del POM de x-SNAPSHOT a una nueva versión (lo ideal es utilizar versionado semántico.
  3. Ejecutar los tests con el POM modificado para comprobar que todo está funcionando correctamente.
  4. Hacer commit de los POMs modificados
  5. Etiquetar el código en el sistema de control de versiones con el nombre de la versión. En git se puede hacer por medio del comando git tag <tagName>
  6. Desplegar el proyecto con mvn deploy

Una vez desplegado el proyecto, lo normal es que queramos empezar a desarrollar la nueva versión de nuestra aplicación. Para ello, no hay que olvidar:

  1. Subir la versión del proyecto en el POM a y-SNAPSHOT.
  2. Hacer commit del POM modificado.

Estos pasos se pueden hacer manualmente, aunque existe un plugin de maven especialmente diseñado para la gestión de versiones llamado maven-release-plugin.

Ejercicio: Sigue manualmente o con la ayuda del maven-release-plugin el proceso descrito anteriormente para hacer el release de la versión 1.0 y pasar a desarrollar la 1.1.


Uso de un repositorio remoto

En el apartado anterior hemos utilizado un repositorio local donde desplegar nuestros JAR, pero eso resulta de poca utilidad si queremos compartirlos con otros desarrolladores. Lo habitual es utilizar repositorios remotos. Si estás desarrollando un proyecto open source lo usual es que se utilice Maven Central, pero para otro tipo de proyectos o para ejemplos como el que estamos haciendo debemos utilizar otros repositorios. Si no, estaríamos incurriendo en un mal uso de Maven Central.

Por suerte, hay otros repositorios remotos disponibles de Maven y, algunos de ellos, tienen una versión gratuita para probar como es el caso de http://mymavenrepo.com.

  1. Entrar en http://mymavenrepo.com y crear una cuenta
  2. Sigue las instrucciones para configurar tu pom.xml para tu repositorio. Fíjate que la configuración es muy similar a la que hemos hecho antes. La diferencia más significativa es que en las instrucciones de mymavenrepo te recomiendan poner las URL en un fichero settings.xml para evitar que queden públicas en el pom.xml y cualquiera pueda acceder a ellas.
  3. Haz un mvn deploy y observa el resultado.