En esta sección se tratan todos los aspectos relacionados con el sistema de control de librerías o artefactos utilizado como parte del entorno de entrega o recepción del software.
Entre otros, se describe el procedimiento para la solicitud de actualización de artifactory en el caso de entregas de software basadas en maven.
Para conocer la URL de acceso al Repositorio de Artefactos de MADEJA consultar el recurso " Repositorio de Artefactos de MADEJA"
Código | Título | Carácter |
---|---|---|
PROC-0013 | Procedimiento Solicitud de Actualización de Artifactory | Recomendado |
Código | Título | Tipo | Carácter |
---|---|---|---|
RECU-0520 | Repositorio de Artefactos de MADEJA | Herramienta | Obligatorio |
RECU-0319 | Plantilla Solicitud de Actualización del Artifactory | Plantilla | Recomendado |
RECU-0327 | Artifactory | Manual | Recomendado |
RECU-0329 | Arquitectura del repositorio de librerías MADEJA | Ficha Técnica | Recomendado |
RECU-0018 | Despliegue de artefactos en Artifactory desde Hudson | Ficha | Recomendado |
Antes de realizar una entrega software, se debe asegurar la total autonomía de la compilación de la entrega, quedando resueltas todas las posibles dependencias de librerías propias o ajenas a través del uso del repositorio de artefactos corporativo.
Por lo tanto, el Jefe de Proyecto ha de asegurarse que las dependencias están resueltas en el repositorio de artefactos antes de formalizar la entrega. En caso contrario deberá comunicar con carácter previo la necesidad de publicación de librerías haciendo uso del procedimiento 'Solicitud de actualización del repositorio de artefactos' publicado en MADEJA.
Código | Título | Carácter |
---|---|---|
PROC-0013 | Procedimiento Solicitud de Actualización de Artifactory | Recomendado |
Código | Título | Tipo | Carácter |
---|---|---|---|
RECU-0319 | Plantilla Solicitud de Actualización del Artifactory | Plantilla | Recomendado |
Los proyectos desarrollados por o para la Junta de Andalucía se deben construir haciendo uso del repositorio Maven de MADEJA
Cualquier entrega de una versión de un proyecto (modelado con Maven), debe poder construirse a partir del conjunto de artefactos disponible en el repositorio de MADEJA.
Se recomienda que durante la fase de desarrollo del proyecto, se configure el repositorio MADEJA en el fichero setting.xml de la instalación de maven de la siguiente manera:
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<mirrors>
<mirror>
<id>ja-external</id>
<mirrorOf>*</mirrorOf>
<name>MADEJA Maven2 Repository</name>
<url>http://www.juntadeandalucia.es/madeja/repositoriodelibrerias/ja-external</url>
</mirror>
</mirrors>
</settings>
En el caso de que el proveedor tenga acceso a la red corporativa de la Junta, puede configurar la url interna del Repositorio de Librerías, que tienen los mismos artefactos y además aquellos que por su licencia no se pueden publicar en internet.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<mirrors>
<mirror>
<id>ja-external</id>
<mirrorOf>*</mirrorOf>
<name>MADEJA Maven2 Repository</name>
<url>http://repositorio-librerias.i-administracion.junta-andalucia.es/artifactory/ja-internal/</url>
</mirror>
</mirrors>
</settings>
Código | Título | Tipo | Carácter |
---|---|---|---|
RECU-0127 | Arquetipo JSF con Richfaces | Arquetipo Software | Recomendado |
Los proyectos desarrollados por o para la Junta de Andalucía deben mantener el mismo criterio a la hora de definir la coordenada groupId en sus ficheros pom.xml
Para aquellos proyectos que se desarrollen por o para la Junta de Andalucía se recomienda seguir un criterio a la hora de asignar el "groupId" de un proyecto, que permita unificar y agrupar el conjunto de proyectos desarrollados en el seno de la Junta de Andalucía.
En caso de tratarse de un proyecto horizontal, se recomienda usar las siguientes coordenadas(fragmento de pom.xml):
<groupId>es.juntadeandalucia.PROYECTO</groupId>
En caso de tratarse de un proyecto vertical responsabilidad de una Consejería u Órgano, se recomienda usar las siguientes coordenadas(fragmento de pom.xml):
<groupId>es.juntadeandalucia.ORGANO.PROYECTO</groupId>
Se recomienda el uso del plugin maven-enforcer-plugin para dejar constancia de las restricciones relativas al entorno de desarrollo de un proyecto determinado. El plugin Enforcer proporciona medios para controlar algunas restricciones relativas al proyecto como la versión de Maven, la versión del JDK, así como un conjunto de reglas standard.
Se pueden definir algunas restricciones como:
De esta manera, haciendo uso de este plugin se ayuda a mantener la reproducibilidad de los proyectos en cualquier otro entorno. En el siguiente ejemplo se fuerza a:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>2.2.1</version>
</requireMavenVersion>
<requireJavaVersion>
<version>1.5</version>
</requireJavaVersion>
<requireOS>
<family>unix</family>
</requireOS>
<requireReleaseVersion>
<message>No se permite una versión Snapshot</message>
</requireReleaseVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
Para la adecuada gestión de las dependencias de un proyecto maven y evitar problemas en el empaquetamiento del software que se entrega, se deben seguir las recomendaciones que aquí se incluyen.
La gestión de las dependencias y sus versiones es una de las problemáticas más complejas de la entrega de un código fuente con maven. Para el correcto control las dependencias del software que se entrega y para que sea fácilmente publicable y reutilizable en el futuro hay que cumplir las siguientes pautas.
Si durante el desarrollo de un proyecto se ha configurado el repositorio de librerías de MADEJA como única fuente de artefactos quiere decir que a lo largo del desarrollo del proyecto se han realizado las oportunas peticiones de actualización del repositorio desde el procedimiento definido para tal propósito. Si esto es así no será necesario entregar ninguna dependencia puesto que ya estarán todas en el repositorio MADEJA.
En caso que se haya utilizado otros repositorios aparte, habrá que identificar ese conjunto de librerías que se aportan desde otros repositorios y solicitar una petición de actualización del repositorio de MADEJA tal y como indica el procedimiento.
Muchos organismos disponen de un repositorio maven propio para la recepción de sus entregas. En este caso, los proyectos deben solicitar la actualización de las librerías que necesiten al responsable del repositorio de librerías de dicho Organismo. Se recomienda a estos organismos que proporcionen un procedimiento de actualización similar al que se ha mencionado antes para el repositorio de MADEJA.
Si desde una Consejería se desea publicar una dependencia en el repositorio de MADEJA, se proporciona un mecanismo más ágil que el procedimiento definido para actualizar el repositorio.
Este método sólo aplica para aquellas dependencias creadas para la Junta de Andalucía cuyo "groupId" sea es.juntadeandalucia.[ORGANISMO]. O las que excepcionalmente la Consejería indique cumpliendo un determinado patrón de inclusión, por ejemplo "ceic/**" (Se entiende que son librerías que aún no se han adaptado a la nueva nomenclatura).
MADEJA recomienda a las distintas Consejerías crear un repositorio dedicado exclusivamente a publicar el conjunto de artefactos candidatos a ser publicados en el repositorio MADEJA. Una vez creado el repositorio, se seguirán los siguientes pasos:
Las dependencias deben tener versionado.
Las dependencias deberán también tener versionado, para que se puedan gestionar adecuadamente y poder comprobar si ya existe en el repositorio de librerías de la Consejería u Organismo o en el de MADEJA, si debe ser desplegada. Por ejemplo: spring-beans-1.2.8.jar
En todo caso, habrá que indicar el origen de la dependencia tal y como recoge la pauta "Indicar las fuentes o repositorios de las dependencias" un poco más abajo
Cabe destacar que la política de versionado de una dependencia es la suya propia, y que la que propone MADEJA está dirigida a los desarrollos hechos por y para la Junta de Andalucía.
No se deben definir intervalos de versiones en las dependencias del pom.xml.
Por ejemplo: <version>[1.1.15,1.2.0)</version>
Esta practica en fase en un entorno de desarrollo puede ser muy útil para cambiar una librería por otra con una versión compatibles, pero en una entrega para una Consejería u Organismo puede ser una complicación más a la hora de que el personal técnico pueda saber qué librerías tenía la entrega asociada en su momento. En el pom.xml de una entrega de software el proveedor debe evitar el uso de intervalos y hacer referencia a un número de versión fija.
Si alguna de las dependencias del proyecto es a su vez un nuevo desarrollo se deberán entregar sus fuentes completos con su pom.xml.
Las dependencias que aparecen en el pom.xml de un desarrollo que usa maven tienen a su vez su propio xml, donde exponen sus dependencias con otros componentes. Si no se ha indicado el repositorio remoto (apache, jboss, etc...) del que se pueden obtener tanto la dependencia como su xml, porque la dependencia no esta pública en ningun repositorio conocido, será necesario desplegarla a mano. En este caso se debe entregar también el xml asociado a la dependencia, para que cuando se genere el paquete del software se puedan localizar las dependencias transitivas que puedan exisitir.
Para toda dependencia que se instale en el repositorio de librerías se debe indicar la fuente o repositorio de donde procede, ya que debe ser "localizable" en Internet.
Toda dependencia candidata a ser instalada en el repositorio de librerías, tiene que ser "localizable" en Internet bien vía un repositorio de librerías maven que la distribuya, o bien mediante descarga desde la página web del desarrollador original de la misma. De esta manera se pretende proteger la integridad de las versiones de todos los artefactos.
Si en el desarrollo se han usado dependencias que no se encuentren en el repositorio de librerías MADEJA, habrá que solicitar una petición de actualización del repositorio indicando la "localización" de la dependencia.
Se deben excluir las dependencias transitivas que no sean necesarias
Es habitual que al incluir una nueva dependencia en el fichero pom.xml, no se caiga en la cuenta de preguntarse por las dependencias transitivas que se están incluyendo. En ocasiones estas dependencias transitivas no son necesarias que se incluyan, bien porque no se hará uso de ellas en tiempo de ejecución o bien porque ya fueron incluidas explícitamente en el pom.xml o por alguna otra dependencia.
Por ello es buena práctica tener en cuenta estas dependencias transitivas y excluirlas siempre que se sepa que no son necesarias. Por ejemplo, si en un proyecto se deseará acceder a un directorio LDAP se podría hacer uso de la librería spring-ldap, sin perjucio de descargar también spring-core o spring-beans
<dependency>
<groupId>org.springframework.ldap</groupId>
<artifactId>spring-ldap</artifactId>
<version>1.2.1</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
</exclusions>
</dependency>
El atributo scope se utiliza para limitar la "transitividad" de una dependencia, afectando de manera directa sobre el classpath utilizado para según que tarea.
Si el uso de una dependencia determinada sólo tiene sentido en las pruebas unitarias, no tiene sentido que se incluya en el war deplegable en el servidor de aplicaciones. Si para la realización de las pruebas unitarias se utiliza la librería testng y commons-httpclient se indicará de la siguiente manera:
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.7</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
<scope>test</scope>
</dependency>
Se puede obtener más información acerca de este tema en la página oficial de maven
Para aquellos artefactos desarrollados y/o mantenidos bajo el paraguas de la Junta de Andalucía, en ningún caso se admitirá el despliegue de una versión SNAPSHOT.
El uso de versiones SNAPSHOT está exclusivamente orientado a entornos de desarrollo y en este contexto no tiene sentido si lo que se va a realizar es una entrega de una versión.
Es recomendable añadir el Repositorio de Artefactos de MADEJA, como fuente en el repositorio de artefactos local que tenga una Consejería u Organismo. Para poder disponer de cualquier librería se ponga en común.
A la hora de añadir el Repositorio de Artefactos de MADEJA al de la Consejería u Organismo que lo desee existen dos opciones
Aquellos Organismos y Consejerías que deseen publicar en el Catálogo de Software, deberán asegurar la correcta compilación de los fuentes contra el Repositorio de Artefactos Corporativo de la Junta de Andalucía.
Existen dos mecanismos para que una Consejería u otro Organismos de la Junta de Andalucía aporte librerías al Repositorio de Artefactos de MADEJA.
Las Consejerías u Organismos que publiquen su repositorio de artefactos, para que sea leido por el de MADEJA, no deben publicar artefactos originados en proyectos impulsados desde otra Consejería.
Una Consejería u Organismo que publique su repositorio de artefactos para que sea leido por el de MADEJA, e incluso si es leido solo por desarrolladores, no debería publicar artefactos generados en proyectos impulsados desde otra Consejería. De hecho es recomendable que ni siquiera se suban a mano a su repositorio, si pueden ser obtenidos ya del repositorio de la Consejería que los impulsa.
Para el correcto funcionamiento y gestión del repositorio de librerías es conveniente seguir una serie de recomendaciones y/o buenas prácticas en la administración del mismo.
Existen un conjunto de recomendaciones que es conveniente seguir para dar solución a las diferentes problemáticas que se pueden dar durante el día a día en la administración de un repositorio de librerías. Aunque este libro de pautas se ha redactado para la administración interna del repositorio de librerías de MADEJA, puede ser de ayuda para cualquier repositorio de librerías existente en la Junta de Andalucía.
Título | Carácter |
---|---|
Artefactos free y non-free | Recomendada |
Artefactos de la Junta de Andalucía | Recomendada |
Localización de artefactos | Recomendada |
Redirección de artefactos | Recomendada |
Inclusión de un repositorio remoto de otra Consejería | Recomendada |
Repositorio virtual por defecto "repo" en Artifactory | Recomendada |
Se debe examinar la licencia del artefacto a desplegar, de forma que los artefactos free (libre distribución) se desplieguen en un repositorio distinto a los non-free (no permite distribución)
Dentro del conjunto de artefactos que hay que desplegar manualmente en el repositorio Artifactory, se distingue entre aquello cuya licencia permite su libre distribución y aquellos que no la permiten.
Dado el caso de tener que desplegar un artefacto, habrá que mirar en su licencia si permite la libre distribución. Si permite la libre distribución el artefacto se desplegará en el repositorio ja-free-repo, en otro caso el artefacto se desplegará en ja-non-free-repo.
De esta manera, a la hora de publicar el repositorio en Internet, bastará con excluir el repositorio ja-non-free-repo; y de esta manera no se incurrirá en una violación de licencia.
Aquellos artefactos que son desarrollados bajo el paraguas de la Junta de Andalucia, se desplegarán en el repositorio ja-artifacts-deploy. Este repositorio obliga a todo artefacto a contener el groupId es.juntadeandalucia.
Para localizar un artefacto, se recomienda utilizar las herramientas y mecanismos que a continuación se describen
El proceso de localizar un artefacto definido en un fichero pom no es exacto al 100%, sin embargo se puede hacer uso de algunas herramientas que nos ayuden en nuestro propósito:
En caso de no encontrar nuestro artefacto haciendo uso de las herramientas anteriores, posiblemente dicho artefacto se distribuirá como una descarga desde la página web del fabricante. Se descargará el artefacto desde la página web del fabricante, y se desplegará el artefacto según lo definido en el apartado Artefactos free y non-free.
En caso de detectar un defecto en las coordenadas de una dependencia, se utilizará el concepto de relocalización de artefactos que tiene Maven para redirigir las coordenadas incorrectas de una dependencia a las coordenadas correctas.
En caso de detectar un defecto en las coordenadas de una dependencia, hay ocasiones en las que no es factible solicitar al proveedor modificar las coordenadas que están mal. Lo primero que hay que hacer en este caso es localizar la dependencia con las coordenadas correctas. Una vez localizada se utilizará el concepto de relocalización de artefactos que tiene Maven, de esta manera se podrán redirigir las coordenadas incorrectas de una dependencia a las coordenadas correctas.
El proceso sería el siguiente:
Se parte de la base que la dependencia con las coordenadas correctas ya está subida en el repositorio. Caso que no estuviese bien ubicada es lo primero que tendríamos que hacer. En este caso la dependencia con las coordenadas correctas, no habría que desplegarlo puesto que ya está en el repositorio oficial de Maven
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.1</version>
</dependency>
Cada vez que se encuentre algún pom que incluya la dependencia xmlsec-1.4.1 de manera incorrecta se actuará de la siguiente manera. Por ejemplo, en un proyecto se definela dependencia de la siguiente manera:
<dependency>
<groupId>apache</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.1</version>
</dependency>
Se creará un fichero pom.xml con la siguiente estructura:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>apache</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.1</version>
<distributionManagement>
<relocation>
<groupId>org.apache.santuario</groupId>
</relocation>
</distributionManagement>
</project>
En este caso sólo se redefine la coordenada groupId, aunque podrían redefinirse cualquier otra.
En caso que haya que incluir un nuevo repositorio remoto de una Consejería
En caso que haya que incluir un nuevo repositorio remoto de una Consejería, habrá que realizar lo siguiente desde las pantallas de administración de la interfaz web:
Con estos dos pasos, cualquier artefacto desplegado en el repositorio remoto de la Consejería, será accesible desde nuestro repositorio de librerías.
Se recomienda deshabilitar el repositorio virtual por defecto "repo" en Artifactory
Por defecto Artifactory publica un repositorio virtual denominado "repo", que agrupa el conjunto de todos los repositorios configurados. En algunas ocasiones este comportamiento no es el deseado, ya que podría interesar no publicar algún repositorio.
Para subsanar este problema, se recomienda realizar los siguientes pasos en la interfaz de administración de Artifactory:
Sobre el System Export que se acaba de realizar, modificar el archivo artifactory-config.xml incluyendo un nuevo repositorio virtual:
...
<virtualRepository>
<key>repo</key>
<description></description>
<type>maven2</type>
<includesPattern>**/*</includesPattern>
<artifactoryRequestsCanRetrieveRemoteArtifacts>false</artifactoryRequestsCanRetrieveRemoteArtifacts>
<repositories/>
<pomRepositoryReferencesCleanupPolicy>discard_active_reference</pomRepositoryReferencesCleanupPolicy>
</virtualRepository>
...
Identificar artefactos cuya licencia no permita su distribución libre y desplegarlos en un repositorio "non-free" que no sea visible desde fuera de la intranet de la Junta de Andalucía.
Existe un procedimiento para dar de alta en el repositorios artefactos necesarios para la construcción de nuevos proyectos. En dicho procedimiento se muestra el caso en el que hay que desplegar un nuevo artefacto manualmente.
En el caso de tener que desplegar un artefacto manualmente en nuestro repositorio de librerías (puede ser el de MADEJA o el de una Consejería en concreto), es importante identificar qué licencia tiene el artefacto y cual sería su destino final.
En caso que el artefacto empezara sus coordenadas maven por "es.juntadeandalucia.*" no habría nínguna duda, y el repositorio destino sería "ja-artifacts-deploy". El problema surge cuando el artefacto ha sido desarrollado por terceras partes. En tal caso los dos repositorios destinos posibles serían "ja-free-repo" o "ja-non-free-repo". Para resolver esta disyuntiva, hay que identificar la licencia del artefacto que se quiere desplegar. Si la licencia del artefacto permite su distribución, entonces el repositorio destino será "ja-free-repo". En caso que la licencia no permita su distribución, el repositorio destino será "ja-non-free-repo".
Esto se considera así ya que el repositorio de librerías MADEJA tiene dos vertientes, una de cara a la intranet de la Junta de Andalucía (donde no habría problemas para distribuir de manera interna librerías "non-free"), y otra de carácter público (donde se podría incurrir en una violación de la licencia) en Internet. El repositorio "non-free" podrá ser utilizado dentro de la intranet de la Junta de Andalucía, pero sin embargo no podrá ser utilizado desde Internet. Si alguna Consejería publica su repositorio en internet también debería de seguir esta directriz.
Dado el caso, la persona que quisiera construir el proyecto tendrá que descargarse los diferentes artefactos de las correspondientes páginas del fabricante. En su defecto, se podrá publicar en el repositorio "free-repo", un fichero pom.xml con las mismas coordenadas indicando la dirección donde se puede encontrar dicho artefacto. Por ejemplo:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.0.2</version>
<name>JavaBeans Activation Framework (JAF)</name>
<description>
JavaBeans Activation Framework (JAF) is a standard extension to the Java platform that lets you take advantage of standard services to: determine the type of an arbitrary piece of data; encapsulate access to it; discover the operations available on it; and instantiate the appropriate bean to perform the operation(s).
</description>
<url>
http://java.sun.com/products/javabeans/jaf/index.jsp
</url>
<distributionManagement>
<downloadUrl>http://java.sun.com/products/javabeans/glasgow/jaf.html</downloadUrl>
</distributionManagement>
</project>
El procedimiento Solicitud de Actualización de Artifactory tiene como objetivo llevar a cabo la inclusión en el Artifactory de las librerías necesarias para la correcta compilación de los fuentes entregados, asegurando que no se requieren dependencias locales. En este sentido, TODAS las librerías propias o externas necesarias en algunos de los proyectos Maven deberán estar publicadas en el repositorio de liberías de la Consejería u Organismo.
Se trata de un procedimiento genérico de actualización de Artifactory que es extensible a cualquiera de las Consejerías u Organismos para la gestión de su artifactory interno. Las Consejerías que para la publicación en el Catálogo de Software de algunas de sus aplicaciones, requieran la actualización del Artifactory corporativo de la Junta de Andalucía, deberán registrar un petición de actualización de Artifactory en la herramienta de gestión del servicio (NAOS).
Título |
SOP.SAA.01. Análisis de librerías necesarias
|
Descripción | Como paso previo a la entrega software, el Equipo de Proyecto deberá asegurar la correcta compilación de los fuentes contra el repositorio de librerías de la Consejería. Es por ello que deberá solicitar la actualización del Artifactory con las librerías que estime necesarias (propias o de terceros). |
Tareas |
|
Responsable | Equipo de Proyecto |
Productos |
|
Título |
SOP.SAA.02. Registro de petición de actualización del Artifactory
|
Descripción | Si el Equipo de Proyecto necesita incluir alguna librería en el Artifactory, deberá registrar una petición en la herramienta de gestión del servicio. En esta petición se deberá indicar el número de librerías a incorporar, así como si la librería es externa o propia. |
Tareas |
|
Responsable | Equipo de Proyecto |
Productos |
|
Título |
PSOP.SAA.03. Incorporación del fuente de la librería en el sistema de gestión de versiones
|
Descripción | Si alguna de las librerías necesarias a incluir en el Artifactory es propia del desarrollo, el Equipo de Proyecto deberá incluir el código fuente de la misma en el sistema de gestión de versiones |
Tareas |
|
Responsable | Equipo de Proyecto |
Productos |
|
Título |
SOP.SAA.04. Definición URL del repositorio público
|
Descripción | Si algunas de las librerías necesarias a incluir en el Artifactory no es propia del desarrollo, pero están publicadas en algún repositorio maven remoto, el Equipo de Proyecto deberá proveer la URL de dicho repositorio remoto en la que se encuentran las librerías necesarias para el proceso de construcción. |
Tareas |
|
Responsable | Equipo de Proyecto |
Productos |
|
Título |
SOP.SAA.05. Definición URL de la versión correcta de la librería
|
Descripción | Si algunas de las librerías necesarias a incluir en el Artifactory no es propia del desarrollo, y además no está publicada en ningún repositorio maven remoto, el Equipo de Proyecto deberá proveer la URL de descarga de la fuente original en la que conseguir la librería necesaria para el proceso de construcción. |
Tareas |
|
Responsable | Equipo de Proyecto |
Productos |
|
Título |
SOP.SAA.06. Revisión y validación de la petición de actualización
|
Descripción | El Administrador del Artifactory deberá revisar y validar la petición de actualización del Artifactory. Para ello deberá comprobar en primer lugar, si las nuevas librerías necesarias a incluir no se encuentran ya disponibles en el repositorio, en cuyo caso desestimará la petición. |
Tareas |
|
Responsable | Administrador del Artifactory |
Productos |
|
Título |
SOP.SAA.07. Construcción de la librería y despliegue en Artifactory
|
Descripción | Una vez se dispone de todos los datos necesarios para la construcción de la librería propia, el Administrador del Artifactory accederá al sistema de gestión de versiones y comprobará su correcta compilación y lo desplegará en el repositorio Artifactory. |
Tareas |
|
Responsable | Administrador del Artifactory |
Productos |
|
Título |
SOP.SAA.08. Alta repositorio remoto e incorporación al repositorio proxy
|
Descripción | Una vez se dispone de la URL del repositorio de librerías, el Administrador de Artifactory lo dará de alta como repositorio remoto, y lo configurará convenientemente incluyéndolo como proxy. |
Tareas |
|
Responsable | Administrador del Artifactory |
Productos |
|
Título |
SOP.SAA.09. Obtención de la librería y despliegue en Artifactory
|
Descripción | Una vez se dispone de la URL de descarga de la librería, el Administrador de Artifactory descargará la librería correspondiente y la desplegará manualmente en Artifactory con las coordenadas correctas. |
Tareas |
|
Responsable | Administrador del Artifactory |
Productos |
|
Código | Título | Tipo | Carácter |
---|---|---|---|
RECU-0319 | Plantilla Solicitud de Actualización del Artifactory | Plantilla | Recomendado |
Artifactory es un Repositorio de Maven. En el se pueden desplegar las dependencias que necesiten los proyectos en maven para su ciclo de vida. Otra de las principales funciones de artifactory es hacer de proxy cache de un repositorio propio con otros existentes. Esta basado en JCR (usando JackRabbit como implementación) para guardar los artefactos y administración de los metadatos (xml). Tiene una GUI basada en wicket y usa jetty para una implementación rápida (también se puede implementar sobre Tomcat).
A continuación vamos a enumerar las principales característica de Artifactory.
Según la documentación de Artifactory, los requisitos son los siguientes:
Para establecer el tamaño mínimo y máximo de memoria que Java utilizará, se ejecutará el siguiente comando:
java -XmsTamañoMinimo -XmxTamañoMáximo
Como ya hemos comentado en las características de Artifactory, este se puede ejecutar en modo standalone con una instancia dedicada de Tomcat o bien realizar un despliegue bajo Tomcat a partir del WAR. Recordemos que la opción de ejecutar Artifactory desde un servidor embebido por defecto no es la opción más recomendable para entornos productivos.
Tanto para la instalación en Tomcat dedicado como para la versión de despliegue desde WAR utilizaremos la versión 5.5 o superior.
En el apartado "Instalación y Modo de empleo" veremos como realizar ambas instalaciones
En caso de que se desee emplear Maven3, es necesario modificar la configuración de metadatos de Artifactory para que no se publiquen “snapshots” no únicos. Para ello, en el fichero artifactory.config.xml, modificar el valor de <maxUniqueSnapshots> para que valga 1.
A continuación vamos a proceder a detallar los pasos que se han de seguir para instalar Artifactory.
Para realizar este procedimiento de instalación, nos hemos basado en la versión de 2.2.5 y Tomcat 5.5.27, corriendo sobre S.O. Debian 5.0.2 Lenny. En este apartado se comentarán dos posible métodos para instalar la herramienta Artifactory. En ambos casos estos dos primeros pasos son comunes.
Si no se ha cambiado la configuración por defecto, Artifactory estará disponible en el puerto 8081 de la instancia de Tomcat.
Incluir en el fichero $ARTIFACTORY_HOME/etc/artifactory.system.properties la siguiente propiedad:
artifactory.jcr.configDir=repo/filesystem-mysql
Artifactory reconoce limitaciones a la hora de configurar la aplicación en alta disponibilidad. La solución que proponen en este sentido es una configuración en modo activo/pasivo. Esta configuración dispone de dos instancias de Artifactory compartirán una misma base de datos al mismo tiempo. Según la documentación oficial, en la versión actual no es posible otro tipo de configuración.
Una vez instalada la aplicación, podremos acceder a la aplicación web vía http://server:8081/artifactory. La primera vez que iniciamos sesión con Artifactory, utilizaremos como nombre de usuario “admin” y contraseña “password”.
Es recomendable cambiar la contraseña en la primera entrada. En el menú de la izquierda, Security / Users, editamos el usuario admin y le cambiamos la contraseña.
También es recomendable la creación de otros usuarios, por ejemplo se podría crear el usuario "hudson" sin permisos de administración pero que pueda desplegar dependencias.
La estructura del repositorio tiene un enfoque orientado al proceso de entregas software y no orientado al desarrollo software basado en SNAPSHOTS. De esta manera, la propuesta de repositorios por defecto que nos presenta Artifactory no satisface nuestras necesidades. Por este motivo, se procederá a eliminar los siguientes repositorios que vienen preconfigurados en Artifactory:
Repositorios locales | Repositorios virtuales |
---|---|
libs-releases-local | remote-repos |
libs-snapshots-local | lib-releases |
plugin-releases-local | plugin-releases |
plugin-snaphots-local | libs-snapshots |
ext-releases-local | ext-snapshots-local |
Una vez "logados" como administrador pulsar en la pestaña de “Admin” y seleccionar en el menú de la izquierda “Repositories”. Eliminar todos los repositorios definidos como Local Repositories y Virtual Repositories.
Será necesario crear los repositorios propuestos en la arquitectura lógica del sistema. Por este motivo, se procederá a crear los siguientes repositorios en Artifactory:
Repositorios locales | Repositorios virtuales |
---|---|
ja-free-repo | ja-proxy-repo |
ja-non-free-repo | ja-artifacts |
ja-artifacts-deploy | ja-internal |
ja-legacy |
Este repositorio será el encargado de recoger el conjunto de artefactos de libre uso que no estén disponibles en ningún repositorio maven, si y solo si esté permitida su libre distribución. Se da la posibilidad de manejar tanto “releases” como “snapshots”. En un principio no se configuran patrones de inclusión/exclusión ya que no se ha detectado la necesidad de usarlo en este caso, aunque esto no exime de la posibilidad de usarlos en caso que fuera necesario.
Este repositorio será el encargado de recoger el conjunto de artefactos de libre uso que no estén disponibles en ningún repositorio maven, pero que sin embargo no esté permitida su libre distribución. Se da la posibilidad de manejar tanto “releases” como “snapshots”. En un principio no se configuran patrones de inclusión/exclusión ya que no se ha detectado la necesidad de usarlo en este caso, aunque esto no exime de la posibilidad de usarlos en caso que fuera necesario.
Este repositorio contendrá aquellos artefactos que se generan a partir de los proyectos del repositorio MADEJA. En este caso sólo se permite incluir “releases”, y sólo se admitirán artefactos generados en la juntadeandalucia mediante el patrón “es/juntadeandalucia/**. En caso de existir más patrones que apliquen sobre proyectos generados desde la Junta de Andalucía se indicarán en este repositorio.
Este repositorio representa al grupo de repositorios proxy-caché a los repositorios publicados por terceras partes(Maven Central, etc). En caso que un determinado proyecto necesite de un artefacto publicado en un repositorio (por ejemplo las librerías de Jboss), habrá que dar de alta dicho repositorio como proxy Al crearlo se incluirán todos los repositorios remotos que trae pre-configurados Artifactory.
Una de las buenas prácticas definidas para el nuevo repositorio es la publicación de un repositorio por cada Consejería que desee publicar sus artefactos en el nuevo repositorio MADEJA. De esta manera el nuevo repositorio MADEJA creará un nuevo repositorio remoto que enlace con el repositorio de cada Consejería. De esta manera se consigue el nuevo repositorio MADEJA dispondrá en todo momento, del conjunto de artefactos publicados en las distintas Consejerías. El repositorio virtual “ja-artifacts” agrupará a todos los repositorios remotos que se han dado de alta enlazando con las distintas Consejerías. Además “ja-artifacts” incluirá el conjunto de artefactos generados a partir de los proyectos desplegados en el repositorio MADEJA (estos artefactos serían los que están almacenados en “ja-artifacts-deploy”) . El resultado final esperado sería que el repositorio “ja-artifact” contuviera todos los artefactos cuyo groupId fuera del tipo “es,juntadeandalucia”.
Este repositorio agrupará al conjunto de repositorios creados según la arquitectura lógica propuesta. De esta manera, este repositorio será el que haya que configurar en fichero de configuración Maven “settings.xml”. Este repositorio será la fachada principal del nuevo repositorio MADEJA interno. De esta manera este repositorio agrupará los repositorios “ja-free-repo”, “ja-non-free-repo”, “ja-artifacts” y “ja-proxy-repo” anteriormente definidos. No se configuran patrones de inclusión/exclusión ya que al actuar como fachada tiene como objetivo servir todos los artefactos que se desean publicar independientemente de su procedencia.
Este repositorio tiene como objetivo extender la vida de los proyectos que estaban utilizando el repositorio anterior. De esta manera este repositorio LEGACY, se configurará como proxy a MADEJA Artifactory. En función de la estructura de MADEJA Artifactory, “ja-legacy” se configurará como repositorio remoto o como repositorio virtual.
El conjunto de repositorios remotos puede variar a lo largo del tiempo. Este tipo de repositorios proporciona una de las principales ventajas de Artifactory, que es su capacidad de hacer de proxy-cache con otros repositorios. De esta forma cuando maven pida una dependencia a nuestra instalación de Artifactory y no la tenga, irá a buscarla en los repositorios remotos que tenga en su configuración, y si la encuentra se la traerá y la cacheará para el futuro.
Artifactory permite autenticarse a sus usuarios vía LDAP. Para ello, es necesario configurar convenientemente Artifactory proporcionándole los datos relativos a la ubicación del directorio LDAP, así como la estructura interna de la ramas.
En la aplicación web (autenticado como administrador) iremos a la sección Security > LDAP Settings e indicaremos que se desea configurar un directorio LDAP pulsando sobre el botón "New". Una vez en el formulario habrá que rellenarlos con los siguientes datos:
Para subir los artefactos propios, utilizaremos la interfaz web para subir el artefacto o el conjunto de artefactos (empaquetados convenientemente en zip), seleccionando en el menú de la izquierda "Deploy an artifact"
La última versión final disponible de Artifactory durante la redacción de esta página es la 2.2.5.
Entre las características principales disponibles en esta versión son:
Código | Título | Tipo | Carácter | |
---|---|---|---|---|
PAUT-0082 | Definición del entorno de entrega o recepción del software | Pauta | Directriz | Recomendada |
Código | Título | Tipo | Carácter |
---|---|---|---|
RECU-0681 | Características de Maven3 respecto a Maven2 | Referencia | Recomendado |
Con la finalidad de:
El repositorio de librerías MADEJA se organiza en base a un diseño arquitectónico cuyas principales características se pueden observar a continuación
El repositorio de librerías de MADEJA está orientada principalmente a la gestión de entregas software, más que al desarrollo propio. Por este motivo, se requiere un organización del repositorio distinta a las que viene siendo el estandar de facto orientado a releases y snapshots.
Esta ficha presenta la arquitectura del repositorio de librerías corporativo de MADEJA. Las ideas claves de la siguiente arquitectura son:
A continuación se muestra el diagrama con la arquitectura lógica del repositorio:
El repositorio MADEJA queda representado por el recuadro en rojo. El repositorio a su vez, se compone de tres grandes repositorios:
Este será el repositorio al que deben apuntar los proveedores para la construcción de los proyectos.
El nuevo repositorio interactúa con distintos elementos:
Como materialización de la arquitectura lógica, se presenta a continuación la arquitectura física. Esta información puede ampliarse con el Esquema lógico de la infraestructura de la Junta de Andalucía, incluyendo información sobre direccionamiento.
A continuación se propone dos opciones (básica y avanzada) para la implantación del repositorio. Principalmente se diferencian por el volumen de infraestructuras utilizado. Ambas opciones permitirían la instalación del sistema en condiciones satisfactorias e incluso podrían ejecutarse en 2 fases: ejecutando primero la opción básica para una rápida implantación del sistema, y posteriormente ampliar las infraestructuras para cubrir los requisitos de la opción avanzada.
En la siguiente figura se puede apreciar la propuesta de arquitectura física básica:
Esta opción tiene las siguientes ventajas e inconvenientes:
En la siguiente figura se puede apreciar la propuesta de arquitectura física avanzada:
Esta opción tiene las siguientes ventajas e inconvenientes:
A continuación se presenta la jerarquía de repositorios definidas en Artifactory en la que se identifican el tipo de repositorio creado, y como se relacionan entre ellos.
Se aprecia como tanto ja-internal como ja-external se organizan internamente prácticamente de la misma manera. La única excepción es que ja-external no integra el repositorio ja-non-free-repo para evitar problemas de licenciamiento de librerías de terceros.
En esta ficha se muestra los pasos a seguir para conseguir desplegar artefactos en Artifactory haciendo uso de la herramienta de integración continua Hudson.
En el contexto de MADEJA, Hudson se utiliza como herramienta para automatizar el proceso de construcción de un proyecto, así como su despliegue en el repositorio MADEJA.
Antes que nada, es necesario instalar en Hudson el plugin que permite integrar Artifactory. Para ello, se accederá en la Administración de Hudson > Administración de Plugins. En la pestaña "Todos los plugins" se seleccionará "Artifactory Plugin", y pulsaremos el botón Instalar
Una vez instalado el plugin de Artifactory, se creará una nueva tarea con el proyecto que queremos construir y desplegar en Artifactory.
En el apartado Acciones a ejecutar después (Post-build Actions), se marca la opción desplegar en Artifactory y se configura la ruta, credenciales con permisos para desplegar y el repositorio destino en el que se desplegará el artefacto.
De esta manera cuando lanzamos un proceso de construcción, si este finaliza con éxito se procederá a desplegar el resultado de la construcción en Artifactory en el repositorio indicado.
....
[INFO] [install:install {execution: default-install}]
[INFO] Installing /root/.hudson/jobs/AUTORIZA-domain/workspace/target/autoriza-domain-1.0.6.jar to /root/.m2/repository/es/juntadeandalucia/copt/transportes/autoriza-domain/1.0.6/autoriza-domain-1.0.6.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
{INFO] Total time: 1 minute 9 seconds
[INFO] Finished at: Tue Nov 23 12:49:16 GMT+01:00 2010
[INFO] Final Memory: 14M/28M
[INFO] ------------------------------------------------------------------------
channel stopped
Deploying artifacts to http://192.168.50.27:8080/artifactory
Deploying artifacts of module: es.juntadeandalucia.copt.transportes:autoriza-domain
Deploying artifact: http://192.168.50.27:8080/artifactory/ja-artifacts-deploy/es/juntadeanda...
Deploying artifact: http://192.168.50.27:8080/artifactory/ja-artifacts-deploy/es/juntadeanda...
Deploying build info ...
Finished: SUCCESS
Desde Artifactory se pueden consultar todos los procesos de despliegue ejecutados desde Hudson. Para ello, desde la pestaña "Artifacts", seleccionar en el menú de la izquierda la sección Builds. Aquí aparecerá un listado con todas los procesos de construcción lanzados en Hudson que ha desplegado un artefacto en Artifactory