Guía para principiantes: construcción de una tubería de DevOps

Si es nuevo en DevOps, eche un vistazo a este tutorial sobre cómo crear su primera tubería de cinco pasos.







DevOps se ha convertido en la solución estándar para reparar procesos de desarrollo de software lentos, desconectados o rotos. El problema es que si eres nuevo en DevOps y no sabes por dónde empezar, es posible que no entiendas estas técnicas. Este artículo lo guiará a través de la definición de una tubería de DevOps y proporcionará instrucciones sobre cómo crearlo en cinco pasos. Si bien este tutorial no es exhaustivo, debería proporcionarle una base para comenzar y ampliar sus conocimientos en el futuro. Pero comencemos con la historia.

My DevOps Journey

Solía ​​trabajar en el equipo en la nube del Grupo Citi desarrollando una aplicación web de Infraestructura como Servicio (IaaS) para administrar la infraestructura en la nube de Citi, pero siempre me he preguntado cómo hacer que el proceso de desarrollo sea más eficiente y traer un cambio cultural positivo al equipo de desarrollo. Encontré la respuesta en un libro recomendado por Greg Lavender, el CTO de Citi para Cloud Architecture and Infrastructure. El libro se tituló The Phoenix Project y explica los principios de DevOps mientras se lee como una novela.



La tabla al final del libro muestra con qué frecuencia las diferentes compañías implementan sus sistemas en un entorno de lanzamiento:



Amazon: 23,000 por día

Google: 5,500 por día

Netflix: 500 por día

Facebook: una vez al día

Twitter: 3 veces a la semana

Compañía típica: una vez cada 9 meses



¿Cómo son posibles las frecuencias de Amazon, Google y Netflix? Esto se debe a que estas compañías descubrieron cómo crear una tubería DevOps casi perfecta.



Estábamos muy lejos de eso hasta que implementamos DevOps en Citi. Mi equipo tenía diferentes entornos en aquel entonces, pero la implementación en el servidor de desarrollo era completamente manual. Todos los desarrolladores tuvieron acceso a un solo servidor de desarrollo basado en IBM WebSphere Application Server Community Edition. El problema era que el servidor se apagaba cuando varios usuarios intentaban desplegarse al mismo tiempo, por lo que los desarrolladores tenían que comunicarse entre sí, lo cual era bastante doloroso. Además, hubo problemas con la cobertura del código de prueba de bajo nivel, los engorrosos procesos de implementación manual y la imposibilidad de rastrear la implementación del código asociado con una tarea específica o una historia de usuario.



Me di cuenta de que necesitaba hacer algo y encontré un colega de ideas afines. Decidimos colaborar en la canalización inicial de DevOps: configuró una máquina virtual y un servidor de aplicaciones Tomcat mientras trabajaba en Jenkins, integró Atlassian Jira y BitBucket, y trabajé en la cobertura del código de prueba. Este proyecto paralelo tuvo mucho éxito: automatizamos casi por completo muchos procesos, logramos un tiempo de actividad de casi el 100% de nuestro servidor de desarrollo, proporcionamos seguimiento y mejoramos la cobertura del código de prueba, y también agregamos la capacidad de vincular sucursales en Git con problemas en Jira o implementaciones. La mayoría de las herramientas que utilizamos para construir nuestro canal de DevOps eran de código abierto.



Ahora entiendo cuán simple era nuestra canalización de DevOps: no utilizamos extensiones como archivos de Jenkins o Ansible. Sin embargo, esta simple tubería funcionó bien, posiblemente debido al principio de Pareto (también conocido como la regla 80/20).

Una introducción rápida a DevOps y la canalización de CI / CD

Si le preguntas a varias personas, “¿Qué es DevOps?”, Entonces probablemente obtendrás varias respuestas diferentes. DevOps, como Agile, ha evolucionado para abarcar muchas disciplinas diferentes, pero la mayoría de la gente estará de acuerdo en algunas cosas: DevOps es una práctica de desarrollo de software o ciclo de vida de desarrollo de software (SDLC) cuyo principio central es cambiar la cultura en la que los desarrolladores y los no desarrolladores existen en un entorno en el que:



Operaciones automatizadas que se realizaron previamente manualmente;

Todos hacen lo que mejor sabe;

El número de implementaciones durante un cierto período de tiempo aumenta; El rendimiento aumenta;

Se aumenta la flexibilidad de desarrollo.



