¿Quieres saber cómo podemos ayudarte?   Agenda tu cita ahora mismo 

Idioma:   English EN Español ES

Puntos clave

  • Siendo DevOps el centro de la industria, los equipos pueden ampliarse al enfoque “como código” un poco más allá de la infraestructura y las configuraciones tradicionales.  
  • Pipelines as Code cambia la manera en la que los desarrolladores se desempeñan en las tareas automatizadas de sus flujos de trabajo, se alejan de un bloqueo de herramientas y se acercan a un modo completamente independiente, todo contenido en un repositorio de código.
  • Los desarrolladores ahora pueden beneficiarse de todas las funciones previamente reservadas a los archivos de código, además de funciones avanzadas, así como plantillas, bucles, etc. Mejorando la manera en la que los pipelines pueden ser usados para desempeñar tareas fuera de la creación y lanzamiento básica. 
  • Adoptar este enfoque, será el nuevo estándar en la ingeniería de software, aumentando así la productividad y dándole un nuevo y mejor nivel de control a desarrolladores.
  • Mientras pueda que tome un poco de tiempo migrar las definiciones al nuevo modelo, los desarrolladores podrán beneficiarse de las herramientas y enfoques de los que ya tienen conocimiento, así como tomar ventaja de los orquestadores de automatización más poderosos.

 

Si podemos observar el estado de las ingenierías de software, está claro que esta industria tuvo muchos cambios similares a los de un camaleón. Lo que antes era muy usado, ahora pasó a ser casi escaso, completamente reemplazado por diferentes herramientas y tecnologías.

 

Si miramos lo que hace 10 años se usaba, recuerdo haber trabajado mucho con sistemas de control de versiones actualizadas, que se limitaba a la elección del sistema operativo que se ejecutaba con una carga de trabajo y, en general una demarcación intensa entre ser “un desarrollador” y trabajar “en infraestructura”.

 

Obviamente las cosas han cambiado, sin embargo, el único y principal factor de perturbación en este campo siempre ha sido Git. Git lo cambió todo- democratizo las buenas prácticas de ingeniería como el control de código de fuentes, y también permitió que una gran cantidad de herramientas fueran construidas desde sus inicios. Evidentemente DevOps jugó un papel clave en todo esto, siendo el pegamento que unió toda una serie de herramientas, enfoques y tecnologías. Resumiendo, esta proliferación que asciende y la adopción de prácticas DevOps, le permitió a la industria pasarse de una manera orgánica a este enfoque “como código (as code en inglés)”

 

Así es como Terraform (y similares) herramientas aparecieron, empujadas por el ecosistema de herramientas y por ser DevOps muy bien adoptada y usada en varias compañías. La infraestructura como código, es ahora omnipresente, y todo proveedor de la nube ofrece capacidades del despliegue de infraestructura con archivos de código y APIs- lo que debería ser la opción predeterminada para cualquier aplicación que no sea una muestra de “Hello World”

 

La infraestructura como código fue solo el comienzo. La configuración como Código apareció luego – una vez más convirtiéndose en algo común y permitiéndole a las organizaciones agrandar su capacidad de ingeniería. Y para poder aumentar el valor generado de los equipos de desarrollo, Pipelines as Code fue la consecuencia más natural. 

 

¿Por qué debería transformar las definiciones de construcción y lanzamiento en código? 

 

Pipelines as Code es la evolución natural de un artefacto clave que los ingenieros usan todos los días. Piensa esto: ¿si tienes infraestructura como código (Infrastructure as Code), configuración como código (Configuration as Code) … por qué no Pipelines como código (Pipelines as Code)?

 

El concepto es simple, en vez de pensar en pipeline como termino de motor CI/CD, puedes expandirlo en ser un orquestador para tu plataforma de desarrollo, y todos los artefactos que sean guardados en archivos de código.

 

Eso proporcionará control de versiones, capacidades de trabajo en equipo, etc. Y así mismo te dará el poder para automatizar todos tus procesos. Y entre más se automatice, la calidad aumenta, la velocidad mejora y su resistencia aumenta también. Es realmente un gran cambio para cualquier equipo de desarrollo.

 

Mira mi sistema de publicación para blogs, está todo alojado en GitHub, y cada vez que publico algo esto es lo que pasa:

 

Dos pipelines (O flujos de trabajo como se dice en GitHub) se ejecutan siempre, uno para publicaciones y otro para actividades, bajo ciertas condiciones. Te preguntarás por qué dos, y por qué el flujo de trabajo CI existe entre el flujo de trabajo de construcción. El primero es personalizado y el segundo está fuera de la caja de publicación. Veamos el que está personalizado.

 

 

