{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Gu\u00eda para principiantes: creando un pipeline de DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si eres nuevo en DevOps, echa un vistazo a esta gu\u00eda para crear tu primer pipeline en cinco pasos.<\/i><\/p>\n

\"Gu\u00eda<\/p>\n

DevOps se ha convertido en la soluci\u00f3n est\u00e1ndar para solucionar procesos de desarrollo de software lentos, fragmentados o ineficaces. El problema es que, si eres nuevo en DevOps y no sabes por d\u00f3nde empezar, es posible que te falte comprensi\u00f3n sobre estos m\u00e9todos. En este art\u00edculo se definir\u00e1 qu\u00e9 es un pipeline de DevOps y se ofrecer\u00e1 una gu\u00eda para crear uno en cinco pasos. Aunque este tutorial no es exhaustivo, deber\u00eda proporcionarte una base para comenzar tu camino y expandir tus conocimientos en el futuro. Comencemos con un poco de historia.<\/p>\n

Mi viaje por DevOps<\/h3>\n

\nAntes trabajaba en el equipo de nube de Citi Group, desarrollando una aplicaci\u00f3n web Infrastructure-as-a-Service (IaaS) para gestionar la infraestructura en la nube de Citi, pero siempre me interes\u00f3 c\u00f3mo hacer que el proceso de desarrollo fuera m\u00e1s eficiente y c\u00f3mo promover cambios culturales positivos en el equipo de desarrolladores. Encontr\u00e9 la respuesta en un libro recomendado por Greg Lavender, director t\u00e9cnico de arquitectura e infraestructura en la nube de Citi. El libro se llama \u201cEl Proyecto F\u00e9nix\u201d (The Phoenix Project<\/a><\/noindex>), y en \u00e9l se explican los principios de DevOps, present\u00e1ndose como una novela.<\/p>\n

En la tabla en la contraportada del libro se muestra la frecuencia con la que las diferentes compa\u00f1\u00edas implementan sus sistemas en el entorno de lanzamiento de versiones:<\/p>\n

Amazon: 23,000 por d\u00eda
\nGoogle: 5,500 por d\u00eda
\nNetflix: 500 por d\u00eda
\nFacebook: Una vez al d\u00eda
\nTwitter: 3 veces a la semana
\nCompa\u00f1\u00eda t\u00edpica: Una vez cada 9 meses<\/p>\n

\u00bfC\u00f3mo es posible que Amazon, Google y Netflix logren tales frecuencias? Todo porque estas empresas han ideado c\u00f3mo crear un pipeline de DevOps casi perfecto.
\n<\/a><\/noindex>
\nEst\u00e1bamos lejos de ello hasta que implementamos DevOps en Citi. En ese momento, mi equipo trabajaba en diferentes entornos, pero el despliegue en el servidor de desarrollo era completamente manual. Todos los desarrolladores ten\u00edan acceso solo a un servidor de desarrollo basado en IBM WebSphere Application Server Community Edition. El problema era que el servidor se apagaba cada vez que varios usuarios intentaban desplegar al mismo tiempo, por lo que los desarrolladores deb\u00edan comunicarse entre s\u00ed sobre sus intenciones, lo cual era bastante doloroso. Adem\u00e1s, exist\u00edan problemas con la baja cobertura de pruebas de c\u00f3digo, procesos de despliegue manual complicados y la falta de capacidad para rastrear el despliegue de c\u00f3digo asociado con una tarea o historia de usuario espec\u00edfica.<\/p>\n

Me di cuenta de que era necesario hacer algo y encontr\u00e9 a un colega af\u00edn. Decidimos colaborar en la creaci\u00f3n del primer canal DevOps; \u00e9l configur\u00f3 una m\u00e1quina virtual y un servidor de aplicaciones Tomcat, mientras yo trabajaba en Jenkins, integrando Atlassian Jira y BitBucket, y tambi\u00e9n mejorando la cobertura de pruebas de c\u00f3digo. Este proyecto paralelo fue muy exitoso: casi automatizamos muchos procesos, logramos casi el 100% de operatividad de nuestro servidor de desarrollo, implementamos rastreo y mejoramos la cobertura de pruebas de c\u00f3digo, as\u00ed como a\u00f1adimos la capacidad de vincular ramas en Git con tareas en Jira o despliegues. La mayor\u00eda de las herramientas que utilizamos para construir nuestro canal DevOps eran de c\u00f3digo abierto.<\/p>\n

Ahora entiendo cu\u00e1n simple era nuestro pipeline DevOps: no utiliz\u00e1bamos extensiones como Jenkins files o Ansible. Sin embargo, este simple canal funcionaba bien, posiblemente gracias al principio de Pareto (tambi\u00e9n conocido como la regla del 80\/20).<\/p>\n

Una breve introducci\u00f3n a DevOps y al pipeline CI\/CD<\/h3>\n

\nSi preguntas a varias personas: \u00ab\u00bfQu\u00e9 es DevOps?\u00bb, probablemente obtendr\u00e1s varias respuestas diferentes. DevOps, al igual que Agile, ha evolucionado para abarcar muchas disciplinas distintas, pero la mayor\u00eda de la gente estar\u00e1 de acuerdo en algunas cosas: DevOps es una pr\u00e1ctica de desarrollo de software o ciclo de vida de desarrollo de software (SDLC), cuyo principio central es un cambio cultural en el que desarrolladores y no desarrolladores coexisten en un entorno en el que:<\/p>\n

Las operaciones que antes se realizaban manualmente est\u00e1n automatizadas;
\nCada uno hace lo que mejor sabe hacer;
\nEl n\u00famero de implementaciones en un per\u00edodo determinado aumenta; La capacidad de trabajo se incrementa;
\nLa flexibilidad del desarrollo se mejora.<\/p>\n

Aunque tener las herramientas de software adecuadas no es lo \u00fanico necesario para crear un entorno DevOps, algunas herramientas son fundamentales. Una herramienta clave es la integraci\u00f3n y despliegue continuos (CI\/CD). En este pipeline, los entornos tienen diferentes etapas (por ejemplo, DEV, INT, TST, QA, UAT, STG, PROD), muchas operaciones est\u00e1n automatizadas y los desarrolladores pueden escribir c\u00f3digo de alta calidad, lograr flexibilidad en el desarrollo y una alta frecuencia de despliegues.<\/p>\n

Este art\u00edculo describe un enfoque de cinco etapas para crear un pipeline DevOps, similar al representado en el siguiente diagrama, utilizando herramientas de c\u00f3digo abierto.<\/p>\n

Paso 1: M\u00e9todos de CI\/CD<\/h3>\n

\nLo primero que necesitas es una herramienta para CI\/CD. Jenkins, una herramienta de c\u00f3digo abierto basada en Java y distribuida bajo la licencia MIT, es el medio que ha popularizado la direcci\u00f3n de DevOps y se ha convertido en el est\u00e1ndar de facto.<\/p>\n

\u00bfEntonces, qu\u00e9 es Jenkins? Piensa en ello como un tipo de control remoto m\u00e1gico que puede comunicarse con varios servicios y herramientas y organizarlos. Una herramienta de CI\/CD como Jenkins por s\u00ed sola es in\u00fatil, pero se vuelve m\u00e1s poderosa a medida que se conecta a diversas herramientas y servicios.<\/p>\n

Jenkins es solo una de las muchas herramientas de c\u00f3digo abierto para CI\/CD que puedes usar para construir un pipeline DevOps.<\/p>\n

Jenkins: Creative Commons y MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

As\u00ed es como se ven los procesos de DevOps con una herramienta de CI\/CD:<\/p>\n

\"Gu\u00eda<\/p>\n

Tienes una herramienta de CI\/CD funcionando en tu localhost, pero por ahora, no puedes hacer mucho. Vamos a pasar a la siguiente etapa del viaje al mundo de DevOps.<\/p>\n

Paso 2: Gesti\u00f3n de sistemas de control de versiones<\/h3>\n

\nLa mejor (y probablemente la m\u00e1s sencilla) manera de comprobar que tu herramienta de CI\/CD puede hacer magia es integrarse con una herramienta de control de c\u00f3digo fuente (SCM). \u00bfPor qu\u00e9 necesitas control sobre el c\u00f3digo fuente? Supongamos que est\u00e1s desarrollando una aplicaci\u00f3n. Cada vez que creas una aplicaci\u00f3n, est\u00e1s programando, independientemente de si usas Java, Python, C++, Go, Ruby, JavaScript o cualquiera de los miles de lenguajes de programaci\u00f3n. El c\u00f3digo que escribes se llama c\u00f3digo fuente. Al principio, especialmente cuando trabajas solo, probablemente puedes poner todo en un directorio local. Pero cuando el proyecto crece y comienzas a invitar a otras personas a colaborar, necesitas una forma de prevenir conflictos y compartir modificaciones de manera efectiva. Tambi\u00e9n necesitas una manera de restaurar versiones anteriores, porque hacer copias de seguridad y copiar\/pegar en ellas ya est\u00e1 obsoleto. T\u00fa (y tus compa\u00f1eros de equipo) necesitan algo mejor.<\/p>\n

Es aqu\u00ed donde una herramienta de control de c\u00f3digo fuente se vuelve pr\u00e1cticamente indispensable. Esta herramienta almacena tu c\u00f3digo en repositorios, lleva un registro de versiones y coordina el trabajo de los miembros del proyecto.<\/p>\n

Aunque hay muchas herramientas de control de c\u00f3digo fuente, Git es el est\u00e1ndar, y esto es cierto. Recomiendo encarecidamente usar Git, aunque, si lo prefieres, hay otras opciones de c\u00f3digo abierto.<\/p>\n

Git: GPLv2 y LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

As\u00ed es como se ve un pipeline de DevOps con la adici\u00f3n de herramientas de control de c\u00f3digo fuente.<\/p>\n

\"Gu\u00eda<\/p>\n

Una herramienta de CI\/CD puede automatizar los procesos de verificaci\u00f3n, obtenci\u00f3n de c\u00f3digo fuente y colaboraci\u00f3n entre miembros. \u00bfNo est\u00e1 mal? Pero, \u00bfc\u00f3mo convertir esto en una aplicaci\u00f3n funcional que miles de millones de personas puedan usar y disfrutar?<\/p>\n

Paso 3: Crear una herramienta de automatizaci\u00f3n de compilaci\u00f3n<\/h3>\n

\n\u00a1Excelente! Puedes revisar el c\u00f3digo y hacer cambios en el sistema de control de versiones, as\u00ed como invitar a tus amigos a colaborar en el desarrollo. Sin embargo, a\u00fan no has creado una aplicaci\u00f3n. Para crear una aplicaci\u00f3n web, debe ser compilada y empaquetada en un formato de paquete implementable o ejecutarse como un archivo ejecutable. (Ten en cuenta que un lenguaje de programaci\u00f3n interpretado, como JavaScript o PHP, no necesita ser compilado).<\/p>\n

Utiliza la herramienta de automatizaci\u00f3n de compilaci\u00f3n. Independientemente de qu\u00e9 herramienta de automatizaci\u00f3n de compilaci\u00f3n elijas, todas persiguen el mismo objetivo: compilar el c\u00f3digo fuente en el formato deseado y automatizar la tarea de limpieza, compilaci\u00f3n, prueba e implementaci\u00f3n en un entorno espec\u00edfico. Las herramientas de compilaci\u00f3n variar\u00e1n seg\u00fan tu lenguaje de programaci\u00f3n, pero aqu\u00ed hay algunas opciones comunes de c\u00f3digo abierto.<\/p>\n

Nombre
\nLicencia
\nLenguaje de programaci\u00f3n<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

\u00a1Genial! Puedes colocar los archivos de configuraci\u00f3n de la herramienta de automatizaci\u00f3n de compilaci\u00f3n en el sistema de control de versiones y permitir que tu herramienta CI\/CD los re\u00fana todos.<\/p>\n

\"Gu\u00eda<\/p>\n

Todo bien, \u00bfverdad? Pero, \u00bfd\u00f3nde implementar\u00e1s tu aplicaci\u00f3n?<\/p>\n

Paso 4: Servidor para aplicaciones web<\/h3>\n

\nHasta ahora, tienes un archivo empaquetado que puede ser tanto ejecutable como instalable. Para que cualquier aplicaci\u00f3n sea realmente \u00fatil, debe ofrecer alg\u00fan servicio o interfaz, pero necesitas un contenedor para alojar tu aplicaci\u00f3n.<\/p>\n

El servidor para aplicaciones web es precisamente ese contenedor. El servidor proporciona un entorno donde se puede definir la l\u00f3gica del paquete implementado. Tambi\u00e9n proporciona una interfaz y ofrece servicios web, abriendo sockets al mundo exterior. Necesitas un servidor HTTP, as\u00ed como alg\u00fan entorno (por ejemplo, una m\u00e1quina virtual) para implementarlo. Mientras tanto, asumamos que aprender\u00e1s m\u00e1s sobre esto m\u00e1s adelante (aunque hablar\u00e9 sobre contenedores m\u00e1s abajo).<\/p>\n

Existen varios servidores de aplicaciones web de c\u00f3digo abierto.<\/p>\n

Nombre
\nLicencia
\nLenguaje de programaci\u00f3n<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Tu pipeline de DevOps est\u00e1 casi listo para usar. \u00a1Buen trabajo!<\/p>\n

\"Gu\u00eda<\/p>\n

Aunque se puede detener aqu\u00ed y encargarse de la integraci\u00f3n por cuenta propia, la calidad del c\u00f3digo es un aspecto importante para cualquier desarrollador de aplicaciones y debe ser una preocupaci\u00f3n constante.<\/p>\n

Paso 5: Cobertura de pruebas de c\u00f3digo<\/h3>\n

\nLa implementaci\u00f3n de pruebas puede ser otro requisito engorroso, pero los desarrolladores deben detectar cualquier error en la aplicaci\u00f3n en una etapa temprana y mejorar la calidad del c\u00f3digo para garantizar que los usuarios finales est\u00e9n satisfechos. Afortunadamente, existen muchas herramientas de c\u00f3digo abierto para probar su c\u00f3digo y generar recomendaciones para mejorar su calidad. A\u00fan mejor, la mayor\u00eda de las herramientas CI\/CD pueden conectarse a estas herramientas y automatizar el proceso.<\/p>\n

Las pruebas de c\u00f3digo constan de dos partes: los marcos de prueba que ayudan a escribir y ejecutar pruebas, as\u00ed como herramientas de sugerencia que ayudan a mejorar la calidad del c\u00f3digo.<\/p>\n

Sistemas de pruebas de c\u00f3digo<\/b><\/p>\n

Nombre
\nLicencia
\nLenguaje de programaci\u00f3n<\/p>\n

JUnit
\nLicencia P\u00fablica de Eclipse
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Sistemas de sugerencias para mejorar el c\u00f3digo<\/b><\/p>\n

Nombre
\nLicencia
\nLenguaje de programaci\u00f3n<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nLicencia P\u00fablica Com\u00fan
\nJava<\/p>\n

JaCoCo
\n Licencia P\u00fablica de Eclipse
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Tenga en cuenta que la mayor\u00eda de las herramientas y marcos mencionados anteriormente est\u00e1n escritos para Java, Python y JavaScript, ya que C++ y C# son lenguajes de programaci\u00f3n propietarios (aunque GCC tiene c\u00f3digo abierto).<\/p>\n

Ahora que ha implementado las herramientas de cobertura de c\u00f3digo, su pipeline de DevOps deber\u00eda parecerse al diagrama mostrado al principio de esta gu\u00eda.<\/p>\n

Pasos adicionales<\/h3>\n

\nContenedores<\/b><\/p>\n

Como mencion\u00e9 anteriormente, puede alojar su servidor en una m\u00e1quina virtual o en un servidor, pero los contenedores son una soluci\u00f3n popular.<\/p>\n

\u00bfQu\u00e9 son los contenedores? La breve explicaci\u00f3n es que una m\u00e1quina virtual necesita una gran cantidad de memoria del sistema operativo, que supera el tama\u00f1o de la aplicaci\u00f3n, mientras que un contenedor solo necesita algunas bibliotecas y configuraciones para ejecutar la aplicaci\u00f3n. Es evidente que las m\u00e1quinas virtuales todav\u00eda tienen \u00e1reas de aplicaci\u00f3n importantes, pero un contenedor es una soluci\u00f3n ligera para alojar aplicaciones, incluidas las aplicaciones servidoras.<\/p>\n

Aunque existen otras opciones de contenedores, las m\u00e1s populares son Docker y Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Herramientas de automatizaci\u00f3n intermedias<\/b><\/p>\n

Nuestro pipeline de DevOps se centra principalmente en la creaci\u00f3n y despliegue colaborativo de aplicaciones, pero hay muchas otras cosas que se pueden hacer con herramientas de DevOps. Una de ellas es el uso de herramientas de Infraestructura como C\u00f3digo (IaC), que tambi\u00e9n se conocen como herramientas de automatizaci\u00f3n intermedia. Estas herramientas ayudan a automatizar la instalaci\u00f3n, gesti\u00f3n y otras tareas para software intermedio. Por ejemplo, una herramienta de automatizaci\u00f3n puede extraer aplicaciones como servidores de aplicaciones web, bases de datos y herramientas de monitoreo, configurarlas correctamente y desplegarlas en el servidor de aplicaciones.<\/p>\n

Aqu\u00ed hay algunas herramientas de automatizaci\u00f3n intermedia de c\u00f3digo abierto:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache o GPL<\/p>\n

\"Gu\u00eda<\/p>\n

Descubre m\u00e1s sobre c\u00f3mo obtener una profesi\u00f3n demandada desde cero o mejorar tus habilidades y salario con los cursos online de pago de SkillFactory:<\/p>\n