Portada » DevOps: metodología, principios, enfoques y tecnologías

DevOps: metodología, principios, enfoques y tecnologías

by Donal Sandro Noblejas Huaman

Hola mi nombre es donal Sandro Noblejas Huamán de Lima Perú 🇵🇪 hoy vengo con otro artículo de  Devops y como siempre y en cada uno de ellos completamente solo y me agrada porque se aprende, y como siempre sin empresas, personas, familiares, ni el estado ni ningún tipo de ayuda cuidado con los estafadores solo en mis tiempos libres redactando jejeje, bueno ahí vamos.

Se habla de DevOps durante mucho tiempo y cada día más, pero este término es tan multifacético que es fácil confundirse. Intentemos desglosarlo todo: sobre los principios, enfoques y tecnologías que utilizan los ingenieros para mejorar la calidad del desarrollo y la operación de las aplicaciones.

DevOps como metodología

DevOps es una metodología para la interacción de todos los participantes en el ciclo de desarrollo y la integración mutua de sus procesos de trabajo, lo que ayuda a asegurar la calidad del producto. Apareció sobre la base de Agile en 2008, una metodología de desarrollo flexible donde el foco principal está en la calidad del producto y todo de lo que depende.

Pasemos a un ejemplo del uso de DevOps. Por ejemplo, la capacidad de realizar cambios y centrarse en las ganancias y los beneficios. Ciertamente, DevOps no tomó prestado el 100% de todos los enfoques de Agile, pero tomó lo mejor e incluso transformó algunos aspectos.

La metodología DevOps está diseñada para organizar, crear y actualizar de manera eficiente productos y servicios de software.

Esto es lo que significa:

• La velocidad de desarrollo aumenta. DevOps, debido a la automatización de un extremo a otro y la integración de procesos, le permite reducir el tiempo necesario para lanzar nuevas funciones (características) o corregir errores de software (bugs) y hacer que el proceso de desarrollo sea más flexible y rápido.

• Mejora de la colaboración y la comunicación. DevOps elimina barreras entre los desarrolladores, los equipos de operaciones y el resto del ciclo de desarrollo.

• Mejora de la calidad del producto. DevOps, cuando se implementa correctamente, permite detectar y corregir errores antes, reduce los riesgos de fallas e incidentes asociados con el factor humano y aumenta la confiabilidad del desarrollo de software y del sistema en su conjunto.

• Reducir costes y optimizar recursos . DevOps se esfuerza por automatizar y optimizar los procesos de desarrollo e implementación, reduciendo así los costos y el uso de recursos como el tiempo y el equipo.

Los enfoques de esta metodología, con la correcta construcción de procesos, permiten trabajar de manera más eficiente. Pero hay que recordar que cada empresa tiene sus matices. Adoptar e implementar DevOps en la empresa A, al igual que en la empresa B, no funcionará. Es necesario tener en cuenta las particularidades, pero al mismo tiempo no descuidar la experiencia de otras personas.

DevOps como combinación de principios culturales

DevOps es también un fenómeno cultural en desarrollo y una combinación de principios, enfoques y herramientas culturales. Agile cuenta con: analistas (negocios y sistemas), desarrollo, pruebas, ingenieros que son directamente responsables del soporte de producción. Y en DevOPs aparecen nuevos roles y ramas.

Ramas de DevOps:

• Metodología SRE (ingeniería de confiabilidad del sitio). Esta metodología pone énfasis en el seguimiento y en la calidad del producto y servicio brindado a los clientes de la empresa.

• Ingeniería en la nube. Su objetivo es trabajar con diversas soluciones en la nube, tanto nubes clásicas como multinubes y el contenido de las mismas.

• ChatOps . Este es un enfoque para gestionar las tareas operativas y la comunicación dentro de un equipo y una organización utilizando una plataforma de chat y herramientas de mensajería instantánea, así como para gestionar la infraestructura y la pila de CI/CD a través de mensajería instantánea.

• ArchOps. Esta dirección se centra en los aspectos arquitectónicos del desarrollo, que van desde el desarrollo del diseño arquitectónico hasta el costo del equipo para el software que se está desarrollando.