Si bien tener las herramientas de software adecuadas no es lo único que necesita para crear un entorno DevOps, se necesitan algunas herramientas. La herramienta clave es la integración continua y la implementación continua (CI / CD). En este proceso, los entornos tienen diferentes etapas (por ejemplo, DEV, INT, TST, QA, UAT, STG, PROD), muchas operaciones están automatizadas y los desarrolladores pueden escribir código de alta calidad, lograr flexibilidad de desarrollo y alta frecuencia de implementación.



Este artículo describe un enfoque de cinco pasos para construir una tubería DevOps similar al que se muestra en el siguiente diagrama utilizando herramientas de código abierto.

Paso 1: métodos de CI / CD

Lo primero que necesita es una herramienta CI / CD. Jenkins, una herramienta de código abierto basada en Java lanzada bajo la licencia MIT, es la herramienta que popularizó la dirección de DevOps y se convirtió en el estándar de facto.



Entonces, ¿qué es Jenkins? Piense en ello como una especie de control remoto universal mágico que puede hablar y organizar diversos servicios y herramientas. Una herramienta de CI / CD como Jenkins es inútil por sí sola, pero se vuelve más poderosa a medida que se conecta a varias herramientas y servicios.



Jenkins es solo una de las muchas herramientas de CI / CD de código abierto que puede usar para construir su canal de DevOps.



Jenkins: Creative Commons y MIT

Travis CI: MIT

CruiseControl: BSD

Buildbot: GPL

Apache Gump: Apache 2.0

Cabie: GNU



Así es como se ven los procesos DevOps con una herramienta CI / CD:







Tiene una herramienta CI / CD ejecutándose en su host local, pero no hay mucho que pueda hacer en este momento. Pasemos a la siguiente etapa del viaje DevOps.

Paso 2: administrar los sistemas de control de código fuente

La mejor (y posiblemente la forma más fácil) de probar que su herramienta CI / CD puede hacer la magia es integrarse con una herramienta de control de código fuente (SCM). ¿Por qué necesitas control de fuente? Digamos que estás desarrollando una aplicación. Cada vez que crea una aplicación, está programando, no importa si usa Java, Python, C ++, Go, Ruby, JavaScript o cualquiera de los miles de millones de lenguajes de programación. El código que escribes se llama código fuente. Al principio, especialmente cuando trabajas solo, probablemente puedas poner todo en un directorio local. Pero a medida que el proyecto se hace más grande e invita a otras personas a colaborar, necesita una forma de evitar conflictos y compartir modificaciones de manera eficiente. También necesita una forma de restaurar versiones anteriores,porque crear copias de seguridad y copiarlas / pegarlas ya es obsoleto. Usted (y sus compañeros de equipo) necesitan algo mejor.



Aquí es donde el control de la fuente se convierte prácticamente en una necesidad. Esta herramienta almacena su código en repositorios, realiza un seguimiento de las versiones y coordina el trabajo de los participantes del proyecto.



Si bien existen muchas herramientas de control de código fuente, Git es el estándar y con razón. Recomiendo usar Git, aunque hay otras opciones de código abierto si lo desea.



Git: GPLv2 y LGPL v2.1

Subversion:

Sistema de versiones concurrentes Apache 2.0 (CVS): GNU

Vesta: LGPL

Mercurial: GNU GPL v2 +



Así es como se ve una tubería DevOps con controles de código fuente agregados.







La herramienta CI / CD puede automatizar los procesos de verificación, recuperación del código fuente y colaboración entre los miembros. ¿No está mal? Pero, ¿cómo se convierte en una aplicación que funcione para que miles de millones de personas puedan usarla y apreciarla?

Paso 3: crear una herramienta de automatización de compilación

¡Multa! Puede verificar el código y realizar cambios en el sistema de control de código fuente, así como invitar a sus amigos a colaborar en el desarrollo. Pero aún no has creado la aplicación. Para hacer una aplicación web, debe compilarse y empaquetarse en un formato de lote desplegable, o ejecutarse como un archivo ejecutable. (Tenga en cuenta que no es necesario compilar un lenguaje de programación interpretado como JavaScript o PHP).



Use una herramienta de automatización de compilación. Independientemente de la herramienta de automatización de compilación que elija utilizar, todas tienen el mismo objetivo: compilar el código fuente en el formato que desee y automatizar la tarea de limpieza, compilación, prueba e implementación en un entorno específico. Las herramientas de compilación variarán según su lenguaje de programación, pero aquí hay algunas opciones comunes de código abierto.