name: CI

 

# Controls when the action will run. Triggers the workflow on push or pull request

# events but only for the master branch

on:

  push:

    branches: [ master ]

 

# A workflow run is made up of one or more jobs that can run sequentially or in parallel

jobs:

  # This workflow contains a single job called “build”

  build:

    if: “!contains(github.event.head_commit.message, ‘NO CI’)”

    # The type of runner that the job will run on

    runs-on: ubuntu-latest

 

    # Steps represent a sequence of tasks that will be executed as part of the job

    steps:

    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it

    – uses: actions/[email protected]

 

    – name: Send Tweet Action

      uses: ethomson/[email protected]

      with:

        # The status (“tweet”) to post to twitter.

        status: “Blogged! ${{ github.event.head_commit.message }} – https://mattvsts.github.io #mvpbuzz #AzureDevOps @AzureDevOps @GitHub”

        # Consumer API key, available in the “Keys and tokens” section of your application in the Twitter Developer site.

        consumer-key: ${{ secrets.TWITTER_CONSUMER_API_KEY }}

        consumer-secret: ${{ secrets.TWITTER_CONSUMER_API_SECRET }}

        access-token: ${{ secrets.TWITTER_ACCESS_TOKEN }}

        access-token-secret: ${{ secrets.TWITTER_ACCESS_TOKEN_SECRET }}

 

 

Este flujo de trabajo twittea automáticamente en mi nombre. Se ejecuta siempre, a no ser que algún commit contenga “NO CI” en el mensaje. Es un archivo de código y esté almacenado en mi repositorio. Si lo llego a mover de mi cuenta a otro repositorio, seguirá funcionando igual sin ningún problema.

 

Todos los orquestadores de CI/CD van en esta dirección: Azure PipelinesGitHub ActionsJenkins, etc. La interfaz de usuario ya deja de ser un foco, y el Pipelines as Code permite varias ventajas muy específicas para el desarrollador.

Los beneficios de Pipelines as Code

 

Siendo sólo código significa que tus pipelines se beneficiarán de todas las herramientas que ya son usadas en cualquier organización de ingeniería. Esto incluye control de versiones, los pull requests, el branching, etc. Los desarrolladores sabrán como lidiar con código, así que los pipelines solo serán otro artefacto almacenado en Git. 

 

Esto también facilita un gran número de situaciones donde debes mantener la trazabilidad, auditabilidad, etc. mientras se mantiene un fácil acceso y familiaridad. Una vez más, Pipelines as Code significa que todo es almacenado con un acceso de control e historial completo, mientras se mantiene la facilidad de uso y repetibilidad.

 

Finalmente, portabilidad. Sí, hay dialectos diferentes de Pipelines as Code dependiendo de la plataforma de destino, sin embargo, el concepto permanece igual en todos los ámbitos. Pienso en GiftHub Actions y Azure Pipelines, por ejemplo- los dos son basados en YAML con diferente sintaxis y algunas peculiaridades. Al menos un día se toma un desarrollador para ponerse al día con todo y máximo una semana para sentirse cómodo con las diferencias. El aumento en la productividad es increíble, como ya no hay diferencia entre un pipeline de compilación y de lanzamiento. Todo está en un conjunto de tareas orquestadas hecho por el mismo motor.

 

Hay algunas funciones avanzadas para cada orquestador moderno. Las plantillas son comunes ahora, y realmente un salvavidas. Podrás definir un pipeline una vez y reutilizarlo en muchas más automatizaciones y proyectos con cambios mínimos. Tu plantilla contendrá toda la lógica, y todas las posibles configuraciones- en las que lo invocarás desde tu pipeline principal. Echémosle un vistazo.

 

Esto será una plantilla, llamada template.yml en tu repositorio:

 

 

parameters:

  input : []

steps:

  – ${{ each p in parameters.input }}:

    – script: ‘echo ${{ p }}’

 

 

Esta plantilla soporta un array de entrada, y transmitirá los elementos individuales que hacen al array uno por uno usando una tarea de línea de comandos. Es de simple lógica, sin embargo, entre un pipeline puedes ir usando construcciones más complejas para bucles for (a través de la palabra clave each) y te permitirá componer dinámicamente muchas tareas como elementos el array de entrada tenga. 

Ahora, si lo invocas desde otro pipeline, esto es lo único que tendrás que hacer:

 

 

steps:

– template: template.yml

  parameters:

    input: [“Pipelines”, “Azure DevOps”, “Demo”, “Pipelines as Code”]

 

 

La salida de este Pipeline principal es la siguiente:

 

 

Cuatro tareas de líneas de comando generadas “on demand”, mostrando los valores. Todo orquestado a la vista.