Parece que estas son sólo tendencias. Todos decidieron: “¡Agreguemos -Ops a cualquier palabra y todo estará bien!” ¡Pero en realidad no lo es! Un ejemplo de esto es el DevSecOps clásico, cuando agregamos seguridad al ciclo de desarrollo utilizando enfoques SAST/DAST. Es decir, la atención se centra en la seguridad del desarrollo del código y la búsqueda de eliminar vulnerabilidades, puertas traseras, así como el escaneo de una aplicación en ejecución y pruebas de penetración. En mi opinión, cuando se combina con DevOps, DevSecOps es una metodología completamente funcional. Encaja bien en el ciclo de desarrollo. Metodologías que parecían extrañas, como ChatOps o ArchOps, también funcionan si comprendes de qué se tratan y cómo implementarlas correctamente para tus tareas.

DevOps como combinación de desarrollo y soporte de productos

Dev – desarrollo (desarrollo).

Ops – operación.

DevOps es una combinación de desarrollo de productos y soporte, pero dependiendo de los procesos de una empresa, puede verse diferente en todos los ámbitos. En algún lugar de la empresa, los ingenieros de Devops responden:

• para el circuito productivo;

• para todos los circuitos y pila CI/CD;

• para todo lo relacionado con CI/CD y circuitos de prueba;

• y en algún lugar, y este, en mi opinión, es el enfoque más maduro, los ingenieros de Devops son los únicos responsables del desarrollo de productos, la introducción de nuevas tecnologías y todo lo relacionado con el proceso de CI/CD.

De todo lo anterior podemos concluir que todo depende de la empresa y de la madurez de sus procesos de desarrollo.

Puede agregar otra versión del término. DevOps es la integración de personas, procesos y tecnologías para ofrecer valor continuamente a los clientes. DevOps permite a representantes de departamentos que antes estaban dispares (desarrollo, operaciones de TI, control de calidad y seguridad) coordinar sus esfuerzos y colaborar para crear productos mejores y más confiables.

Es decir, gracias a esta metodología las empresas se vuelven más competitivas para ingresar al mercado. Esto se aplica tanto a las nuevas empresas como a las grandes y torpes empresas.

DevOps también significa unidades de infraestructura adicionales y administradores de áreas específicas. También pueden ser propietarios de producto, directores técnicos, Scrum masters. Dependiendo de la empresa, estos roles pueden denominarse de forma diferente o igual. Desafortunadamente, en el mundo moderno, cada uno entiende la terminología actual a su manera, a pesar de los muchos trabajos y términos establecidos, esto no impide que las personas comprendan qué es DevOps a su manera.

DevOps y participantes en el desarrollo

Canalización clásica de DevOps

Echemos un vistazo paso a paso a cómo se manifiesta DevOps en cada etapa de desarrollo, usando el ejemplo de escribir software desde cero. Está claro que aquí todo es de un nivel extremadamente alto, pero para entenderlo será suficiente.

Paso 1: planificación

Primero, basándose en los requisitos comerciales, un analista comercial escribe los requisitos comerciales (BT), luego la arquitectura de la aplicación y, si todos están satisfechos con ella, un analista de sistemas procesa los requisitos comerciales en una especificación técnica (TOR). En este paso, DevOps significa algún tipo de sistema de planificación de tickets, sistemas de proyectos.

Paso 2: Codificación (desarrollo)

Los desarrolladores escriben código basándose en especificaciones técnicas, lo que da como resultado una primera versión determinada de la aplicación (software) en su forma original. Aquí DevOps es un IDE de desarrollador y un repositorio de código fuente. Es importante, en esta etapa, también es importante cubrir el código con pruebas funcionales y unitarias, así como verificar el código para el diseño del código (estilo de código) y la revisión del código (revisión de código).

Paso 3: Compilación

La aplicación compilada (ensamblada) se ensambla y pasa verificaciones de diseño de código, cobertura de código con pruebas funcionales y unitarias. Si todas las comprobaciones son exitosas, el ensamblaje de la aplicación se coloca en el registro de aplicaciones compiladas o artefactos, por ejemplo, Jfrog Artifactory.

Paso 4: Prueba