¡Excelente! Puede colocar los archivos de configuración de la herramienta de automatización de compilación en un sistema de control de código fuente y dejar que su herramienta CI / CD reúna todo.







Está bien, ¿no es así? ¿Pero dónde desplegar su aplicación?

Paso 4: servidor para aplicaciones web

Hasta ahora, tiene un archivo comprimido que puede ser ejecutable o instalable. Para que cualquier aplicación sea realmente útil, debe proporcionar algún tipo de servicio o interfaz, pero necesita un contenedor para alojar su aplicación.



El servidor de aplicaciones web es solo un contenedor de este tipo. El servidor proporciona un entorno en el que se puede definir la lógica del paquete desplegado. El servidor también proporciona una interfaz y ofrece servicios web al abrir sockets al mundo exterior. Necesita un servidor HTTP y un entorno (como una máquina virtual) para instalarlo. Por ahora, supongamos que aprende más sobre esto (aunque hablaré sobre los contenedores a continuación).



Existen varios servidores de aplicaciones web de código abierto.







Su canalización de DevOps está casi lista para usar. ¡Buen trabajo!







Si bien puede detenerse allí e integrarse, la calidad del código es algo importante para que un desarrollador de aplicaciones se preocupe.

Paso 5: cobertura de prueba de código

La implementación de pruebas puede ser otro requisito engorroso, pero los desarrolladores deben detectar cualquier error en la aplicación temprano y mejorar la calidad del código para garantizar que los usuarios finales estén satisfechos. Afortunadamente, existen muchas herramientas de código abierto para probar su código y hacer recomendaciones para mejorar su calidad. Mejor aún, la mayoría de las herramientas de CI / CD pueden conectarse a estas herramientas y automatizar el proceso.



La prueba de código consta de dos partes: marcos de prueba de código que lo ayudan a escribir y ejecutar pruebas, y herramientas de sugerencia que ayudan a mejorar la calidad de su código.



Sistemas de prueba de código







Sistemas de recomendación de mejora de código







Tenga en cuenta que la mayoría de las herramientas y los marcos mencionados anteriormente están escritos para Java, Python y JavaScript, ya que C ++ y C # son lenguajes de programación patentados (aunque GCC es de código abierto).



Ahora que ha implementado herramientas de cobertura de prueba, su canalización de DevOps debería ser similar al diagrama que se muestra al comienzo de este tutorial.

Pasos adicionales

Contenedores



Como dije, puede alojar su servidor en una máquina virtual o servidor, pero los contenedores son una solución popular.



¿Qué son los contenedores? La explicación breve es que una máquina virtual necesita una gran cantidad de memoria del sistema operativo que excede el tamaño de la aplicación, mientras que el contenedor solo necesita unas pocas bibliotecas y configuraciones para ejecutar la aplicación. Obviamente, todavía hay usos importantes para una máquina virtual, pero un contenedor es una solución ligera para alojar una aplicación, incluido un servidor de aplicaciones.



Si bien existen otras opciones de contenedor, las más populares son Docker y Kubernetes.



Docker: Apache 2.0

Kubernetes: middleware de Apache 2.0



Automation



Nuestro canal de DevOps se centra principalmente en la creación conjunta y la implementación de aplicaciones, pero hay muchas otras cosas que se pueden hacer con las herramientas de DevOps. Uno de ellos es el uso de la Infraestructura como herramientas de Código (IaC), que también se conocen como herramientas de middleware. Estas herramientas ayudan a automatizar la instalación, administración y otras tareas para el middleware. Por ejemplo, una herramienta de automatización puede recuperar aplicaciones como el servidor de aplicaciones web, la base de datos y la herramienta de monitoreo con las configuraciones correctas e implementarlas en el servidor de aplicaciones.



Aquí hay algunas herramientas de middleware de código abierto:



Ansible: GNU Public

SaltStack: Apache 2.0

Chef: Apache 2.0

Marioneta: Apache o GPL







Descubra los detalles de cómo obtener una profesión de alto perfil desde cero o subir de nivel en habilidades y salario tomando los cursos en línea pagos de SkillFactory:

• Curso DevOps (12 meses)

Útil

• 450 cursos gratuitos de la Ivy League
• Tendencias en el escenario de datos 2020
• La ciencia de datos está muerta. Larga vida a la ciencia empresarial
• Data Science on Steroids: Introducing Decision Intelligence
• Proyecto de ciencia de datos más exitoso y más controvertido: Cambridge Analytica