Diferencia entre revisiones de «Despliegue de proyectos»
(No se muestra una edición intermedia de otro usuario) | |||
Línea 25: | Línea 25: | ||
Vaya a la carpeta de despliegue y observe su contenido. | Vaya a la carpeta de despliegue y observe su contenido. | ||
− | = | + | = Actualice el proyecto= |
Abra el pom.xml de su proyecto y cambien la versión de éste. Vuelva a desplegar el proyecto. | Abra el pom.xml de su proyecto y cambien la versión de éste. Vuelva a desplegar el proyecto. | ||
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 actual del 16:49 14 dic 2017
Desplegar un proyecto significa enviar tu artefacto a un lugar (repositorio) para ser compartido con otros. Se establecerá un repositorio para esto.
Contenido
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.
Actualice 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:
- 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 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
git tag <tagName>
- 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:
- 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 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.
- Entrar en http://mymavenrepo.com y crear una cuenta
- 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.
- Haz un
mvn deploy
y observa el resultado.