Para probar un conjunto, es necesario implementarlo o implementarlo en un determinado circuito de prueba. Podría ser un banco de pruebas dedicado, una máquina virtual (VM) o un conjunto de bucles de prueba. Después de lo cual ocurren varios tipos de pruebas, que siempre comienzan con pruebas manuales, y luego de humo, funcionales, UI, regresión, carga, etc., dependiendo de la madurez de la metodología de prueba en su empresa.

Paso 5: Formación del comunicado

Pueden ser recopilados por ingenieros de Devops o los propios desarrolladores principales, o por el desarrollador responsable, o por especialistas especialmente designados que sean responsables de la versión en sí. Pueden ser Scrum masters, delivery-managers, release-managers, etc.

Paso 6: Implementar en producción

Implementación de nuestra versión de software previamente ensamblada y probada en producción. Es importante que se preserve el principio de idempotencia, el conjunto que ha sido ensamblado y probado con todos los tipos de pruebas necesarios debe incluirse en el circuito productivo.

Paso 7: Monitoreo

Nosotros, o colegas del departamento de soporte (operaciones) y/o monitoreo, monitoreamos la versión implementada previamente: qué tan bien fue todo, si se necesita soporte o monitoreo adicional.

Agregaré más sobre el monitoreo. Puede ser en tres niveles:

1. Supervisión del rendimiento. Monitoreamos el hardware y la infraestructura: memoria, CPU, swap, disco duro, etc.

2. Monitoreo de aplicaciones. Observamos el comportamiento de una aplicación y un servidor en ejecución con todos sus componentes. Monitoreamos la disponibilidad del software, que funciona correctamente (su funcionalidad), la base de datos del software, si la hay.

3. Seguimiento empresarial. Seguimos los beneficios prácticos para la empresa que aporta la aplicación. Recopilamos métricas y registros de aplicaciones y monitoreamos la funcionalidad comercial del software.

Después de esto, comienza la siguiente iteración. Y esto seguirá sucediendo durante mucho tiempo hasta que nuestro software sea eliminado o reemplazado por otra cosa.

¿Cuáles son los enfoques dentro de DevOps?

