Software">
Nothing Special   »   [go: up one dir, main page]

HDC DevOps Maven

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 15

UNIVERSIDAD AFRO-AMERICANA DE ÁFRICA CENTRAL

Facultad de Ingenierías-Departamento de Informática

HERRAMIENTAS DE DESARROLLO EN COMPUTACIÓN

DevOps:
Maven

MTR. SAMUEL ELA NSOGO NSA

PROFESOR/INGENIERO
Resumen
- DevOps es un acrónimo inglés de development (desarrollo) y operations
(operaciones), que se refiere a una metodología de desarrollo de
software que se centra en la comunicación, colaboración e integración
entre desarrolladores de software y los profesionales de sistemas en las
tecnologías de la información (IT)". DevOps es una respuesta a la
interdependencia del desarrollo de software y las operaciones IT. Su
objetivo es ayudar a una organización a producir productos y servicios
software más rápidamente, de mejor calidad y a un coste menor. Las
empresas con entregas (releases) muy frecuentes podrían requerir
conocimientos de DevOps. Flickr desarrolló un sistema DevOps para
cumplir un requisito de negocio de diez despliegues diarios. A este tipo
de sistemas se les conoce como despliegue continuo (continuous
deployment) o entrega continua (continuous delivery), y suelen estar
asociados a metodologías lean startup. Grupos de trabajo, asociaciones
profesionales y blogs usan el término desde 2009. Con todo lo anterior se
puede recetar en tres ideas clave:
- DevOps es una metodología para creación de software.
- DevOps se basa en la integración entre desarrolladores software y
administradores de sistemas.
- DevOps permite fabricar software más rápidamente, con mayor calidad,
menor coste y una altísima frecuencia de releases.