Otra función que me gusta es la Matrix en Azure Pipelines, por ejemplo:

 

 

 

strategy:

  matrix:

   ‘Ubuntu 18.04’:

      image: ‘ubuntu-18.04’

    ‘Ubuntu latest version’:

      image: ‘ubuntu-latest’

    ‘MacOS X 10.15’:

      image: ‘macos-10.15’

    ‘MacOS X latest version’:

      image: ‘macos-latest’

    ‘Windows Server 2016’:

      image: ‘vs2017-win2016’

    ‘Windows Server 2019’:

      image: ‘windows-2019’

 

pool:

  vmImage: $(imageName)

 

steps:

 

 

Este pedazo ejecutará las tareas específicas en la sección de pasos entre tres pipelines diferentes, cada uno ejecutando un agente diferente con distintos sistemas operativos. Esto es todo lo que debería necesitarse.

 

No hay que decir que todo es tan fácil y sencillo – hay una curva de aprendizaje. Como es de lógica, el mayor obstáculo que se tendrá que superar es la falta de una UI (interfaz de usuario). Por al menos una década, nuestros orquestadores de compilación dependían mucho en interfaces de usuarios para hacer el proceso más simple. Como industria, hemos sentado la expectativa de que la UI tenía que estar ahí para poder hacer las cosas más fáciles de digerir.

 

Luego el movimiento “as code” llegó, y empezó a abrirse paso. Infrastructure as Code fue el primero en incursionar, luego todo empezó a seguir todo lo demás. Adelantando 10 años, ahora somos capaces de lidiar con el hecho de que las UIs (Interfaces de usuario) ya no tienes las mejores funciones y opciones, en cambio, se convierte en una puerta de un orquestador de compilación para poder aprender las funcionalidades principales antes de pasarse a la implementación de as code.  

 

Otro factor de cambio importante es el hecho de que ahora todo se ejecuta en un pipeline, sin que haya ninguna distinción entre compilación y lanzamiento. Está a decisión del desarrollador de definir estos límites, y migrar puede tomar un poco de trabajo ya que no habrá un mapeo 1:1 para todo. Sin embargo, este es un trabajo ligero, así que no es un obstáculo tan grande.

¿Qué he aprendido?

 

Después de haber trabajado en muchas plataformas, te darás cuenta que algunos patrones y enfoques son reutilizables. Sin embargo, la principal lección aprendida es sobre tener el hábito de implementar Pipelines as Code lo más rápido que se pueda. Crear la definición de construcción debería ser lo primero que un ingeniero haga, porque evolucionará con el código de aplicación y dará una experiencia mucho más perfecta una vez sea usada en plataformas DevOps.

 

Un típico ejemplo de esto: tener definiciones de pipeline incrustada en tus repositorios de código significa que los repositorios serán inmediatamente granulares e independientes, porque no solo contendrán el código de fuente para la aplicación sino también la definición de construcción que se necesita para compilar y desplegar dicha aplicación, haciéndolo un artefacto que se mueva a través de plataformas DevOps. El desarrollo de microservicios se vuelve mucho más fácil. Las pruebas se vuelven más simples. La automatización de las tareas mundanas puede aportar mucho valor adicional al equipo, dándole a cualquier ingeniero más enfoque en la resolución de problemas reales en lugar de repetir los mismos pasos a cada rato. Pipelines as Code logra hacer maravillas

Conclusión

 

Cambiarse a Pipelines as Code no pasa de la noche a la mañana, pero puede abrir muchas puertas y caminos a tu equipo de desarrollo. Si apenas empiezas en esto, lo primero que puedes hacer es – tomar uno de tus procesos de construcción y lanzamiento y empezar a replicarlo en archivos de código. Es tan simple como eso. Entre más empieces a automatizar los procesos, más empezarás a usar está opción como la determinada y te ahorrarás un montón de tiempo que de alguna manera se ve perdido en tareas repetitivas 

 

Hacerlo, te guiará naturalmente a automatizar todos los pasos en los que te habías estado frenando, todo esto con el beneficio de la experiencia de desarrollo a lo que los ingenieros están acostumbrados. Los cambios se vuelven más fáciles de encontrar, la fusión es simple y se empareja con un proceso de revisión por pares, será de fácil acceso para los desarrolladores.

 

Tomado de la web:

Traducido al español por Estefanía Morales Rodríguez de Devops Latam.

 

Contribuido por Matteo Emili  – Publicado el 8 de Julio de 2022 – https://www.infoq.com/articles/workflow-pipelines-as-code/

Leave a Reply

Tu dirección de correo electrónico no será publicada.