Integración Continua (CI 

integración continua

La integración continua es el proceso de trabajar con el código fuente, ensamblar y probar la cobertura del código con pruebas funcionales y unitarias, verificar el estilo del código y revisar el código. El resultado de este enfoque será un artefacto: una aplicación compilada. Por ejemplo, un archivo jar o una imagen acoplable.

Pruebas automatizadas (AT)

Pruebas automatizadas

Cuando una aplicación supera las decenas o cientos de versiones, probarla manualmente deja de ser rentable y resulta demasiado lenta. Aquí es donde nos ayudan las pruebas automáticas, que están integradas en la tubería. Es importante agregar que es mejor integrar las pruebas en la tubería junto con un sistema de informes que registrará todas las ejecuciones de las pruebas, el porcentaje de pruebas exitosas y no exitosas, su posible degradación o, por el contrario, que todo está bien desde el lanzamiento hasta el final. liberar.

Pruebas continuas (CT)

Pruebas continuas

Este enfoque consiste en que el ciclo de prueba completo esté automatizado. Cuando tienes una aplicación madura, los procesos maduros en la empresa y todos los tipos de pruebas necesarios están presentes y el código está bien cubierto de pruebas.

Despliegue continuo (CD)

Despliegue continuo

La esencia de este enfoque es crear una canalización que permita que cada cambio de código exitoso se implemente automáticamente en producción o producción sin intervención humana. Según el modelo de desarrollo clásico, debemos tener al menos 3 circuitos: prueba, preproducción y producción. Dependiendo del proyecto y la disponibilidad de tipos de pruebas, se agregan otras opciones de circuito. El Despliegue Continuo es una buena práctica muy extendida, pero lamentablemente no todas las empresas alcanzan la madurez de sus procesos.

Recuperación automatizada (AR)

Recuperación automatizada

Este es un enfoque importante que a menudo se olvida. Algunas aplicaciones no vuelven automáticamente a la versión anterior. Incluso si dicha canalización se configura de fábrica teniendo en cuenta las herramientas de CI/CD. En consecuencia, algunas aplicaciones corrigen sus errores únicamente instalando la siguiente versión. No pueden retroceder, sólo pueden avanzar. La Recuperación Automatizada es un enfoque en el que puedes restaurar cualquier contorno, en primer lugar, el contorno de producción a la versión anterior de la aplicación con todo lo que ello implica, tanto la capa app como la capa DB.

Gestión de versiones (RM)

Gestión de la liberación

La gestión de lanzamientos es la gestión del ciclo de lanzamiento de toda la aplicación, y no de algunos elementos o servicios individuales. La tarea principal de la gestión de lanzamientos es planificar los lanzamientos, las fechas de entrega del software, así como su ciclo de lanzamiento completo, lo que incluye comprender la cantidad de tareas incluidas en el lanzamiento y su funcionalidad. Un ingeniero de DevOps no siempre gestiona directamente la gestión de lanzamientos, pero participa en el ciclo mismo.

IaC: infraestructura como código

IaC: infraestructura como código

El enfoque es que a través de un repositorio de código fuente puedas gestionar completamente tu infraestructura. Es decir, un CD es la instalación de aplicaciones sobre algún circuito, y aquí podemos ampliar el propio circuito desde cero con un solo botón. Comenzando desde la VM, terminando con el sistema operativo y todas las configuraciones, dependencias de los componentes de la aplicación, configuraciones, variables de entorno. Este es un enfoque al que no todas las empresas llegan. Pero en situaciones en las que esto se implementa, es algo genial.

Monitoreo de desempeño (PM)

Supervisión del rendimiento

La esencia principal del enfoque es que deberíamos tener sólo el seguimiento necesario en todas las capas. Si tenemos algún tipo de virtualización, necesitamos monitorear el hipervisor, el hardware, necesitamos monitorear una máquina virtual específica por CPU, memoria, etc. Esta es una base que no debes olvidar, especialmente si estás haciendo virtualización o contenedorización, dependiendo de métricas de rendimiento. Especialmente en situaciones en las que tenemos una gran carga, esto es algo necesario. No es necesario simplemente colgar alertas sobre todo sin pensar, es necesario hacerlo solo donde sea necesario y para los responsables que son directamente responsables de esta infraestructura. No es necesario enviar un boletín informativo a todo el mundo.

Monitoreo de aplicaciones (AM)

Monitoreo de aplicaciones

Esta es una historia sobre el comportamiento de una aplicación, que incluye sus métricas: grupo de conexión, grupo de base de datos de conexión, consumo de memoria por parte de la aplicación misma, carga en la utilización del núcleo, ingreso a SWAP, degradación de la ejecución de consultas en la base de datos, etc. La capa de aplicación afecta a todos los componentes de la aplicación. No olvide que esto incluye no sólo el monitoreo clásico de aplicaciones, sino también el seguimiento de registros.

Monitoreo de Negocios (BM)

Monitoreo de Negocios

Se trata de monitorear la generación real de ganancias de su empresa, es decir, las operaciones comerciales. Si compramos algún seguro, esto significa registrar un usuario, calcular el seguro y trabajar con los reguladores. Esto es importante porque, a partir de este seguimiento, se puede predecir y monitorear el número real de ventas, tanto en el tiempo como analizar la retrospectiva. Así como otros aspectos útiles que inciden en estas ventas desde el punto de vista de la funcionalidad empresarial del usuario. Tanto los usuarios externos, si por ejemplo tienes una tienda online, como los internos, si son dependientes de CC.

Gestión de configuración (CM)

Gestión de configuración

Esta es una parte integral de CI/CD: gestión de configuración, no sólo de circuitos, sino también del software mismo. Las configuraciones deben estar cubiertas por la automatización y gestionadas a través de ella. Estamos hablando de configuraciones de servidor de software, configuraciones de registro y monitoreo, configuraciones de integración, configuraciones de autorización, cachés, etc. Todo esto hay que gestionarlo a través de código, a través de un sistema de gestión y despliegue. Si cambia con frecuencia alguna configuración, debe revisarla manualmente cada vez o, en general, esta configuración está dentro de una aplicación compilada y necesita reconstruir la aplicación cada vez para cambiarla, no es necesario hacerlo. Inmediatamente abandonamos esto, sacamos la configuración de los corchetes de la aplicación y la administramos a través del repositorio de código fuente y los scripts de implementación.

CI/CD

CI/CD

Esta es una cinta transportadora. Digamos que tenemos: código, confirmaciones, lanzamientos, ensamblajes, verificación de código con pruebas, pruebas de integración, revisión final, composición de lanzamientos, pruebas de carga y despliegue hasta producción final. Antes de saturarlo con automatización y seguridad, debe asegurarse de que funcione correctamente.

La integración continua es la historia de la automatización en torno al ensamblaje, las pruebas unitarias y otras pruebas, la implementación para probar circuitos, la capacidad de ejecutar pruebas y verificaciones automáticas.

La entrega continua ocurre lo mismo con la automatización, pero aquí la entrega se suma a la producción. Pero se hace manualmente: mediante botón, en un momento determinado, con o sin tiempo de inactividad.

La implementación continua es un ciclo totalmente automatizado en el que la implementación a producción se produce automáticamente. Además, puede realizarse según lo previsto.

¿ Cuál es la principal diferencia entre entrega continua e implementación continua ? En ese mismo botón de implementación en producción, se inicia automática o manualmente. 

Diferencia entre entrega continua y entrega continua

Principios básicos de CI/CD:

● Distribución de responsabilidad;

● Minimizar los riesgos y los factores humanos;

● Comentarios rápidos.

Tecnologías DevOps

Versionado

Código de versiones y artefactos

La historia de las tecnologías relacionadas con CI/CD comienza con el control de versiones. Dependiendo de lo que queramos versionar, pueden ser diferentes tipos de sistemas:

• Versionado de código. Básicamente es un repositorio de código fuente. Dependiendo de lo que utilice su empresa, existen algunos matices.

• Versionado de artefactos. Existen repositorios de artefactos para esto.

• Versionado de modelos de datos (en el caso de ML).

Virtualización

Tipos de arquitectura de infraestructura: tradicional, virtualización, contenedorización

La implementación tradicional es cuando tenemos una pieza de hardware en la sala del servidor, un sistema operativo y una aplicación. En la mayoría de los casos, esto se denomina arquitectura bare metal local.

La virtualización es la misma pieza de hardware en la que se implementa el sistema operativo, pero también tiene un hipervisor que administra las entidades de las máquinas virtuales en las que se implementa el sistema operativo. Hay un conjunto de binarios y bibliotecas que son necesarios para que la aplicación funcione y la aplicación misma.

La contenedorización es el mismo hardware, el mismo sistema operativo, pero en lugar de un hipervisor, el tiempo de ejecución del contenedor. No existe un sistema operativo clásico, pero hay contenedores que se ejecutan en función de una determinada imagen. Luego vienen los binarios necesarios con bibliotecas para iniciar y la aplicación en sí.

Arquitectura acoplable

Principales instrumentos de orquestación para 2023

Qué se necesita para CI/CD

1. Sistema de control de versiones de código: Git, Bamboo, GitabCI, Mercurial.

2. Herramienta CI/CD: GitlabCI, TeamCity, Jenkins, Bamboo, CircleCI.

3. Sistema de gestión de artefactos: Sonatype Nexus, Jfrog Artifactory, Docker Registry.

4. Sistema de gestión de configuración: Ansible, Terraform, Chef, Pippet.

Herramientas CI/CD en 2023

Herramientas de seguimiento en 2023 

Y así es como se verán las principales herramientas de registro en 2023:

1. Datadog Log Collection & Management – EDITOR’S CHOICE

2. SolarWinds Security Event Manager (FREE TRIAL)

3. SolarWinds Papertrail (FREE PLAN)

4. Graylog (FREE PLAN)

5. Loggly (FREE TRIAL)

6. ManageEngine EventLog Analyzer (FREE TRIAL)

7. SematextLogs (FREE TRIAL)

8. FirstWaveopEvents (FREE TRIAL)

9. ManageEngine Log360 (FREE TRIAL)

10. Paessler PRTG Network Monitor

11. Splunk

12. Fluentd

13. Logstash

14. Kibana

15. XpoLog

16. Managelogs 

Se pueden encontrar más detalles aquí . https://www.comparitech.com/net-admin/log-management-tools

Conjunto general de herramientas DevOps 2023

Lista detallada con descripción aquí . https://sapphireventures.com/blog/future-of-devops-ecosystem-european-players/

Y preguntas: “¿Es necesario dominar todo esto?” Es simplemente imposible abarcarlo todo. Pero tiene sentido tocar al menos 2 herramientas de cada bloque y elegir la que necesita.

Si hablamos de los mejores, es decir, esta opinión para 2023 identifica dicho conjunto de conjuntos como los mejores : https://www.simform.com/blog/devops-tools/

Las mejores herramientas de DevOps 2023

Muchas de estas herramientas son de código abierto.

Procesos DevOps

Mantenga un truco de vida sobre la introducción de nuevos procesos. Cuando implementa DevOps, es probable que haya cambios en el proceso. Algunas son pequeñas, otras grandes, incluida la creación de otras nuevas. Ahora le daré un cierto enfoque de trabajo, es posible que tenga que modificarlo usted mismo en alguna parte, pero este enfoque ya se ha probado en una gran cantidad de implementaciones de procesos, tanto dentro de una empresa como dentro de varias.

¿Qué hacer y adónde ir?

¿Qué preguntas deberías hacer?

Paso 1: ¿Por qué?

En primer lugar, debemos responder a las preguntas: ¿por qué estamos introduciendo este proceso y qué dolor estamos resolviendo con este proceso?

¿Por qué necesitamos todo esto?

Paso 2: ¿Cuáles son los beneficios de la implementación?

Además, el beneficio se puede dividir en varias capas: para usted personalmente, para el departamento, para la empresa.

Beneficio

Paso 3: ¿Qué equipos se verán afectados o afectados (para peor) por este proceso ?

Esté preparado para que pueda haber resistencias, discusiones y tendrá que vender la idea.

¿Quién se verá afectado?

Paso 4: ¿Hay quienes claramente estarán en contra?

Porque estas son las personas que pondrán radios en las ruedas al principio.

Habrá resistencia

Paso 5: ¿Hay alguien que esté de acuerdo inmediatamente? Estos serán aliados, aquellos que os apoyen.

¿Estás de acuerdo?

Por ejemplo, queremos agregar un proceso determinado para introducir nuevas tecnologías en la empresa. Digamos que usted está en el rol de ingeniero de Devops o simplemente de ingeniero de soporte. ¿Qué podría resultarte útil?

Estamos trabajando en los procesos.

Intentemos responder cada una de las preguntas anteriores y hablar sobre ellas con más detalle.

Respuestas a preguntas sobre la necesidad de implementar procesos.

Acudimos a quienes estarán a favor, buscamos confianza, acordamos qué decidimos, cómo decidimos y en qué plazo. Y luego, dependiendo de cómo esté estructurada su empresa, defiende estas ideas ante la dirección.

Inevitablemente surgirá resistencia. Poco a poco estamos encontrando un argumento que eliminará la resistencia. Por ejemplo, si el cambio tiene que ver con el apoyo y tienen que ampliar las competencias, pueden decir: “No tenemos suficientes recursos, no queremos ampliar las competencias”. Luego les respondemos: “Aprenderán esto y aquello, se convertirán en especialistas mejor pagados y conocerán más herramientas. Le proporcionaremos formación adicional”. Todos estos argumentos deben estar presentes para ir superando progresivamente esta resistencia.

Piensa si necesitas DevOps en tu empresa y, lo más importante, ¿por qué? Simplemente implementar por implementar es una muy mala historia, no deberías hacer eso. Si necesita DevOps, elija tecnologías basadas en competencias y mercado. Es decir, elegir aquellas tecnologías que sean relevantes en un momento determinado y se adapten a tus necesidades. No tenga miedo de utilizar enfoques existentes y rehacerlos para adaptarlos a sus necesidades.

Los estaré esperando 

Autor Donal Sandro Noblejas Huamán

Lima Perú 🇵🇪 

Sitio web verlista.com/blog

verlista.com

https://pe.linkedin.com/in/donal-sandro-noblejas-huaman

You may also like

Leave a Comment

Are you sure want to unlock this post?
Unlock left : 0
Are you sure want to cancel subscription?
-
00:00
00:00
Update Required Flash plugin
-
00:00
00:00