Definición
¿Qué es Maven?
Maven es una herramienta de gestión de proyectos y compilación que
generalmente se utiliza en marcos creados en Java. Está desarrollado por la
Fundación de Software Apache. Maven, una palabra del idioma yiddish, significa
"recolector de conocimientos". Se introdujo para realizar el proceso de
activación de la construcción en el Proyecto de Turbinas de Yakarta. Aunque se
puede utilizar con diversos lenguajes (C#, Ruby, Scala...) se usa principalmente
en proyectos Java, donde es muy común ya que está escrita en este lenguaje. De
hecho, frameworks Java como Spring y Spring Boot la utilizan por defecto.
Apache Maven es una potente herramienta de gestión de proyectos que se
utiliza para gestión de dependencias, como herramienta de compilación e
incluso como herramienta de documentación. Es de código abierto y gratuita.
Al contrario que otras herramientas anteriores y más limitadas como Apache Ant
(también muy popular), Maven utiliza convenciones sobre dónde colocar ciertos
archivos para el proceso de build de un proyecto, por lo que solo se debe
establecer las excepciones y por lo tanto simplifica mucho el trabajo. Además, es
una herramienta declarativa. Es decir, todo lo que definamos (dependencias en
módulos y compontes externos, procesos, orden de compilación, plugins del
propio Maven...) se almacena en un archivo XML que Maven lee a la hora de
funcionar. Otras alternativas, como Gradle no utilizan archivos XML, sino de otro
tipo, pero usan los mismos conceptos de Maven.

Por qué utilizar Maven


Maven realiza las siguientes actividades:
- Gestionar las dependencias del proyecto, para descargar e instalar
módulos, paquetes y herramientas que sean necesarios para el mismo.
- Compilar el código fuente de la aplicación de manera automática.
- Empaquetar el código en archivos .jar o .zip.
- Instalar los paquetes en un repositorio (local, remoto o en el central de la
empresa)
- Generar documentación a partir del código fuente.
- Gestionar las distintas fases del ciclo de vida de las build: validación,
generación de código fuente, procesamiento, generación de recursos,
compilación, ejecución de test.
- Integración con herramientas de Integración Continua como Jenkins.
- Integración con herramientas de control de versiones como Git.
Además, la mayor parte de los entornos de desarrollo y editores de Java
disponen de plugins específicos o soporte directo de Maven para facilitarnos el
trabajo con esta, puesto que se ha convertido en una herramienta casi universal.

ciclo de vida de un proyecto Maven


Maven cuenta con una serie de etapas que se ejecutan de forma secuencial y
ordenada. En la siguiente ilustración se puede observar el flujo de ejecución
para un proyecto Maven:
Validar Maven
Esta fase se encarga simplemente de validar que el proyecto dispone de toda la
información necesaria para ser procesado.

Compilación de Maven (ciclo de vida de Maven)


Es una de las fases más importante de la gestión de un proyecto Maven ya que
se encarga de compilar los ficheros fuentes .java y generar en las carpetas de
destino los compilados.

Prueba experta
Esta es otra de las fases principales en las cuales una vez se ha compilado el
código se ejecutan las pruebas unitarias que se han construido para él. De esta
forma nos aseguramos que nuestro código es correcto y no nos llevaremos
ninguna sorpresa en producción.
Paquete Maven (ciclo de vida de Maven).
Esta es otra de las fases fundamentales ya que se encarga de empaquetar
nuestro código a un formato standard de Java que permita su ejecución o
despliegue en servidor. Los empaquetados más habituales.

Maven verificar.
Esta fase del ciclo de vida se encarga de lanzar los test de integración para
confirmar que todo funciona correctamente y que la calidad es la correcta.

Ciclo de vida de Maven (instalación).


Es otra de las fases más importantes a la hora de trabajar con Maven ya que se
encarga de desplegar el artefacto en el repositorio local con su versionado de tal
forma que otros artefactos puedan hacer uso de él.
Hasta este punto se abordan las fases más habituales de trabajar con Maven ya
disponemos del artefacto instalado en el repositorio y otros artefactos se
podrán añadir a sus dependencias sin ningún problema.

Maven LifeCycle (implementación).


Esta fase cuesta mucho entender a los desarrolladores ya que ejecutar un
Maven Deploy muchas veces en un entorno meramente local no se realiza. Sin
embargo, es una fase clave cuando disponemos de una serie de artefactos que
deseamos compartir entre desarrollos ya que permite desplegar el artefacto en
un servidor remoto de tal forma que otros desarrolladores puedan utilizarlo.
¿Qué es el archivo pom.xml?
La unidad básica de trabajo en Maven es el llamado Modelo de Objetos de
Proyecto conocido simplemente como POM (de sus siglas en inglés: Project
Object Model).
Se trata de un archivo XML llamado pom.xml que se encuentra por defecto en la
raíz de los proyectos y que contiene toda la información del proyecto: su
configuración, sus dependencias, etc...
En la siguiente ilustración podemos observar la estructura habitual de un
proyecto Java que utiliza Maven:
En la siguiente ilustración visualizamos el contenido de un archivo pom.xml
sencillo de ejemplo:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>es.campusmvp</groupId>d>
<artifactId>demo</artifactId>
<version>1.0</version>
<!-- Dependencias -->
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-
engine</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>compile</scope>
</dependency>
</dependencies>
</project>
Como podemos observar incluye una serie de dependencias: la primera es el
starter de Spring Boot para generar una aplicación Web, la segunda es el starter
que trae todas las dependencias para poder ejecutar test (por ejemplo, JUnit o
Mockito) y que excluye todo lo relativo al motor antiguo de JUnit 4. La final
añade el soporte para JSP en el servidor Apache Tomcat.
Los 4 primeros nodos son los únicos obligatorios y definen respectivamente el
modelo de objetos que utilizará Maven, el identificador del grupo del proyecto,
el id del proyecto (artifact) y su versión. Esto es lo mínimo que debe incluir el
archivo si utilizamos Maven y la mayor parte de los editores y herramientas nos
lo crearán automáticamente al crear el proyecto.
De forma general, definiremos cada parámetro del archivo pom.xml del proyecto
por separado tal que:

- GroupId: reconoce nuestro proyecto de forma única entre todos los


proyectos. GroupId es parte del archivo pom. Se suele decir como
identidad del grupo de proyectos.
- ArtifactId: un archivo jar que se implementa en el repositorio de Maven.
ArtifactId es parte del archivo pom. Se suele decir que es la identidad y el
nombre de nuestro proyecto.
- Versión: Especifica la versión del jar del proyecto. La versión también
forma parte del archivo pom. Como se muestra en la imagen de arriba,
podemos ver que las etiquetas <groupId>, <artifactId> y <version>
forman parte de las dependencias definidas para el proyecto.

Repositorio Maven
El repositorio Maven puede ser de tres tipos:
- Repositorio local
- Repositorio remoto
- Repositorio central
Una vez que Maven lee las dependencias del archivo POM, primero las busca en
el repositorio local, luego en el central y finalmente en el repositorio remoto. Si
las dependencias no se encuentran en ninguno de los tres repositorios, se
notifica al usuario con un error y se detiene el proceso.
#1) Repositorio local de Maven
El repositorio local está ubicado en nuestro sistema local, principalmente en el
directorio .m2 (C:/Users /superdev /.m2), que muestra su presencia una vez que
Maven está instalado en nuestro sistema y hemos podido ejecutar con éxito un
comando de Maven.
#2) Repositorio central de Maven
El repositorio central (https://repo.maven.apache.org/maven2/ ) es
desarrollado por el grupo Apache Maven y está alojado en la web. Este se
considera el repositorio central y cuenta con todas las bibliotecas comunes. Al
igual que un repositorio local, también podemos modificar la ubicación donde
se descargarán por defecto cambiando el archivo settings.xml.
#3) Repositorio remoto de Maven
También se aloja un repositorio remoto en la web. En algunos escenarios, una
empresa puede desarrollar su propio repositorio remoto y realizar
implementaciones en sus proyectos privados. Estos serán propiedad de esa
empresa específica y podrán operarse únicamente dentro de ella.
El repositorio remoto tiene patrones de trabajo similares a los de un repositorio
central. Siempre que se requieran dependencias o configuraciones de estos
repositorios, primero se descargarán en nuestro local y luego se usarán.

Herencia y agrupación
#1) Herencia
Maven permite gestionar dependencias desde un pom padre a los hijos para
simplificar y evitar redundancias. El empaquetado debe indicarse como pom en
la definición del pom padre.
El Super POM es un ejemplo de herencia de proyecto.
Es similar a como cualquier objeto Java hereda de Object.
Permite al equipo de desarrollo de Maven definir un patrón claro y estable de
base que estará siempre presente. El usuario tan solo tiene que añadir en su
pom aquellos cambios que requiera para su proyecto concreto.

#2) Agrupación.

• Un proyecto puede agrupar en su paquete varios proyectos distintos


definiéndolos como módulos en su POM.
• Cada entrada <module> es la dirección relativa al directorio del proyecto
a cargar como módulo, dentro del cual estará su propio pom.
• Al construir el proyecto, se compilan e incluyen en el paquete todos sus
módulos. Maven gestiona automáticamente las dependencias entre
ellos.
• Un proyecto puede ser multi-módulo, proyecto padre o ambos a la vez:
Se usa herencia para evitar redundancia y centralizar información (versiones, url,
licencias, propiedades, etc.)
Se usa agrupación para incluir diferentes proyectos en una misma unidad.

POM extendido
#1.1) Propiedades.
• Definen constantes para usar en cualquier otra parte del pom.xml
• Se declaran en su propio campo.
• Se acceden desde cualquier parte con ${nombre-propiedad} como por
ejemplo: ${project.build.sourceEncoding}
• Muchos plugins usan propiedades para facilitar cambios de configuración.

#1.2) Propiedades (automáticas)


Además de las explícitamente definidas en el campo <properties >, Maven
crea ciertas propiedades automáticamente:
• env.X :: Acceso a propiedades de la shell: ${env.PATH}
• java.X :: Acceso a propiedades de java: ${java.home}
• project.X :: Acceso a campos definidos en el pom: ${project.name}
extraería el valor de
<project><name>nombreProyecto</project></name>
• settings.X :: Acceso a campos definidos en settings.x ml:
${settings.DB Backend}

#2.1) Build
Información sobre el proceso de compilación y construcción del proyecto.

- default Goal :: Acción (o fas e) a ejecutar por defecto.


- directory :: Directorio de la construcción, donde se escribirán las clases
compiladas, paquetes y logs. Por defecto usará el directorio ./target en el
directorio del pom.
- filters :: Define ficheros adicionales de los que extraer propiedades.
Maven parsea es os ficheros convirtiendo entradas del tipo
`nombre=valor` a propiedades `${nombre}` con el valor indicado para uso
en el campo de recursos.
#2.2) Build (recursos)
Dentro del apartado <build> se pueden definir recursos externos necesarios
para la construcción del proyecto. Estos pueden ser imágenes, ficheros de
configuración, consultas sql, ...
Con filtering a true, Maven sustituye en los recursos indicados todas las
llamadas a propiedades incluyendo:
- propiedades definidas en el pom
- propiedades automáticas
- propiedades dadas por argumento en ejecución
#2.3) Plugins
Colección de acción es (goals) de Maven:
- archetype:generate :: Acción generate del plugin archetype
- install:install :: Acción install del plugin install
Tanto acciones como plugins se pueden agrupar jerárquicamente para crear
nuevas acciones o plugins más complejos. Las acciones pueden recibir
parámetros (-D) e incluso tener valores por defecto asignados a los parámetros.
Podemos pensar en ellas como en programas CLI de Unix. Los plugins se
versionan y pueden configurarse en el pom. Ejemplos de plugins básicos:
compiler, jar, war.

#2.4) Informes
E l campo <reporting> sirve para configurar plugins que es criben algún tipo de
informe, como puede ser generar el javadoc del código.
Al igual que <build>, se definen plugins con su correspondiente configuración.
Para más granularidad, también se definen reportSets para poder configurar
qué hacer con acciones concretas.
#2.5) Información adicional
E l pom recoge la mayoría de meta-información del proyecto. Algunos datos
habituales que se incluyen:
• Datos de empres a o grupo

• Licencias

• Equipo
• Datos de CI/C D
• Gestor de incidencias
Bibliografía:
https://www.softwaretestinghelp.com/maven-tutorial/
https://www.tokioschool.com/noticias/que-es-maven/
https://www.campusmvp.es/recursos/post/java-que-es-maven-que-es-el-
archivo-pom-xml.aspx
https://www.arquitecturajava.com/que-es-un-maven-lifecycle-y-como-funciona/
https://eusebiorubio.es/fases-de-maven-explicadas-en-un-grafico/
https://www.arquitecturajava.com/que-es-un-java-maven-artifact/
https://maven.apache.org/guides/introduction/introduction-to-the-pom

También podría gustarte