Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gestión del software con Maven y Jenkins

10,061 views

Published on

Gestión del software con Maven y Jenkins

Published in: Software

Gestión del software con Maven y Jenkins

  1. 1.                             Gestión del Software con Maven  y Jenkins                                        Clara del Rey, 26, 4ª planta  [28002] Madrid  [+34] 902 20 25 52  hablemos@beeva.com  www.beeva.com          www.beeva.com      1 
  2. 2.       1. Hoja de Control  1.1 Control de versiones  2. Objetivo  3. Herramientas  4. Conocimientos previos  4.1 Política de versionado  4.2 Maven y Artifactory, artefactos estables y artefactos en construcción  4.3 Estructura de los proyectos en el repositorio de subversión  5. Herramienta de control de librerías y dependencias  5.1 ¿Qué es Maven?  5.2 Estructura Maven  5.3 Definición del fichero de construcción pom.xml  5.4 Construcción de un proyecto Maven  5.5 Opciones de compilación  6. Herramienta de integración continua  6.1 ¿Qué es la integración continua?  6.2 Finalidades que se persiguen en su implantación  6.3 Ventajas que se derivan de su utilización  6.4 Descripción del entorno de integración continua utilizado por Beeva  6.5 Configuraciones y utilización de Jenkins  6.6 Plugins utilizados en el entorno Jenkins  7. Generación de Releases  7.1 Procedimiento de Generación de una Release  7.2 Procedimiento de Generación de una revisión de una Release                www.beeva.com      2 
  3. 3.           1. Hoja de Control   Realizado por  Fecha  Firma  Dpto. de Arquitectura  21/10/2013    Revisado por  Fecha  Firma  Isaac Andrés Díez Bargueño      Aprobado por  Fecha  Firma          1.1 Control de versiones   Versión  Motivo del cambio  Responsable del  cambio  Fecha Cambio  v1.0  Versión inicial  Antonio Iglesias  11/10/2013  v1.1  Adición de los capítulos para  Maven y Jenkins  Rubén Martín  21/10/2013            2. Objetivo   En el presente documento se pretende analizar la problemática y plantear una solución sobre                            cómo gestionar el código fuente de los proyectos de manera que simplifique tareas como                            desplegar una cierta versión en un entorno concreto o realizar una marcha atrás de la versión                                que se ha desplegado que es particularmente importante cuando los proyectos adquieren un                          gran tamaño y hay varios entornos en los que se pueden desplegar (Desarrollo, Sandbox,                            Preproducción, Producción).    3. Herramientas   Las herramientas que vamos a usar son:  ● Eclipse IDE (con algún plugin de SVN)  ● Control de Versiones con Subversión (SVN)  ● Gestión y Construcción de Proyectos con Apache Maven  www.beeva.com      3 
  4. 4.     ● Artifactory: Repositorio de artefactos generados por Maven  ● Integración contínua con Jenkis y Maven Release Plugin para Jenkis    4. Conocimientos previos 4.1 Política de versionado   Para el versionado vamos a usar la siguiente notación:    nombreProyecto­major.minor.bugfix[.revisión]    donde:  ­ nombreProyecto: el nombre del proyecto, claro  ­ major: indica la versión principal, este número sólo cambiará cuando se añadan                          nuevas funcionalidades claves de la aplicación respecto de la versión anterior  ­ minor: indican funcionalidad menor, cambiará cuando haya cambios significativos con                      respecto a la funcionalidad existente o corrección de grandes fallos.  ­ bugfix: corrección de pequeños fallos con respecto a la versión anterior.  ­ revisión: correcciones o cambios que se hayan realizado de una versión que se haya                              liberado    4.2 Maven y Artifactory, artefactos estables y artefactos en construcción   Puesto que no es el objetivo de este documento hablar del uso de Maven, sólo haremos un                                  inciso sobre Maven para indicar el uso que haremos de las versiones estables y las versiones                                SNAPSHOT de los artefactos generados con Maven y dónde se guardan en el repositorio de                              Maven (Artifactory).    ● Versiones no definitivas (en construcción): en el pom se debe indicar que la versión se                              esta desarrollando, para ello hay que añadir el sufijo “­SNAPSHOT” a la versión en el                              pom.xml, por ejemplo:    <version>3.1.1­SNAPSHOT</version>    El tratamiento de Maven para estas versiones es diferente, por ejemplo, cuando se hace un                              deploy de una versión snapshot, siempre se añade una copia del artefacto en el repositorio, el                                nombre del artefacto se compone del artifactId + version + timestamp, con lo que para cada                                deploy se genera un objeto distinto que se guarda en la misma ruta del repositorio pero que se                                    distinguen por la hora en la que se han guardado dentro del repositorio.  Los deploys de estas versiones se realizan en el repositorio indicado en la etiqueta                            “snapshotRepository” del pom.xml, por ejemplo:  www.beeva.com      4 
  5. 5.       <snapshotRepository>    <id>repoBeeva</id>    <name>Beeva Artifactory for Snapshots</name>    <url>http://ic.bbvaglobalnet.com/artifactory/libs­snapshot­local</url>    </snapshotRepository>    Cuando se tiene una dependencia de un artefacto SNAPSHOT, maven comprueba si la copia                            que se tiene en el repositorio local es más reciente que la copia existente en el repositorio                                  remoto (artifactory) si ésta es más actual, se la bajará actualizando el repositorio local (.m2),                              con lo nos aseguramos de que siempre usamos la versión más actual.    ● Versiones definitivas (estables): en el pom se debe indicar que la versión se ha liberado                              y por lo tanto es definitiva y estable, para ello simplemente hay que quitar el sufijo                                “­SNAPSHOT” de la etiqueta versión del pom.xml, por ejemplo, si se estaba                        desarrollando la versión 3.1.1­SNAPSHOT pues sería:    <version>3.1.1</version>    El tratamiento de maven para las versiones definitivas es, en los deploys simplemente se “pisa”                              la versión que hay en el repositorio, aunque es una buena práctica configurar artifactory para                              que no permita hacer deploy de una versión existente en el repositorio (habitualmente se hace                              así), esto es así porque las versiones estables no se deben cambiar, de hecho, cuando se tiene                                  una dependencia de una versión estable, si ésta está ya presente en el repositorio local, maven                                no la bajará del repositorio remoto.    Los deploys de estas versiones se realizan en el repositorio indicado en la etiqueta                            “repository” del fichero pom.xml, por ejemplo:    <repository>  <id>repoBeeva</id>  <name>Beeva Artifactory</name>  <url>http://ic.bbvaglobalnet.com/artifactory/libs­release­local/</url>  </repository>    Otra práctica habitual es configurar artifactory para requerir autenticación a la hora de hacer                            deploy de versiones estables (releases), la configuración de la autenticación se hace en el                            fichero “settings.xml” de maven.    Se puede acceder a este fichero fácilmente desde eclipse desde:    Window > Preferences > Maven > User Settings    www.beeva.com      5 
  6. 6.     o bien abrirlo en el repositorio local de maven (por ejemplo, /home/usuario/.m2/settings.xml).    Un ejemplo de configuración para este fichero sería:    <settings 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/xsd/settings­1.0.0.xsd">  <interactiveMode>true</interactiveMode>  <usePluginRegistry>false</usePluginRegistry>  <offline>false</offline>  <servers>  <server>  <id>repoBBVAGlobalnet­snapshots</id>  <username>juanmanuel.perez</username>  <password>********</password>  </server>  <server>  <id>repoBBVAGlobalnet</id>  <username>juanmanuel.perez</username>  <password>********</password>  </server>  </servers>  </settings>    4.3 Estructura de los proyectos en el repositorio de subversión   Como base, se plantea la siguiente Estructura de los proyectos en el Repositorio de Versiones:    Proyecto_Padre  subproyecto1  trunk  tags  branches  subproyecto2  trunk  tags  branches    donde:  ­ /branches: este subdirectorio contendrá todas las ramas del proyecto, además habrá una                            rama especial, que servirá como base para generar los tags de las diferentes versiones y                              revisiones del proyecto.  ­ /trunk: este subdirectorio contendrá la línea de desarrollo principal del proyecto con el código                                www.beeva.com      6 
  7. 7.     actualizado y donde los desarrolladores hacen periódicamente los commits.  ­ /tags: este subdirectorio contendrá los diferentes tags del proyecto, entendiendo como tag al                              código congelado de una cierta versión y que se correspondrá con una release del mismo, o                                sea, una versión estable del que tenemos la certeza que no cambiará, éstas serán las que se                                  desplieguen en el entorno de producción.    La siguiente imagen muestra una situación normal en un proyecto con las herramientas  anteriores:      5. Herramienta de control de librerías y dependencias   En Beeva, como herramienta de control de librerías y gestión de dependencias, se utiliza la                              herramienta Maven.    5.1 ¿Qué es Maven?   Maven es una herramienta de construcción de código para java que permite compilar, ejecutar                            test o realizar distribuciones, capaz de tratar de forma automática las dependencias de librerías                            del proyecto.    Alguna de las ventajas que tenemos al utilizar Maven son:  www.beeva.com      7 
  8. 8.     ● Estandariza la estructura de directorios. Maven propone una estructura estándar de                      directorios, gracias a esto eliminamos la problemática de estructuras arbitrarias                    basadas en nuestro criterio.  ● Integración. Maven se integra con otras herramientas y Frameworks tales como eclipse,                        Selenium, CSV, SVN, hibernate, etc.  ● Gestión de dependencias. Maven aporta un sistema de gestión de dependencias basado                        en repositorios, lo que ayuda a reducir la duplicación de librerías requeridas durante la                            generación de un proyecto. Para ello la sugerencia de Maven es almacenar todas las                            librerías en un repositorio central. Maven usa por defecto el repositorio público ibiblio.org                          que es el repositorio que contiene los groupsID de casi todos los jar de libre distribución                                que se puedan encontrar en Internet. Adicionalmente se pueden definir repositorios                      propios de librerías internas.    5.2 Estructura Maven   Para utilizar Maven es necesario utilizar una estructura defina que se explica a continuación:    ● Proyectos Jar:    Proyecto  |­src  |_|­main  |_|_|­java  |_|_|_|­<paquetes­java>  |_|_|­resources  |_|_|_|­<ficheros­recursos>  |_|­test  |_|_|­java  |_|_|_|­<paquetes­java>  |_|_|­resources  |_|_|_|­<ficheros­recursos>  |­target    ● Proyectos War:    Proyecto  |­src  |_|­main  |_|_|­java  |_|_|_|­<paquetes­java>  |_|_|­resources  |_|_|_|­<ficheros­recursos>  www.beeva.com      8 
  9. 9.     |_|_|­webapp  |_|_|_|­<contenido­web>  |_|_|_|­WEB­INF  |_|_|_|­META­INF  |_|­test  |_|_|­java  |_|_|_|­<paquetes­java>  |_|_|­resources  |_|_|_|­<ficheros­recursos>  |­target    5.3 Definición del fichero de construcción pom.xml    Además de la estructura anteriormente explicada también es necesario definir un fichero de                          configuración “pom.xml”, POM son las siglas de "Project Object Model" (Modelo de Objetos de                            Proyecto) y contiene los detalles para la construcción de un proyecto Maven.    El “Pom.xml” es un archivo XML ubicado en la raíz del proyecto. Es un fichero de configuración                                  en donde declaramos datos sobre el proyecto, las dependencias y puglins necesarios para                          compilar un proyecto.    Un ejemplo de la configuración que tiene el fichero pom.xml tiene que contener es el siguiente:    <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/xsd/maven­4.0.0.xsd">    <modelVersion>4.0.0</modelVersion>      <!­­ The Basics ­­>    <groupId>...</groupId>    <artifactId>...</artifactId>    <version>...</version>    <packaging>...</packaging>    <dependencies>...</dependencies>    <parent>...</parent>    <dependencyManagement>...</dependencyManagement>    <modules>...</modules>    <properties>...</properties>      <!­­ Build Settings ­­>    <build>...</build>  www.beeva.com      9 
  10. 10.       <reporting>...</reporting>      <!­­ More Project Information ­­>    <name>...</name>    <description>...</description>    <url>...</url>    <inceptionYear>...</inceptionYear>    <licenses>...</licenses>    <organization>...</organization>    <developers>...</developers>    <contributors>...</contributors>      <!­­ Environment Settings ­­>    <issueManagement>...</issueManagement>    <ciManagement>...</ciManagement>    <mailingLists>...</mailingLists>    <scm>...</scm>    <prerequisites>...</prerequisites>    <repositories>...</repositories>    <pluginRepositories>...</pluginRepositories>    <distributionManagement>...</distributionManagement>    <profiles>...</profiles>  </project>    5.4 Construcción de un proyecto Maven   Aparte de la estructura anteriormente explicada Maven pone a nuestra disposición plantillas, las                          cuales son estructuras predefinidas para las diferentes tecnologías que utilicemos para                      desarrollar nuestro proyecto.    El nombre de estas plantillas dentro de la terminología Maven se denomina como “Arquetipos”.                            Existen alrededor de 300 arquetipos para diferentes tecnologías que van desde un j2ee­sample                          hasta proyectos avanzados con tecnologías no estándares.    Para obtener una lista de los diferentes arquetipos ejecutamos:    # mvn archetype:generate    Para definir un arquetipo ejecutamos:    # mvn archetype:generate ­DarchetypeGroupId=org.apache.maven.archetypes  ­DarchetypeArtifactId=maven­archetype­XXX  www.beeva.com      10 
  11. 11.       Se introducen los diferentes valores para los atributos requeridos para el proyecto:    Define value for groupId    :    XXX­XXX  Define value for artifactId :    XXX­XXX  Define value for version    :    XXX­XXX  Define value for package    :    XXX­XXX    groupId                     :    Nombre del paquete del proyecto.  artifactId    :    Nombre del proyecto.  Versión    :    Número de versión del proyecto.  Package                     :    Paquete base donde se almacena el código  fuente    5.5 Opciones de compilación   A continuación resumimos la sintaxis para utilizar Maven a la hora de construir nuestros                            proyectos:  ● mvn compile. Compila el código fuente del proyecto y  deja el resultado en target/clases.  ● mvn test. Testea la compilación del código fuente.  ● mvn valídate. Valida que el proyecto es correcto y toda la información necesaria esta                            disponible.  ● mvn Packaged. Toma el código compilado y lo empaqueta en un formato de distribución,                            como puede ser un Jar.  ● mvn install. Instala el paquete en un repositorio local, el cual puede ser utilizado como                              dependencias en otros proyectos localmente.  ● mvn clean. Elimina artefactos previamente creados por otras compilaciones.  ● mvn verify. Ejecutar cualquier check necesario para verificar si el paquete es válido y                            cuenta con los criterios definidos de calidad.  ● mvn deploy. Copia el paquete final a un repositorio remoto para poder ser compartido por                              otros.  ● mvn site. Genera archivos HTML que describen el proyecto.  ● mvn default. Genera los archivos binarios del proyecto.    www.beeva.com      11 
  12. 12.     6. Herramienta de integración continua 6.1 ¿Qué es la integración continua?   La integración continua (CI) es una metodología informática que consiste en realizar                        integraciones (o también llamadas construcciones) de un proyecto de forma automatizada y                        continua, entendiéndose por integración la compilación, ejecución de tests, generación de los                        paquetes de software e incluso el posible despliegue de todo un proyecto.    6.2 Finalidades que se persiguen en su implantación   Los propósitos principales que persigue esta metodología de desarrollo son:  ● Agilizar y facilitar la ejecución iterativa de todas las tareas relacionadas con la                          construcción de un proyecto permitiendo la automatización y planificación de las                      mismas.  ● Anticipar la detección de posibles fallos.    En definitiva, la integración continua tiene como finalidad última minimizar progresivamente en                        cada iteración el coste del desarrollo tanto en las pruebas de las funcionalidades como en la                                detección y solución temprana de problemas, consiguiendo con ello maximizar la calidad del                          producto entregado.    6.3 Ventajas que se derivan de su utilización   Las principales ventajas que aporta la herramienta de integración continua son las siguientes:  ● Disponibilidad constante y en cualquier fase del proyecto de una construcción del                        desarrollo que se está implementando, ya sea para pruebas, demos o incluso para                          lanzamientos anticipados.  ● La ejecución inmediata, y en cada iteración, de las pruebas unitarias del código                          implementado en el desarrollo.  ● La detección y solución de forma continúa de problemas de integración por parte de los                              desarrolladores, consiguiendo de este modo evitar en gran medida los problemas de                        última hora que se acarrean a medida que se va aproximando la fecha de entrega del                                producto.  ● Monitorización continua e inmediata de las métricas de calidad del proyecto, así como                          del resultado obtenido en cada iteración del mismo.    6.4 Descripción del entorno de integración continua utilizado por Beeva   www.beeva.com      12 
  13. 13.     La herramienta adoptada por Beeva para implantar esta metodología de desarrollo es Jenkins.                          Este software de código abierto (distribuido y desarrollado libremente) ha sido desarrollado en                          Java, y permite ser ejecutado tanto en contenedores de servlets (por ejemplo Apache Tomcat),                            como de forma directa, utilizando para ello el servidor de aplicaciones Winstone.  Jenkins permite trabajar con diferentes herramientas de control de versiones (repositorios),                      ejecutando proyectos basados en Apache Ant y Apache Maven, así como la ejecución (tanto en                              local como en remoto) de Shell scripts o procesos por lotes de Windows.    6.5 Configuraciones y utilización de Jenkins   El entorno de integración continua sobre Jenkins utilizado por Beeva presenta la siguiente                          configuración:  ● Utilización de Subversion (SVN) como repositorio de software y herramienta de control                        de versiones.  ● Utilización mayoritaria de Apache Maven para la compilación, ejecución de pruebas                      unitarias del desarrollo y generación del paquete de software, contemplándose también                      la posibilidad de utilizar Apache Ant debido a que la configuración de Jenkins incluye el                              plugin para la integración de esta herramienta.  ● Despliegue de los paquetes generados mediante la ejecución de procesos por lotes                        (Shell scripts) preferiblemente.    Para integrar un proyecto en Jenkins, se deberá configurar (al menos) una nueva tarea                            independiente de las ya existentes, que en términos generales deberá ejecutar de forma                          ordenada los siguientes pasos:  ● Descarga del código fuente del repositorio Subversion (SVN).  ● Compilación del código descargado.  ● Ejecución de las pruebas unitarias.  ● Generación del paquete de software que contendrá el código compilado.  ● Despliegue del paquete generado en el servidor que proceda.    6.6 Plugins utilizados en el entorno Jenkins   A continuación se ofrece un listado de los plugins más relevantes utilizados en el entorno                              Jenkins de Beeva:  ● Subversion Plugin: Para la descarga de proyectos almacenados en el repositorio de                        software Subversion (SVN). Este plugin se incluye con la distribución de Jenkins.  ● Maven 2 Project Plugin: Para la construcción de proyectos basados en Apache Maven.                          Este plugin se incluye con la distribución de Jenkins.  ● ant: Para la construcción de proyectos basados en Apache Ant. Este plugin se incluye                            con la distribución de Jenkins.  ● Jenkins Sonar Plugin: Para la integración de la plataforma Sonar en Jenkins, destinada a                            www.beeva.com      13 
  14. 14.     la realización de análisis de calidad del software implementado.  ● Selenium Plugin: Para la integración de Selenium en Jenkins. Selenium es un framework                          para el testeo de software destinado a aplicaciones web que permite la ejecución                          programada de pruebas funcionales, sirviéndose para ello de diversos componentes                    (IDE, Remote Control, Grid, etc).  ● Publish Over SSH: Para el envío de ficheros y la ejecución de comandos y scripts en                                servidores remotos a través del protocolo SSH (Secure Shell).    7. Generación de Releases   La generación de las Releases se hará, por un lado con Eclipse (y el plugin de SVN), con el que                                        se creará el branch y por otro con Jenkis, que tendrá configurado el plugin “Maven Release” (el                                  Jenkis que usamos en Beeva bajo el control del equipo de sistemas ya lo está).    7.1 Procedimiento de Generación de una Release   1. Cuando decidamos que la línea de desarrollo principal está estable, procedemos a                        generar un branch desde el Eclipse: botón derecho sobre el “trunk” ­> “team” ­>                            “branch”. El nombre del branch incluirá el nombre del proyecto y la versión:                          nombreProyecto­releaseVersion, esta instrucción realmente lo que hace es hacer                  una copia del “trunk” y ponerla en el directorio “branches” con el nombre que hayamos                              elegido (de hecho, tanto create branch como create tag están basados en el svn copy).   2. Preparar el pom.xml para que funcione con el plugin de Jenkis: sólo se requiere poner la  etiqueta “scm” y que apunte al branch recién creado:   <scm>  <connection>scm:svn:http://subversion.bbvaglobalnet.com/java/…./branches/proyectoX­releas eVersion</connection> <developerConnection>scm:svn:http://subversion.bbvaglobalnet.com/java/.../branches/proyect oX­releaseVersion</developerConnection>      </scm>    3. Generar la Release con la tarea de Jenkis, la tarea de generación de releases de Jenkis  estará asociada al despliegue en el entorno de Desarrollo. La pantalla será algo así  como:    www.beeva.com      14 
  15. 15.         Los campos que tenemos que rellenar son:  releaseVersion: la versión que vamos a liberar (la que tiene el sufijo ­SNAPSHOT de la                              etiqueta “version” del pom.xml)  developmentVersion: la siguiente versión que se empezará a desarrollar, el plugin                      creará un artefacto SNAPSHOT con la versión que se indique.  version: la ruta de donde se va a sacar el codigo a liberar, en nuestro caso el branch                                    creado en el primer punto:      www.beeva.com      15 
  16. 16.         Lo que conseguimos es, por un lado generar una release (versión estable) con la versión                              3.0.1 que se desplegará en el repositorio de releases, por otro lado se generará un tag (código                                  congelado e intocable) con la versión 3.0.1, normalmente éste tag será el que se despliegue en                                entornos como preproducción o producción.    Por último, no olvidar que si el artefacto generado es dependencia de otros, hay que actualizar                                la versión a la generada.    7.2 Procedimiento de Generación de una revisión de una Release ¿Qué pasa si encontramos un bug en un tag? básicamente, generar otro que lo corrija, quizá                                a priori parece un poco tedioso y muchas veces estaremos tentados a corregir el bug                              directamente en el tag con excusas como: “... si es una tonteria, es sólo cambiar una clase!” ó                                    “... no te preocupes, que lo tengo localizado y fijo que no falla” pero esta práctica tiene el riesgo                                      de que por cualquier cosa el bug este mal corregido (y pasa a veces) y no podamos volver a                                      una situación conocida, con lo cual un tag NUNCA se debe modificar, para asegurarnos de que                                www.beeva.com      16 
  17. 17.     no es así se procede de la siguiente manera: por un lado se configura el artifactory para que no                                      se haga deploy de una versión estable (un release) de la que ya se ha hecho deploy                                  anteriormente y por otro lado, se debe configurar el repositorio de subversion para que no se                                permita hacer commits a tags.    Lo primero que hay que aclarar es que no siempre queremos incluir el bugfix en el propio tag, si                                      éste puede esperar a la siguiente release, el tag/release se dejará tal y como está y sólo se                                    cambiaría el “trunk” para incluir el bugfix en la siguiente release, pero si es importante incluir el                                  bugfix en una determinada versión, el procedimiento es:  1. Partir de un branch, en una situación normal, cuando ya se ha generado un branch para                                una versión concreta, sólo hará falta modificar el código asociado al branch, de hecho                            sólo hará falta un branch por versión y éste contendrá el código asociado a la última                                revisión de la versión.  2. Modificar el branch, desplegarlo en el entorno de desarrollo para su validación. Una vez                            validado, hay que incluir el bugfix en las versiones posteriores y el “trunk” (se puede usar                                el merge de SVN)  3. Una vez validado se genera desde Jenkis otra release, recordar el número que se                            modifica de la versión es el 4º (revisión) ya que la versión de la release es la misma:      www.beeva.com      17 
  18. 18.       Como podemos ver en la imagen, el branch del que se parte es el mismo que se uso                                    para generar la ultima release/tag.  4. El tag está listo para ser validado y desplegado en Producción.  5. Por último, no olvidar que si el artefacto generado es dependencia de otros, hay que                              actualizar la versión a la generada.    Como hemos visto, nosotros en ningún caso ni generamos un tag manualmente, ni lo                            modificamos, el tag es generado a partir de un “branch” por el plugin de Jenkis, por otro lado,                                    aparecerá en las listas de despliegue para ser desplegado en el entorno que queramos.  www.beeva.com      18 

×