Bienvenidos, amantes de la automatización y víctimas ocasionales de la programación, a otra entrada de nuestro blog, donde el sarcasmo se encuentra con el código, y las buenas prácticas de desarrollo son el plato principal. Hoy nos zambulliremos en el maravilloso mundo de Jenkins, específicamente en cómo escribir bibliotecas Groovy sin perder la cordura. Así que prepárate para un viaje a través del código, donde las risas y las lágrimas de frustración están casi garantizadas.
1. Scripts Globales vs. Implementación de Clases: La Eterna Batalla
Primero, decidamos si vamos a la guerra con armadura (implementación de clases) o en pijama (scripts globales). Mientras que los scripts globales son como ese amigo que siempre está disponible pero un poco desorganizado, las clases te ofrecen la estructura que necesitas para no perderte en tu propio código. Elegir entre uno y otro es como decidir si quieres café o té en la mañana. Ambos te despiertan, pero la elección depende de cuánto control quieres sobre tu vida (o tu código).
2. Pipelines Declarativos vs. Scripting: ¿Bailamos?
Aquí tenemos el eterno debate entre libertad y restricciones. Los pipelines declarativos son como seguir una receta de cocina al pie de la letra, mientras que el scripting es como improvisar un platillo con lo que encuentres en la nevera. Ambos pueden terminar en desastre si no sabes lo que estás haciendo, pero la verdadera magia ocurre cuando encuentras el equilibrio perfecto entre seguir las reglas y romperlas sabiamente.
3. Lidiando con las Limitaciones de Jenkins Groovy: Un Juego de Ingenio
Jenkins Groovy puede ser tan limitante como intentar programar con un teclado sin la tecla de espacio. Sin embargo, con un poco de ingenio y mucha paciencia, puedes superar estas limitaciones. La clave está en conocer las restricciones como la palma de tu mano y luego aprender a bailar alrededor de ellas sin pisar el vestido.
Aquí tienes una versión afinada sobre cómo abordar estas restricciones, incluyendo la peculiaridad de la serialización y la magia de las anotaciones NonCPS, para mantener tu baile fluido y elegante.
-
Conoce las Reglas del Juego: Primero, es esencial entender las políticas del sandbox de Jenkins. Saber qué métodos y clases están permitidos te dará la libertad de moverte dentro de los límites sin pisarte la cola.
-
Solicita el Pase VIP cuando lo Necesites: Para esas ocasiones en las que necesitas ir más allá de lo básico, la aprobación manual de scripts es tu mejor amigo. Es como pedir permiso para sacar un as bajo la manga en medio del espectáculo.
-
Baila alrededor de la Serialización: Uno de los mayores tropiezos en Jenkins Groovy es la serialización. Groovy quiere que todo sea serializable para jugar bien en el entorno distribuido de Jenkins. Aquí es donde entra la anotación
NonCPS. Usar@NonCPSen métodos que no se llevan bien con la serialización es como aprender a hacer pasos de baile que evitan las partes resbaladizas del escenario. Te permite ejecutar lógica compleja sin el temor de que tu script sea detenido por problemas de serialización. -
La Elegancia de la Simplicidad: Finalmente, mantén las cosas simples. Cuanto más directo sea tu código, menos probable será que choques con las barreras del sandbox. Piénsalo como perfeccionar unos pocos pasos de baile impresionantes en lugar de intentar una rutina complicada que podría terminar en un tropiezo.
En resumen, las limitaciones de Jenkins Groovy ciertamente presentan desafíos, pero con un conocimiento profundo de las reglas, la astucia para solicitar permisos especiales, y la habilidad para navegar alrededor de la serialización con NonCPS, puedes seguir realizando tu coreografía de CI/CD con gracia y precisión. Aunque el entorno intente limitarte, tu ingenio te permitirá presentar una actuación que deje a la audiencia pidiendo más.
4. Configurando el proyecto
Ahora, queridos desarrolladores de Jenkins y aficionados al caos organizado, hablemos de un tema que puede hacer que nuestro código sea tan elegante como un gato en un smoking: la importancia de usar Gradle con Groovy para la configuración y la independencia del IDE de desarrollo. Sí, has leído bien. Vamos a independizarnos de esos IDEs pegajosos que, aunque nos encantan, a veces nos atan más que las condiciones de servicio de cualquier red social.
Primero, aclaremos algo: Gradle es esa herramienta mágica que nos permite construir, probar, y desplegar software sin tener que vender nuestra alma al diablo de los entornos de desarrollo específicos. Es como tener un suizo ejército pero para el desarrollo de software. Y cuando lo mezclamos con Groovy, bueno, se convierte en una fiesta de productividad que no querrás perderte.
Ahora, imagina este escenario: Estás desarrollando una librería compartida para Jenkins, tus dedos bailan sobre el teclado, y entonces te das cuenta de que tu compañero de equipo no usa el mismo IDE que tú. Horrorizado, comprendes que el caos y la desesperación están a punto de desatarse… Pero espera, aquí es donde Gradle viene al rescate, permitiéndote a ti y a tu equipo trabajar en armonía, independientemente del IDE. Es como si todos pudieran bailar al ritmo de su propia música, pero de alguna manera, la coreografía sigue siendo perfecta.
Además, estructurar los directorios según la convención de Jenkins no solo es una buena práctica, es casi una ceremonia sagrada. Piénsalo como organizar tu armario según el color y la temporada; no solo se ve bien, sino que te ahorra un tiempo precioso cuando estás buscando esa camisa perfecta, o en nuestro caso, ese script específico.
Y para poner la cereza en el pastel, te voy a regalar el primer fichero de configuración build.gradle que necesitas para arrancar. No digas que nunca te doy nada:
plugins {
id 'groovy'
}
java {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
}
repositories {
gradlePluginPortal()
mavenCentral()
maven {
url 'https://repo.jenkins-ci.org/releases/'
}
}
sourceSets {
main {
groovy.srcDirs = ['vars', 'src']
resources.srcDirs = ['resources']
}
test {
groovy.srcDirs = ['test/groovy']
resources.srcDirs = ['test/resources']
}
}
dependencies {
implementation 'org.codehaus.groovy:groovy-all:2.5.23'
implementation 'com.cloudbees:groovy-cps:1.31'
testImplementation 'org.codehaus.groovy:groovy-all:2.5.14'
testImplementation 'org.spockframework:spock-core:2.2-M1-groovy-2.5'
testImplementation 'org.spockframework:spock-junit4:2.2-M1-groovy-2.5'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.1'
testImplementation 'org.yaml:snakeyaml:2.2'
}
tasks.withType(Test) {
useJUnitPlatform()
testLogging {
//showStandardStreams true
exceptionFormat 'FULL'
events 'skipped', 'failed'
}
}
Este pequeño pero poderoso fichero es tu llave maestra para empezar. Configura tu entorno, invoca a los dioses del código y prepárate para crear algo que incluso el mismísimo Jenkins no podría haber imaginado en sus sueños más locos.
Este archivo build.gradle está configurado para un proyecto de Jenkins Shared Library utilizando Gradle con el lenguaje de programación Groovy. A continuación, se desglosa cada sección y su propósito:
Plugins
plugins {
id 'groovy'
}
plugins: Esta sección declara los plugins que se utilizarán en el proyecto. En este caso, solo se especifica el plugingroovy, necesario para compilar y trabajar con código Groovy, el lenguaje utilizado para escribir la biblioteca compartida de Jenkins.
Java Compatibility
java {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
}
java: Configura la compatibilidad del código fuente y la compatibilidad de la versión objetivo de Java. Aquí, se establece tanto la compatibilidad de la fuente como la del objetivo en Java 11, asegurando que el código se compile para ser compatible con esta versión específica de Java.
Repositories
repositories {
gradlePluginPortal()
mavenCentral()
maven {
url 'https://repo.jenkins-ci.org/releases/'
}
}
repositories: Define los repositorios de donde Gradle puede descargar las dependencias. Incluye el portal de plugins de Gradle, Maven Central para la mayoría de las dependencias Java/Groovy, y un repositorio específico de Jenkins para acceder a artefactos específicos de Jenkins.
Source Sets
sourceSets {
main {
groovy.srcDirs = ['vars', 'src']
resources.srcDirs = ['resources']
}
test {
groovy.srcDirs = ['test/groovy']
resources.srcDirs = ['test/resources']
}
}
sourceSets: Personaliza la estructura de directorios del proyecto para el código fuente y los recursos.maindefine los directorios para el código Groovy (vars,src) y los recursos (resources), mientras quetestespecifica dónde encontrar los tests (test/groovy) y sus recursos asociados (test/resources). Este enfoque es crucial para la organización de una biblioteca compartida de Jenkins, dondevarssuele contener definiciones de pasos globales.
Dependencies
dependencies {
// Implementación principal y dependencias de testing
}
dependencies: Enumera las dependencias necesarias para el proyecto. Incluye la implementación de Groovy (groovy-all), una dependencia específica de Jenkins para CPS (groovy-cpsde CloudBees), y varias dependencias para testing (spock-framework,junit-jupiter-api,snakeyaml), facilitando la escritura de pruebas unitarias y la gestión de configuraciones en formato YAML.
Test Configuration
tasks.withType(Test) {
useJUnitPlatform()
testLogging {
exceptionFormat 'FULL'
events 'skipped', 'failed'
}
}
tasks.withType(Test): Personaliza la configuración de las tareas de prueba. Habilita la plataforma JUnit para la ejecución de tests, configura el formato de logging de excepciones para mostrar toda la información (FULL), y define qué eventos de prueba se logran (skipped,failed), mejorando la visibilidad y el diagnóstico durante el desarrollo de tests.
Esta configuración demuestra un enfoque cuidadosamente pensado para el desarrollo de bibliotecas compartidas de Jenkins, aprovechando las características de Gradle para mejorar la estructuración del proyecto, la gestión de dependencias y la compatibilidad con diversas versiones de Java, al tiempo que facilita la integración continua y la entrega continua (CI/CD).
El Encanto Único de Gradle con Groovy sobre Maven
Ahora, ¿por qué usar Gradle con Groovy en vez de Maven u otras alternativas?
Imagina por un momento que estás en un concurso culinario, con la tarea de preparar el mejor plato posible. Maven es como tener una caja de ingredientes preseleccionados con instrucciones específicas: eficiente y confiable, sí, pero ¿dónde queda el espacio para la creatividad? Gradle con Groovy, por otro lado, es como tener acceso ilimitado a todos los ingredientes del mundo, junto con la libertad de mezclarlos como te plazca. Te permite ser el chef Michelin de tu proyecto, ajustando y experimentando hasta que tu ‘plato’ (léase, configuración de construcción) esté sazonado a la perfección.
Además, Gradle ofrece una evaluación perezosa de sus scripts, lo que significa que solo ejecuta lo que necesita, cuando lo necesita, optimizando el tiempo de construcción y permitiendo una configuración mucho más dinámica. En contraste, Maven, con su estructura más rígida, a veces puede sentirse como intentar realizar una pirueta en una armadura medieval.
En resumen, Gradle con Groovy ofrece una flexibilidad y eficiencia que Maven simplemente no puede igualar, permitiéndote adaptar tu proceso de construcción a las necesidades exactas de tu proyecto. Porque, al final del día, ¿quién quiere seguir una receta al pie de la letra cuando puedes crear una obra maestra culinaria (o de código) con tu toque personal?
5. Diseñando un API con Buenas Prácticas: El Arte de la Elegancia
Crear un API en Jenkins Groovy es como organizar una fiesta donde todos tus invitados son críticos culinarios. Necesitas asegurarte de que cada plato (interfaz) sea exquisito y esté perfectamente preparado. Interfaces como IBuildTool o ILogger son tus utensilios de cocina; úsalos sabiamente para impresionar a tus comensales con la elegancia de tu código.
Vamos a profundizar en este arte, ¿de acuerdo?
Abstracciones y Definiciones de Interfaces
El diseño de un API en el mundo de Jenkins Groovy es un delicado equilibrio entre la abstracción y la utilidad. Imagina que estás esculpiendo en mármol: cada golpe de cincel debe ser preciso, cada línea debe tener un propósito. En nuestro caso, el mármol son las interfaces como IBuildTool, IConfigClient, ILogger, IPipelineContext, IStage, ISteps, ITool, IService. Cada una de estas interfaces representa un aspecto fundamental de nuestro sistema, un contrato sagrado que promete cierta funcionalidad sin revelar cómo se logra esa magia.
IBuildTool
Piensa en IBuildTool como el maestro de ceremonias de tus herramientas de construcción. Esta interfaz garantiza que, sin importar si estás lidiando con Maven, Gradle, o cualquier otro sistema de construcción, tienes un conjunto coherente de operaciones a tu disposición. Es como pedir un café en cualquier parte del mundo y recibir exactamente lo que esperabas, sin sorpresas.
interface IBuildTool<A extends Artifact, F extends FileDefinition> extends ITool {
A build(List<String> options)
void publish(ArtifactRepository repository, A artifact)
F readFileDefinition()
F writeVersion(String overrideVersion)
}
IConfigClient
IConfigClient es el oráculo de tu proyecto, capaz de revelar los misterios de la configuración con solo invocarlo. Implementar esta interfaz te permite acceder a un mundo donde la configuración es fluida, dinámica y, sobre todo, no está hardcodeada en rincones oscuros de tu código.
interface IConfigClient {
void load()
void refresh()
def <T> T required(String key, Class<T> type)
def <T> T optional(String key, Class<T> type)
def <T> T optional(String key, T defaultValue)
}
ILogger
ILogger es tu narrador personal, documentando la épica odisea de tu código en producción. Proporciona una abstracción sobre cómo se registran los mensajes, permitiéndote cambiar el tono de la narrativa sin alterar la historia. En otras palabras, es la diferencia entre contar tu viaje con emojis o con un lenguaje poético; el contenido es el mismo, pero la presentación puede variar.
interface ILogger {
void setLogLevel(LogLevel level)
void info(String message)
void warn(String message)
void debug(String message)
void error(String message)
void fatal(String message)
void executeWhenDebug(Closure body)
def <T> void printPrettyLog(LogLevel level, T obj)
void logPrettyMessages(LogLevel level, List<String> messages)
void logPrettyError(List<String> msgs)
}
IPipelineContext: El Director Orquestal en un Mundo de Solistas
Imagina por un momento que IPipelineContext es ese director de orquesta que intenta mantener a la banda unida, pero cada músico tiene su propia idea de la sinfonía. Este director no solo tiene la batuta para dirigir el espectáculo sino que también lleva un cinturón de herramientas al estilo Batman para enfrentar cualquier eventualidad en este caótico concierto de CI/CD.
El Gran Maestro de la Multitarea
IPipelineContext extiende IServiceLocator, lo que básicamente lo convierte en el héroe sin capa que todos necesitamos pero nadie realmente entiende. Piensa en él como ese amigo que tiene el número de todos en su teléfono y siempre sabe a quién llamar para resolver tus problemas, desde encontrar el mejor lugar para comer hasta arreglar tu computadora.
interface IServiceLocator extends Serializable {
def <T extends IService> T getService(String name)
void registerService(String name, IServiceFactory factory)
void initializeServices(IConfigClient configClient)
}
interface IPipelineContext extends IServiceLocator {
List<String> getSkipStages()
void addSkipStage(String stage)
void injectEnvironmentVariables(Map<String, String> envVars)
IConfigClient getConfigClient()
ILogger getLogger()
Script getSteps()
}
-
El Encantador de Servicios: Con su habilidad para
getService(String name),IPipelineContextpuede convocar cualquier servicio con solo susurrar su nombre. Es como tener un genio en una lámpara, pero en lugar de tres deseos, tienes acceso ilimitado a servicios que ni siquiera sabías que necesitabas. -
El Reclutador de Élite: A través de
registerService(String name, IServiceFactory factory), este maestro del multitasking no solo encuentra al mejor talento sino que también lo pone a trabajar de inmediato. Imagina poder reclutar a un equipo de superhéroes para cada proyecto. ¿Necesitas un experto en configuraciones al vuelo? Hecho. ¿Un mago del registro? También está en el equipo. -
El Entrenador de Servicios: Con
initializeServices(IConfigClient configClient), este director orquestal no solo recluta sino que también asegura que todos estén afinados y listos para el espectáculo. Es como ese entrenador que no solo te consigue los mejores jugadores sino que también los hace jugar en armonía.
IPipelineContext, con su linaje de IServiceLocator, es el cerebro detrás de la operación, el mago detrás de la cortina, y el maestro de ceremonias todo en uno. En el caótico mundo del CI/CD, donde cada pipeline es un potencial drama en cinco actos, este es el personaje que mantiene las cosas en marcha, asegurando que cada servicio esté en su lugar, cada variable de entorno inyectada con precisión quirúrgica, y cada etapa del proceso listo para el gran estreno. Es el tipo de líder que, en el apocalipsis de desarrollo, estarías agradecido de tener de tu lado, principalmente porque sabe dónde está todo y cómo hacer que funcione. En otras palabras, IPipelineContext es el director de orquesta que hace que la música suene, incluso cuando todos los músicos parecen estar tocando diferentes melodías.
PipelineComponent, IStage, e ISteps
Primero, conozcamos a PipelineComponent. Este individuo es el maestro de la iniciación, aquel que sabe cómo empezar la fiesta, introduciendo IConfigClient al sistema. En esencia, prepara a todos para entender el idioma universal de la configuración sin importar en qué rincón oscuro de Jenkins se encuentren.
interface PipelineComponent {
void initialize(IConfigClient configClient)
}
Luego, aparece IStage, adaptando las capacidades de nuestro stage de Jenkins tradicional para asumir el rol de director de escena. Piensa en él como el director que, con un simple movimiento de su batuta (o, en este caso, una llamada de método), puede hacer que incluso las partes más tediosas del despliegue se sientan como un interludio dramático en una obra maestra.
interface IStage extends PipelineComponent {
def stage(String name, Closure body)
}
Por último, pero no menos importante, tenemos a ISteps, el silencioso. No dice mucho, de hecho, no dice nada en absoluto, pero siempre está ahí, firme, listo para actuar cuando se le necesita.
interface ISteps extends PipelineComponent {}
Lo bello de este trío no es solo su capacidad para enfrentar el caos con dignidad; es cómo, juntos, construyen un puente sobre el abismo que separa tu precioso código de la maquinaria pesada de Jenkins. Piénsalos como adaptadores de corriente en un país extranjero: no importa qué extraña sea la entrada, ellos se aseguran de que puedas conectar tu secador de pelo sin incendiar el hotel.
Así que, la próxima vez que te encuentres navegando por el turbulento mar de la automatización de CI/CD, recuerda a PipelineComponent, IStage, e ISteps. No son solo interfaces en tu código; son tus guardianes, tus protectores, asegurándose de que, pase lo que pase, tu código permanecerá elegante, modular y, lo más importante, funcional, sin casarse con la infraestructura subyacente.
ITool, IService
Finalmente, ITool y IService son los comodines de tu baraja, ofreciéndote flexibilidad para definir herramientas y servicios adicionales que tu pipeline pueda necesitar. Son las piezas del rompecabezas que te permiten personalizar tu entorno de CI/CD para que se adapte perfectamente a tus necesidades.
interface ITool extends PipelineComponent {
String execute(String taskName, List<String> options)
}
interface IService extends PipelineComponent {
}
Diseñando con Elegancia
Diseñar un API elegante en Jenkins Groovy es como componer una sinfonía; cada interfaz debe armonizar con las demás, creando una obra de arte cohesiva y funcional. No basta con definir interfaces; debes considerar cómo interactúan entre sí, cómo se extienden y cómo se complementan. La elegancia surge de la simplicidad, la claridad y, lo más importante, la utilidad. Recuerda, un buen diseño de API no solo facilita la vida de quienes lo implementan, sino también de aquellos que eventualmente tendrán que mantener y evolucionar tu código.
Implementacion de Interfaces. Damos cuerpo a las principales abstracciones.
En el corazón de nuestro post sobre la implementación de interfaces, nos sumergimos en el mundo donde las abstracciones cobran vida a través de Steps e IStage, dos pilares que transforman el esqueleto de nuestros pipelines de Jenkins en entidades pulsantes, listas para la acción. Este segmento se adentra en cómo estas clases abstractas y la implementación de interfaces dan forma a la ejecución de las etapas de un pipeline, garantizando no solo la ejecución de tareas sino también una gestión elegante de los flujos de trabajo y las excepciones.
La Clase Steps: La Base de Todo
Steps actúa como la fundación sobre la cual todas las operaciones específicas del pipeline se construyen. Al implementar la interfaz ISteps, esta clase establece el terreno común para cualquier acción que se desee realizar dentro de un pipeline de Jenkins.
abstract class Steps implements ISteps {
protected Script steps
protected ILogger logger
protected IPipelineContext pipeline
Steps(IPipelineContext pipeline) {
this.pipeline = pipeline
this.steps = pipeline.getSteps()
this.logger = pipeline.getLogger()
initialize(pipeline.getConfigClient())
}
}
-
Inicialización y Configuración: En el constructor,
Stepstoma unIPipelineContextcomo argumento, asegurando que cada instancia tenga acceso al contexto del pipeline actual, incluyendo los pasos de Jenkins (steps) y un logger para la grabación de eventos o errores. Esto prepara el terreno para que las acciones subsiguientes se ejecuten con contexto y soporte de logging. -
Inyección de Dependencias: La inicialización automática dentro del constructor con
initialize(pipeline.getConfigClient())demuestra una elegante inyección de dependencias, permitiendo que las subclases configuren componentes adicionales según sea necesario, basándose en la configuración del pipeline.
La Clase Stage: Dando Vida a las Etapas
Stage, extendiendo Steps e implementando IStage, se especializa en la definición y ejecución de las etapas del pipeline, proporcionando una estructura sobre cómo cada etapa debe ser procesada.
abstract class Stage extends Steps implements IStage {
static final List <String> packagesOrClassesPatterns = [
'dev.rubentxu', // Paquete base de tu framework groovy
'java.lang.AssertionError',
'.groovy:', // captura las trazas de los scripts de vars/
]
Stage(IPipelineContext pipeline) {
super(pipeline)
}
@Override
def stage(String name, Closure body) {
body.delegate = steps
steps.stage(name) {
if (!evaluateIfSkipStage(name)) {
def result = null
try {
logger.info "Execute Stage with name: '$name'"
result = body()
} catch (Exception ex) {
handleException(name, ex, logger)
steps.currentBuild.result = 'FAILURE'
steps.error ex.getMessage()
}
logger.info "Finalize Stage with name: '$name'"
return result
}
}
}
protected boolean evaluateIfSkipStage(String name) {
Boolean skipped = false
if (pipeline.skipStages?.contains(name)) {
logger.warn "Stage '$name' is marked to be skipped (pipeline.skipStages=${pipeline.skipStages.join(',')})"
skipped = true
}
return skipped
}
static void handleException(String name, Exception ex, ILogger logger) {
List lines = ["Error in Stage $name", ex.toString(), ex.getMessage()]
lines.add('----------------------------------------')
lines.addAll(filterStackTrace(ex).join("\n"))
logger.logPrettyError(lines)
}
private static filterStackTrace(Exception ex) {
return ex.getStackTrace().findAll {stackTraceElement ->
packagesOrClassesPatterns.any { pattern -> stackTraceElement.toString().contains(pattern)}
}
}
}
-
Ejecución Condicional de Etapas: La función
stageencapsula la lógica para ejecutar una etapa del pipeline, incluyendo la evaluación de si la etapa debe ser omitida (evaluateIfSkipStage). Esto añade una capa de decisión que permite una mayor flexibilidad en la ejecución del pipeline, evitando la ejecución de etapas innecesarias o seleccionadas para ser saltadas. -
Manejo Elegante de Excepciones: El manejo de excepciones dentro de
stageasegura que cualquier error en la ejecución de una etapa se capture, registre y maneje adecuadamente, evitando que el pipeline falle silenciosamente y proporcionando retroalimentación útil para la depuración.handleExceptiones una función estática que filtra y presenta los detalles del error de manera legible, subrayando la importancia de un logging efectivo en el diagnóstico de problemas. -
Delegación y Ejecución de Cuerpo: Al establecer
body.delegate = steps, se permite que el cuerpo de la etapa (definido por el usuario) ejecute los pasos de Jenkins directamente, manteniendo el código de la etapa limpio y centrado en la lógica de negocio, mientras se beneficia de toda la potencia de la DSL de Jenkins Pipeline.
La implementación de Steps e IStage ilustra un enfoque sofisticado para estructurar y ejecutar pipelines de Jenkins. Al dar cuerpo a las abstracciones a través de estas implementaciones, se facilita la creación de pipelines robustos, mantenibles y flexibles que pueden adaptarse dinámicamente según las necesidades del proyecto y manejar los imprevistos con gracia. Este enfoque no solo mejora la legibilidad y la organización del código sino que también enriquece la capacidad de los desarrolladores para construir sistemas de CI/CD complejos con una gestión de errores eficiente y un control de flujo avanzado.
La clase PipelineContext
La clase PipelineContext es una implementación concreta de la interfaz IPipelineContext, actuando como el corazón y el cerebro de la gestión de contextos dentro de un pipeline de Jenkins. Esta clase es fundamental para orquestar y mantener el estado a lo largo de la ejecución del pipeline, proveyendo servicios esenciales, manejo de configuraciones, registro de logs, y la ejecución de pasos específicos. A continuación, se detalla el propósito y el objetivo de cada función y cómo contribuyen al funcionamiento global del pipeline.
Fundamentos del Contexto
- Constructor
PipelineContext(Script steps, ILogger logger, IConfigClient configClient): Este método inicializa el contexto del pipeline con los componentes esenciales:stepspara ejecutar operaciones de Jenkins Pipeline,loggerpara el registro de actividades y errores, yconfigClientpara manejar configuraciones externas. La inicialización deservicescomo unConcurrentHashMapasegura la gestión segura de servicios en entornos concurrentes.
Gestión de Servicios
-
registerService(String name, IServiceFactory factory): Permite la registración dinámica de servicios por nombre, utilizando fábricas de servicios (IServiceFactory). Esto facilita la extensibilidad y la modularidad del sistema, permitiendo añadir o modificar servicios en tiempo de ejecución sin alterar el núcleo del contexto. -
getService(String name): Recupera una instancia del servicio registrado bajo el nombre especificado, creándola mediante su fábrica asociada. Esto demuestra un patrón de diseño de inyección de dependencias, permitiendo el acceso a servicios de manera controlada y desacoplada.
Inicialización y Configuración
initializeServices(IConfigClient configClient): Itera sobre todas las fábricas de servicios registradas, inicializándolas con el cliente de configuración. Este paso es crucial para asegurar que todos los servicios estén correctamente configurados y listos para ser utilizados dentro del pipeline.
Gestión de Etapas
getSkipStages()yaddSkipStage(String stage): Estos métodos gestionan una lista de etapas a omitir durante la ejecución del pipeline. Permiten una configuración dinámica del flujo de trabajo, habilitando o deshabilitando etapas específicas según las necesidades del momento.
Variables de Entorno
injectEnvironmentVariables(Map<String, String> envVars): Introduce variables de entorno personalizadas en el entorno de ejecución del pipeline. Este método demuestra cómo se pueden modificar los entornos de ejecución de manera programática para ajustar las operaciones del pipeline a contextos específicos.
Acceso a Componentes Esenciales
getConfigClient(),getLogger(), ygetSteps(): Proveen acceso conveniente a los componentes fundamentales del contexto del pipeline: el cliente de configuración, el sistema de registro, y el objetoScriptpara ejecutar pasos del pipeline, respectivamente. Estos métodos aseguran que todas las partes del sistema puedan acceder y utilizar estas herramientas esenciales sin tener que manejar sus instancias directamente.
La clase PipelineContext encapsula eficazmente la complejidad de manejar el estado y la configuración a lo largo de la ejecución del pipeline, proporcionando un mecanismo estandarizado y flexible para acceder a servicios, configurar etapas, e inyectar variables de entorno. Su diseño promueve la separación de preocupaciones, la reutilización de código y la facilidad de mantenimiento, elementos cruciales para el desarrollo sostenible de pipelines de CI/CD complejos y robustos.
Singleton y Fábricas de Servicios
La implementación de ContextSingleton y ServiceFactory, junto con la interfaz IServiceFactory, son componentes clave en la arquitectura de gestión de servicios y contextos dentro de un entorno de pipeline de Jenkins. Estos elementos trabajan conjuntamente para proporcionar un acceso controlado y eficiente a los recursos compartidos y servicios dentro del pipeline, asegurando al mismo tiempo la extensibilidad y la modularidad del diseño.
class ContextSinglenton {
private static PipelineContext instance
private ContextSinglenton() {
// constructor privado
}
static synchronized ContextSinglenton getInstance() {
if (instance == null) {
instance = new PipelineContext()
}
return instance
}
}
@FunctionalInterface
interface IServiceFactory {
IService create(IPipelineContext pipeline);
}
class ServiceFactory implements IServiceFactory {
private final Closure<IService> closure
private ServiceFactory(Closure<IService> closure) {
this.closure = closure
}
@Override
IService create(IPipelineContext pipeline) {
return closure.call(pipeline)
}
static ServiceFactory from(Closure<IService> closure) {
return new ServiceFactory(closure)
}
}
Veamos cada uno en detalle:
ContextSingleton: Guardian del Contexto Único
ContextSingleton es una implementación del patrón de diseño Singleton, aplicado específicamente para mantener una única instancia de PipelineContext a través de toda la ejecución del pipeline. Este enfoque garantiza que todos los componentes del sistema compartan un mismo contexto, facilitando la gestión centralizada del estado y la configuración.
-
Constructor Privado: Asegura que
ContextSingletonno pueda ser instanciado directamente, reforzando el control sobre la creación de la instancia del contexto. -
getInstance(): Este método proporciona un punto de acceso global a la única instancia dePipelineContext. La sincronización asegura que la instancia sea segura en entornos concurrentes, previniendo la creación de múltiples instancias en escenarios de multihilo.
ServiceFactory: Fábrica de Servicios Dinámicos
ServiceFactory es una implementación concreta de IServiceFactory, diseñada para crear servicios de manera flexible utilizando clausuras de Groovy. Esto permite definir la lógica de creación de servicios de forma dinámica, sin necesidad de subclases específicas para cada tipo de servicio.
-
Constructor Privado con Clausura: Al tomar una clausura (
Closure<IService>) como argumento,ServiceFactoryencapsula la lógica específica de creación del servicio, permitiendo una gran flexibilidad en cómo se instancian los servicios. -
create(IPipelineContext pipeline): Implementa el método definido porIServiceFactory, invocando la clausura proporcionada para crear y retornar una nueva instancia de un servicio, pasando el contexto del pipeline como argumento. Esto facilita la inyección de dependencias y permite que el servicio acceda al contexto del pipeline para su configuración y operación. -
from(Closure<IService> closure): Método estático que facilita la creación deServiceFactory, proporcionando una interfaz fluida y fácil de usar para definir fábricas de servicios basadas en clausuras.
IServiceFactory: Definiendo el Contrato de Fábricas de Servicios
IServiceFactory es una interfaz funcional que define un contrato único para la creación de servicios, especificando el método create(IPipelineContext pipeline). Este contrato asegura que cualquier implementación de IServiceFactory pueda crear servicios que tengan acceso y puedan interactuar con el contexto del pipeline, promoviendo un diseño cohesivo y modular.
La combinación de ContextSingleton, ServiceFactory, y IServiceFactory en la arquitectura del sistema proporciona un mecanismo robusto y flexible para la gestión de servicios dentro de los pipelines de Jenkins. ContextSingleton asegura una gestión centralizada y consistente del contexto del pipeline, mientras que ServiceFactory y IServiceFactory ofrecen una metodología extensible y adaptable para la creación de servicios. Este diseño fomenta la reutilización de código, la modularidad y la facilidad de mantenimiento, características esenciales para el desarrollo sostenible de sistemas de CI/CD complejos.
6. Implementación de Clases Wrappers: Vistiendo a Tus Herramientas
Envolver tus herramientas de construcción (como Maven o npm) en clases es como ponerle un esmoquin a un pingüino. No solo se ve mejor, sino que también te permite manejarlas con más gracia. Estas clases actúan como traductores entre tú y tus herramientas, asegurando que la comunicación sea fluida y sin malentendidos.
En este caso, estamos hablando de ponerle un esmoquin a Maven, esa herramienta de construcción tan esencial como escurridiza, a través de nuestra distinguida colección de clases MavenTool y sus clases acompañantes que detallan partes de sus relaciones con otras abstracciones.
class Resource implements Serializable {
String id
String name
}
interface IMavenTool extends IBuildTool<MavenArtifact, MavenFileDefinition> {
def readPom()
}
class MavenTool extends Steps implements IMavenTool {
public static final String TOOL_NAME = 'mvn'
private String mavenDefaultArgs
private String mavenSettingsPath
private String pomXmlPath
private String settingsFileId
private Boolean debugMode
MavenTool(IPipelineContext pipeline) {
super(pipeline)
}
@Override
String execute(String taskName, List<String> options) {
def args = mavenDefaultArgs + options.join(' ')
def workDir = new File(pomXmlPath).getParent() ?: '.'
steps.dir(workDir) {
String tool = debugMode ? "${TOOL_NAME} -X" : TOOL_NAME
steps.sh(script: "${tool} -s '${mavenSettingsPath}' ${taskName} ${args}".trim(), returnStdout: true)
}
}
@Override
MavenArtifact build(List<String> options) {
execute('package', ['-DskipTests'] + options)
MavenFileDefinition definition = readFileDefinition()
return new MavenArtifact(
id: "${definition.groupId}:${definition.artifactId}:${definition.version}",
name: definition.artifactId,
domain: definition.groupId,
version: definition.version
)
}
private void copyMavenSettingsFile() {
if (!steps.fileExists(file: mavenSettingsPath)) {
steps.configFileProvider([steps.configFile(fileId: settingsFileId, variable: 'FILE')]) {
steps.sh("cp -p '${steps.env.FILE}' '${mavenSettingsPath}'")
}
}
}
@Override
void publish(ArtifactRepository repository, MavenArtifact artifact) {
execute("verify org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy", [
"-DaltDeploymentRepository=${repository.id}::${repository.baseUrl}/${repository.name}"
])
}
@Override
MavenFileDefinition readFileDefinition() {
def pom = steps.readMavenPom(file: pomXmlPath)
def groupId = pom.groupId ?: pom.parent.groupId
def definition = new MavenFileDefinition(
id: "${groupId}:${pom.artifactId}",
name: "${groupId}:${pom.artifactId}",
artifactId: pom.artifactId,
groupId: groupId,
version: pom.version,
dependencies: pom.dependencies
)
return definition
}
@Override
def readPom() {
return readFileDefinition()
}
@Override
MavenFileDefinition writeVersion(String overrideVersion) {
execute('versions:set', ["-DnewVersion=${overrideVersion}"])
return readFileDefinition()
}
@NonCPS
@Override
void initialize(IConfigClient configClient) {
this.mavenSettingsPath = configClient.optional('maven.settingsPath', String.class)
this.pomXmlPath = configClient.optional('maven.pomXmlPath', String.class)
this.settingsFileId = configClient.required('maven.settingsFileId', String.class)
this.debugMode = configClient.optional('maven.debug', Boolean.class)
this.mavenDefaultArgs = configClient.optional('maven.args', String.class)
copyMavenSettingsFile()
}
}
La clase MavenTool, que extiende Steps e implementa IMavenTool, es un elegante puente entre el mundo de Jenkins y Maven, diseñado para orquestar operaciones de Maven dentro de los pipelines de Jenkins con precisión y flexibilidad. Vamos a desglosar el propósito y el sentido de sus funciones clave para entender mejor cómo esta clase se convierte en un maestro de ceremonias para tus proyectos Maven.
Constructor y Configuración Inicial
MavenTool(IPipelineContext pipeline) {
super(pipeline)
}
El constructor inyecta el contexto del pipeline actual, permitiendo a MavenTool acceder a funciones y variables definidas en el pipeline, un primer paso crucial para establecer el terreno de juego donde MavenTool ejecutará sus hazañas.
Ejecución de Comandos Maven
String execute(String taskName, List<String> options)
Este método es el corazón de MavenTool, permitiendo la ejecución de cualquier tarea Maven especificada por taskName, con opciones adicionales para personalizar el comportamiento de Maven. Maneja la configuración del entorno de trabajo y ajusta el modo de depuración basándose en debugMode, demostrando una flexibilidad esencial para adaptarse a diferentes necesidades y contextos de construcción.
Construcción de Artefactos
MavenArtifact build(List<String> options)
Aquí, MavenTool toma el papel de constructor, compilando el código y generando un MavenArtifact. Este método encapsula no solo la compilación sino también la creación de un objeto MavenArtifact que representa el artefacto construido, ilustrando cómo MavenTool sirve como una interfaz coherente entre Jenkins y el ecosistema de Maven.
Publicación de Artefactos
void publish(ArtifactRepository repository, MavenArtifact artifact)
publish extiende la funcionalidad de MavenTool al mundo exterior, permitiendo la publicación de artefactos a un repositorio especificado. Este método subraya la capacidad de MavenTool para interactuar con infraestructuras de almacenamiento de artefactos, facilitando la integración y entrega continuas.
Lectura y Manipulación de pom.xml
MavenFileDefinition readFileDefinition()
Este método abstrae la complejidad de leer y analizar el archivo pom.xml de Maven, retornando una representación simplificada que puede ser fácilmente manipulada y consultada, lo que demuestra la habilidad de MavenTool para servir como un intermediario inteligente entre Jenkins y la configuración de Maven.
MavenFileDefinition writeVersion(String overrideVersion)
Aquí, MavenTool muestra su capacidad para no solo leer sino también modificar la configuración de Maven, específicamente para actualizar la versión del proyecto en el pom.xml. Este método es un ejemplo de cómo MavenTool facilita la gestión de versiones dentro de los pipelines de Jenkins.
Inicialización y Configuración
@NonCPS
void initialize(IConfigClient configClient)
La inicialización aprovecha IConfigClient para configurar MavenTool según las necesidades específicas del proyecto, desde rutas de archivos hasta modos de depuración. La anotación @NonCPS asegura que este método se ejecute sin problemas en el entorno de Groovy CPS de Jenkins, evitando problemas de serialización y subrayando el diseño cuidadoso de MavenTool para operar dentro de las limitaciones técnicas de Jenkins.
Conclusión
MavenTool es una abstracción sofisticada que encapsula y simplifica la interacción con Maven dentro de los pipelines de Jenkins. Su diseño y sus métodos reflejan un profundo entendimiento de las necesidades de automatización y gestión de artefactos en el desarrollo de software moderno. Al proporcionar una interfaz coherente y flexible para ejecutar tareas de Maven, leer y modificar el pom.xml, y manejar la publicación de artefactos, MavenTool no solo mejora la eficiencia y la claridad en los pipelines de Jenkins sino que también fortalece la integración entre Jenkins y el ecosistema de Maven, demostrando por qué la creación de estas abstracciones es una inversión valiosa en la calidad y mantenibilidad del proceso de desarrollo de software.
MavenArtifact, un tipo de artefacto.
Toda herramienta que implementa IBuildTool genera un artefacto y una implementación de un artefacto para maven no iba a ser menos:
class Artifact extends Resource {
protected String domain
protected String version
protected String url
}
class MavenArtifact extends Artifact {
String artifactId
String groupId
Boolean isSnapshot() {
return this.version.endsWith("-SNAPSHOT")
}
}
ArtifactRepository:
Ah, ArtifactRepository, la pajarita que completa el conjunto, ofreciendo un lugar donde guardar con seguridad nuestros preciados artefactos. Esta abstracción nos recuerda que, sin importar cuán elegantes seamos, siempre necesitamos un lugar para guardar nuestros secretos más valiosos (y nuestras credenciales).
class ArtifactRepository extends Resource {
String baseUrl
String credentialsId
}
FileDefinition y MavenFileDefinition, abstracciones de tus ficheros de configuración de Build Tools.
FileDefinition y MavenFileDefinition entran en escena ofreciendo una abstracción elegante sobre la configuración de herramientas como Maven, Npm, Gradle, etc. MavenFileDefinition, en particular, se adentra en el corazón del pom.xml de Maven, destilando su esencia en una forma más accesible y manejable, permitiendo que el poder y la complejidad de Maven se manejen con la facilidad de un maestro de orquesta dirigiendo una sinfonía.
class FileDefinition extends Resource {
String version
def dependencies
}
class MavenFileDefinition extends FileDefinition {
String artifactId
String groupId
}
La implementación de abstracciones como MavenTool, FileDefinition, MavenFileDefinition, junto con la definición de interfaces como IBuildTool y la estructuración en torno a entidades como Artifact y ArtifactRepository, representa un enfoque estratégico y metódico para manejar la complejidad inherente a los sistemas de construcción y despliegue de software. Este enfoque no solo facilita la interoperabilidad y extensibilidad dentro del ecosistema de Jenkins sino que también proporciona una base sólida para la escalabilidad y la mantenibilidad del código.
Razones Detrás de las Abstracciones
-
Interoperabilidad Mejorada: Al definir interfaces comunes como
IBuildTool, se establece un contrato que cualquier herramienta de construcción puede implementar, permitiendo queMavenTooly otras herramientas similares para diferentes tecnologías (como Node.js o Gradle) se integren de manera fluida en el flujo de trabajo de Jenkins. Esto asegura que independientemente de la tecnología subyacente, el proceso de integración y despliegue se maneje de manera coherente. -
Abstracción y Encapsulamiento:
FileDefinitionyMavenFileDefinitionsirven como abstracciones sobre configuraciones específicas de herramientas de construcción, como elpom.xmlde Maven. Esto permite manejar la configuración de manera uniforme, reduciendo la dependencia directa del código sobre archivos de configuración específicos y permitiendo cambios en la configuración sin afectar el código que depende de estos. En esencia, proporcionan una capa de abstracción que desacopla la lógica de negocio de los detalles específicos de cada herramienta de construcción. -
Extensibilidad y Flexibilidad: La utilización de clases wrapper como
MavenTooly la definición de entidades comoArtifactyArtifactRepositoryfacilitan la extensión y adaptación del sistema a nuevas herramientas y repositorios. Esto no solo hace que el sistema sea más robusto y adaptable a los cambios sino que también permite incorporar nuevas tecnologías y prácticas sin una revisión completa del código existente. -
Mantenibilidad y Escalabilidad: Mediante la separación de responsabilidades y la definición clara de interfaces y clases, se simplifica la comprensión y mantenimiento del código. Esto hace que el sistema sea más mantenible y escalable, ya que las modificaciones en una parte del sistema tienen un impacto limitado en las demás, y se pueden agregar nuevas funcionalidades con un mínimo esfuerzo de integración.
Conclusión
La creación de estas abstracciones y la implementación de clases wrapper en el contexto de Jenkins y el desarrollo de software en general, no es un ejercicio académico sino una necesidad práctica. Facilitan la gestión de la complejidad, mejoran la capacidad de mantenimiento y escalabilidad del sistema, y proporcionan una plataforma flexible para la integración continua y la entrega continua (CI/CD). En última instancia, estas abstracciones permiten a los equipos de desarrollo centrarse en la lógica de negocio y la entrega de valor, minimizando el tiempo y el esfuerzo dedicados a la gestión de la infraestructura y la configuración de herramientas.
