View
47
Download
3
Category
Preview:
DESCRIPTION
Manual de implementación de DevOps, Integración Continua, Entrega Continua, Control y Modelos de Versionamiento
Citation preview
8-8-2015
DevOps para
principiantes Manual de implementación
Yadder Aceituno Gonzalez 201021209
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
Tabla de contenido Qué es DevOps? .......................................................................................................................... 2
1. DevOps no es un puesto de trabajo .............................................................................. 3
2. DevOps no se trata de resolver un problema de TI ..................................................... 3
3. DevOps no es un sinónimo de integración continua .................................................. 3
4. DevOps está aquí para quedarse .................................................................................. 4
Los Principios de DevOps ............................................................................................................ 5
1. Desarrollar y probar contra sistemas que emulan los de producción ...................... 6
2. Desplegar bajo procesos confiables y repetibles ........................................................ 6
3. Monitorear y validar la calidad operacional ................................................................ 6
4. Ampliar círculos de retroalimentación ........................................................................... 7
Gestion de Versionamiento ........................................................................................................ 8
1. El repositorio ....................................................................................................................... 9
2. Modelos de versionado .................................................................................................... 9
El problema de compartir archivos .................................................................................. 10
La solución bloquear-modificar-desbloquear ................................................................ 10
La solución copiar-modificar-fusionar .............................................................................. 11
Integración Continua ................................................................................................................ 12
1. Las buenas prácticas ...................................................................................................... 13
Práctica de desarrollo de software .................................................................................. 13
Los miembros del equipo integran su trabajo frecuentemente .................................. 13
2. Los pasos para implementar integración continua ................................................... 14
2.1 Conciencia a las personas y da información sobre el tema ................................ 14
2.2 Tener claro el proceso de desarrollo de la empresa ............................................. 14
2.3 Tener clara la política de gestión y control de versiones ...................................... 15
2.4 Gestión de tareas y trazabilidad ............................................................................... 15
2.5 Automatización del build ........................................................................................... 15
2.6 Definir cual va a ser el pipeline de integración continua ..................................... 16
2.7 Elegir e instalar el servidor de integración continua .............................................. 16
2.8 Automatizar pruebas................................................................................................... 16
2.9 Inspección continua ................................................................................................... 17
2.10 Implementar entrega continua y despliegue continuo ........................................ 17
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
DevOps para principiantes
Capítulo 1
Qué es DevOps? Mucho se ha escrito acerca de lo que es DevOps: Un camino para que los desarrolladores y
directores de operaciones colaboren; un conjunto de mejores prácticas para la gestión de
aplicaciones en la nube; una idea ágil que se basa en la integración continua, lo que permite
frecuentes liberaciones de código.
La definición de DevOps cubre todas estas cosas y más. Pero dado que el término ha adquirido
estatus de palabra de moda, puede ser más interesante preguntarse no lo que es DevOps, sino
lo que no es. En el artículo SearchSoftwareQuality preguntó a algunos profesionales de software
exactamente eso. He aquí lo que dijeron.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
1. DevOps no es un puesto de trabajo Publicaciones en sitios de empleo sugieren otra cosa, pero DevOps no es un puesto de trabajo,
dijo el consultor de Agile, Scott Ambler. "¿Gestor de DevOps? No sé lo que es eso". DevOps no
debe ser un rol laboral, dijo. "DevOps se trata de que los desarrolladores entiendan la realidad
de las operaciones y de que el equipo de operaciones comprenda lo que involucra el desarrollo”.
DevOps, el concepto, es un aspecto importante del desarrollo y la entrega de software, dijo
Ambler. "Pero el puesto de DevOps es un síntoma de que las organizaciones que contratan no
entienden lo que DevOps es realmente. Ellos no lo entienden todavía."
La postura de Ambler sobre DevOps va en contra de la sabiduría convencional. DevOps apareció
en la lista de 10 títulos de trabajo que es probable encontrar, de acuerdo con SearchCIO.com.
2. DevOps no se trata de resolver un problema de TI A pesar de sus muchos significados, DevOps es ampliamente entendido como una forma de
resolver un problema de TI: permite que el área de desarrollo y operaciones colaboren en la
entrega de software. Pero ese no es su objetivo final, dijo Damon Edwards, socio gerente de
consultoría de TI, Soluciones DTO. "El punto de DevOps es permitirle a su empresa reaccionar
ante las fuerzas del mercado lo más rápido, eficiente y confiable como sea posible. Sin el
negocio, no hay otra razón para que estemos hablando de problemas DevOps, mucho menos
pasar tiempo resolviéndolos".
Kevin Parker, experto de SearchSoftwareQuality, dijo que el nuevo reto que encaran los
gerentes de DevOps es toda la atención que el tema obtiene por parte del negocio. "Lo que
antes era una tarea arcana, de elaborada coordinación y gestión de proyectos es ahora en parte
diplomacia, parte protector y una buena cantidad de innovación."
3. DevOps no es un sinónimo de integración continua DevOps se originó en Agile como una forma de apoyar la práctica ágil de liberaciones de código
más frecuentes. Pero DevOps es más que eso, dijo Ambler. "El hecho de que se practique la
integración continua no significa que se está haciendo DevOps." Él ve a los gerentes de
operaciones como los principales interesados que los equipos ágiles necesitan trabajar para
liberar software.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
4. DevOps está aquí para quedarse En el dinámico mundo de la tecnología, el empleo evoluciona en respuesta a las nuevas
necesidades. A medida que cambian los requisitos, la demanda de estos nuevos puestos de
trabajo aumenta.
Una rama de desarrollo Agile, DevOps desdibuja las líneas entre los desarrolladores y equipos de
operaciones mediante el fomento de los desarrolladores a tener una comprensión de los
principios de las operaciones, y alentar a los profesionales de operaciones para reforzar sus
habilidades de codificación y automatización.
Como cada vez más empresas mueven los datos hacia la Nube y necesitan múltiples centros de
datos de todo el mundo, los roles estratégicos son necesarios, y ahí es donde el papel DevOps
encuentra su nicho.
El rol de DevOps apela a las empresas, pues está diseñado para lograr más con menos. El punto
de derribar los silos de TI tradicionales es aumentar la comunicación entre los empleados. "Hay
que abrir líneas directas de comunicación", dijo Robert Stinnett, Ingeniero de Automatización del
Centro de Datos de Columbia, Missouri.
Stinnett, sin embargo, tuvo unas palabras de advertencia para aquellos interesados en contratar
a personal de desarrollo en DevOps.
"Las empresas no deben usar DevOps como una excusa para tener gente haciendo dos o tres
trabajos diferentes", dijo. "Si usted lo está haciendo para ahorrar dinero, usted va a fracasar."
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
DevOps para principiantes
Capítulo 2
Los Principios de DevOps DevOps no es solo una palabra nueva en nuestro vocabulario, sino también una nueva forma de
hacer negocios. El nombre "DevOps" (una combinación de las palabras "desarrollo" y
“operaciones") aún no está en el diccionario Webster. Sin embargo, se está convirtiendo
rápidamente en un esfuerzo popular para la gestión y el uso común de los administradores de TI
en la industria del software.
Entender los principios de DevOps aporta valor a la empresa quien las aplica así como a aquellos
que utilizan lo que despliegan. He aquí algunos de los principios que presenta esta filosofía.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
1. Desarrollar y probar contra sistemas que emulan los de
producción
El objetivo aquí es permitir que los equipos de desarrollo y de aseguramiento de la calidad
desarrollen y prueben contra sistemas que se comportan tal como lo hace el sistema en su fase
de producción. De esta manera se puede observar cómo se comporta la aplicación y también su
desempeño, mucho antes de que esté lista para su despliegue.
Se busca probar la aplicación bajo el ambiente más parecido al real y simultáneamente también
se busca validar los procesos de entrega de aplicaciones. Desde el punto de vista de operaciones
este principio tiene un enorme valor, ya que permite ver muy temprano en el ciclo cómo se
comporta el ambiente que debe soportar la aplicación y permite eventualmente crear las bases
para poder entonar ese ambiente en función de la aplicación.
2. Desplegar bajo procesos confiables y repetibles
Este principio permite a desarrollo y operaciones apoyar un proceso de desarrollo ágil e iterativo
en todas las fases hasta producción. La automatización es esencial para poder crear procesos
que cumplan con las siguientes condiciones: iterativos, frecuentes, repetibles y confiables. Esto
le permite a la organización crear una cartera de entregables, donde los despliegues y las pruebas
se pueden realizar en forma automática y continua. La ejecución frecuente de despliegues
también permite poner a prueba los procesos de despliegue, limitando los riesgos de fallas en los
momentos de entrega.
3. Monitorear y validar la calidad operacional
Típicamente las organizaciones son muy buenas monitoreando aplicaciones y sistemas en
producción, ya que existen muchas opciones para hacer esto y ellas utilizan herramientas que
permiten capturar las métricas de producción en tiempo real. Sin embargo, este monitoreo es
realizado sobre aplicaciones individuales, donde las aplicaciones no están conectadas las unas
con las otras. DevOps exige que el monitoreo sea realizado más temprano en el ciclo, requiriendo
además que se haga monitoreo de las características funcionales y de las características no-
funcionales de la aplicación.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
En cualquier momento, a medida que las aplicaciones están siendo desplegadas y probadas,
DevOps exige que se capturen métricas de calidad y que sean analizadas. Este monitoreo
frecuente provee aviso tempranero sobre temas operacionales y de calidad que podrían aparecer
posteriormente en la etapa de producción. Adicionalmente, las métricas deben ser capturadas
en un formato que sea entendible y utilizable para todos los interesados, incluyendo a los
responsables de las aplicaciones en las líneas de negocio.
4. Ampliar círculos de retroalimentación
Uno de los principales objetivos de DevOps es permitir a las organizaciones reaccionar y poder
realizar cambios rápidamente en sus procesos de negocio. En la entrega de software, el objetivo
se transforma en proveer retroalimentación en un corto tiempo y además poder aprender
rápidamente de cada acción que se toma. Las organizaciones deben crear canales de
comunicación que permitan a todas las partes interesadas accesar a la información y actuar sobre
la base de la retroalimentación y por ello:
Desarrollo puede actuar ajustando sus planes de proyecto o sus prioridades.
Producción (Operaciones) puede actuar mejorando los ambientes de producción.
Las Líneas de Negocios pueden actuar modificando sus planes de implementación.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
DevOps para principiantes
Capítulo 3
Gestion de Versionamiento La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el
software y hardware instalado en el entorno de producción.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo
(DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware
Definitivo (DHS), donde se almacenan piezas de repuesto y documentación para la rápida
reparación de problemas de hardware en el entorno de producción.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
1. El repositorio Un gestor de versionamiento es un sistema centralizado para compartir información. En su
núcleo está un repositorio, que es un almacén central de datos. El repositorio almacena
información en forma de un árbol de archivos (una jerarquía típica de archivos y directorios). Un
número de clientes se conectan al repositorio, y luego leen o escriben esos archivos. Al escribir
datos, el cliente hace que la información esté disponible para los otros; al leer los datos, el cliente
recibe información de los demás.
Figura 1
Cuando un cliente lee datos de un repositorio, normalmente ve únicamente la última versión
del árbol de archivos. Pero el cliente también tiene la capacidad de ver estados previos del
sistema de archivos. Por ejemplo, un cliente puede hacer preguntas históricas, como “¿qué
contenía este directorio el último miércoles?”, o “¿quién fue la última persona que cambió este
archivo, y qué cambios hizo?” Esta es la clase de preguntas que forman el corazón de
cualquier sistema de control de versiones: son sistemas que están diseñados para guardar y
registrar los cambios a los datos a lo largo del tiempo.
2. Modelos de versionado Todos los sistemas de control de versiones tienen que resolver los mismos problemas
fundamentales: ¿cómo permitirá el sistema compartir información entre usuarios, pero evitando
que ellos accidentalmente se pisen unos a otros? Es demasiado sencillo que los usuarios
accidentalmente sobre-escriban los cambios del otro en el repositorio.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
El problema de compartir archivos
Considere este escenario: suponga que tiene
dos compañeros de trabajo, Harry y Sally. Cada
uno decide editar el mismo archivo del
repositorio a la vez. Si Harry graba sus cambios
en el repositorio primero, el posible que (unos
momentos después) Sally pueda
accidentalmente sobre-escribirlos con su
propia versión nueva del archivo.
Mientras que la versión del archivo de Harry no
se ha perdido para siempre (porque el sistema
recuerda cada cambio), cualquier cambio que
Harry hizo no estará en la versión nueva del
archivo de Sally, porque para empezar ella nunca vio los cambios de Harry. El trabajo de Harry
está aun efectivamente perdido (o al menos falta en la última versión del archivo) y
probablemente por accidente. ¡Esta es una situación que definitivamente tenemos que evitar!
La solución bloquear-modificar-desbloquear
Muchos sistemas de control de versiones
utilizan un modelo bloquear-modificar-
desbloquear para enfrentarse al problema, lo
cual es una solución muy simple. En estos
sistemas, el repositorio sólo permite que una
persona cambie un archivo. Harry primero
debe bloquear el archivo antes que pueda
empezar a hacer cambios en él. Bloquear un
archivo se parece mucho a tomar prestado un
libro de la biblioteca; si Harry ha bloqueado un
archivo, entonces Sally no puede hacer ningún
cambio en él. Si ella intenta bloquear el
archivo, el repositorio le denegará la petición.
Todo lo que ella puede hacer es leer el archivo,
y esperar a que Harry termine sus cambios y libere su bloqueo. Después que Harry desbloquee
el archivo, se acabó su turno, y ahora es el turno de Sally para bloquear y editar.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
La solución copiar-modificar-fusionar
La mayoría de gestores de versiones utilizan este modelo. En este modelo, el cliente de cada
usuario lee el repositorio y crea una copia de trabajo personal del archivo o del proyecto. Luego,
los usuarios trabajan en paralelo, modificando sus copias privadas. Finalmente, las copias
privadas se fusionan juntas en una nueva versión final. El sistema de control de versiones a
menudo ofrece ayuda en la fusión, pero al final la persona es la responsable de hacer que ocurra
correctamente.
Aquí hay un ejemplo. Digamos que tanto Harry como Sally crean copias de trabajo del mismo
proyecto, copiado del repositorio. Ellos trabajan simultáneamente, y hacen cambios al mismo
archivo A dentro de sus copias. Sally es la primera en grabar sus cambios en el repositorio.
Cuando Harry intenta grabar sus cambios más tarde, el repositorio le informa que su archivo A
está desactualizado. En otras palabras, que el archivo A en el repositorio ha cambiado de alguna
forma desde la última vez que lo copió. Por lo que Harry le pide a su cliente que fusione cualquier
nuevo cambio del repositorio dentro de su copia de trabajo del archivo A. Lo más seguro es que
los cambios de Sally no se superpongan a los suyos; por lo que una vez que ambos conjuntos de
cambios se han integrado, él graba su copia de trabajo de nuevo en el repositorio.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
DevOps para principiantes
Capítulo 4
Integración Continua Muchas veces, se tiende a pensar que la integración continua es tener instalado el servidor de
integración continua (por ejemplo Jenkins) y que este compile el código periódicamente; o tener
automatizados los despliegues dándole a un botón desde dicho servidor. Pero la integración
continua engloba mucho más que esto. Es una serie de buenas prácticas, de comprobaciones
interconectadas entre sí, para conseguir software de mejor calidad.
Martin Fowler define la integración continua de la siguiente manera:
“Práctica de desarrollo software donde los miembros del equipo integran su trabajo
frecuentemente, al menos una vez al día. Cada integración se verifica con un build
automático (que incluye la ejecución de pruebas) para detectar errores de integración tan
pronto como sea posible.”
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
1. Las buenas prácticas Partiendo de la definición de Fowler, poder identificar a los componentes e ideas claves de las
buenas prácticas de integración continua.
Práctica de desarrollo de software
Para implantar integración continua solemos definir un “pipeline”, un conjunto de etapas, de
fases por las que va pasando el software y que se automatizan. Un ejemplo de un pipeline
podría ser que con cada subida de código al repositorio de control de versiones este se
descargue y compile.
Si está todo correcto, que se ejecuten una serie de pruebas unitarias, o se despliegue el código
a otro entorno para hacer pruebas de sistema.
Por último, que se despliegue al entorno de QA, de pruebas, para realizar otro tipo de pruebas
manuales. Esta es una de las primeras cosas que hay que definir, saber cómo es el desarrollo,
cuál es el criterio para que el código promocione de un entorno a otro, y qué se hace en cada
entorno.
Y si el código no pasa algún punto hay que establecer cuál es la estrategia para resolver el error,
quién se encarga de ello, cómo se gestiona.
Los miembros del equipo integran su trabajo frecuentemente
Cuando se distribuye el trabajo entre los miembros del equipo, y cada uno comienza a trabajar,
normalmente se asumen cosas de otros componentes del software que todavía no están
implementados o que está programando otra persona. Y hasta que no se junta todo ese código,
no son visibles los errores de integración que se cometen.
Antes, lo que se tendía a hacer es que cada desarrollador programara de forma independiente y
luego al final se realizaba la integración de todo el código. Esto se traduce en integraciones
difíciles, que tardan mucho en completarse y mucho sufrimiento, ya que hay muchos cambios,
mucho código que integrar. Uno de los motivos por los que surge la integración continua es para
evitar esto. La idea es que en vez de dejar la integración para el final, se vayan haciendo pequeñas
integraciones de código frecuentemente.
La frase que podríamos aplicar aquí es que si algo te cuesta, debes hacerlo más a menudo y poco
a poco, para que con el tiempo te vaya costando cada vez menos esfuerzo.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
2. Los pasos para implementar integración continua Implementar integración continua conlleva un cambio en la forma de trabajo del equipo, en el
día a día de las personas, que debe ir siendo aceptado poco a poco.
Aquí enumeramos los pasos principales para implementar la integración continua, y unos
pequeños consejos, puesto que deberás adaptar los pasos a tu empresa, al software etc.
2.1 Conciencia a las personas y da información sobre el tema Los cambios afectan a las personas, y normalmente, tendemos a no querer cambiar, a aceptar lo
malo aunque sea conocido frente al cambio. Hay que facilitar el cambio, explicando ante todo
qué se va a hacer, y por qué se va a implantar integración continua.
Incluso, podría ser un buen momento para hablar con el equipo y que ellos mismos dijeran qué
cosas negativas o positivas ven al proceso de desarrollo actual, o cómo lo mejorarían.
Además, es importante ir formando al equipo en las nuevas tecnologías que vayas a implantar,
en hacer pruebas unitarias, de integración, en buenas prácticas, patrones de diseño, etc.
2.2 Tener claro el proceso de desarrollo de la empresa Con esto me refiero a por ejemplo, tener bien definido cosas como qué entornos hay (por
ejemplo, desarrollo, testing, pre-producción y producción), cuáles son los criterios para que las
versiones software pasen de un entorno a otro, qué se hace en cada entorno, qué tipos de
pruebas se hacen y en qué momento etc. Un servidor de integración continua como Jenkins va a
ser un elemento de enlace para todo esto.
Es decir, vamos a intentar mejorar el desarrollo, introduciendo más comprobaciones, pero
también vamos a intentar automatizar todos los procesos repetibles, manuales que se puedan
automatizar para invertir tiempo en otras cosas.
Por ejemplo, podríamos programar el servidor de integración continua para que cuando el código
que alguien suba al control de versiones se compile y pase ciertas pruebas, se despliegue
automáticamente y promocione a otro entorno.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
2.3 Tener clara la política de gestión y control de versiones Sin control de versiones, la integración continua no funciona. El servidor de integración continua
vigila, monitoriza los cambios que se hagan en el sistema de control de versiones.
Por ello, antes de ponernos manos a la obra implantando integración continua es necesario
pensar cómo vamos a combinar nuestra estrategia de control de versiones con la integración
continua. Por ejemplo, ten en cuenta que para decidir la estrategia de control de versiones a
seguir (sobre todo el tema de crear ramas o no) también influirá qué herramienta de control de
versiones utilizáis en la empresa.
Subversion o SVN, no son iguales que Git o Mercurial y no gestionan las ramas de la misma
manera. Con Git o Mercurial, una estrategia de rama por historia de usuario es mucho más fácil
y eso es algo a tener en cuenta.
2.4 Gestión de tareas y trazabilidad Algo muy útil para controlar los pequeños trozos de código que se agregan al repositorio esto
son las herramientas de gestión de tareas, como Jira o Redmine.
Y otra cosa importante es conseguir trazabilidad entre las tareas o requisitos, y el código, el cuál
es el commit (la modificación) del control de versiones en el que dicho requisito se ha
implementado. Esto es indispensable siempre, pero muy útil cuando detectemos fallos en el
código.
Así tendremos controlado en qué commit del código se ha dado el fallo y que hay
implementado y que no.
2.5 Automatización del build Para automatizar el build (compilación), puedes emplear scripts, herramientas como Ant o
Maven. Otro consejo es que intentes que la compilación no tarde demasiado. Ve optimizando
el proceso de compilación a lo largo del tiempo.
La compilación es el primer paso dentro de la integración continua, antes de ejecutar pruebas,
por lo que si en ese punto tardamos mucho tiempo, todo el proceso se demorará mucho y no
conseguiremos feedback rápido sobre qué falla en la aplicación.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
2.6 Definir cual va a ser el pipeline de integración continua Se debe pensar qué pasos, o por qué fases deberá ir pasando el código. Define un pipeline de
integración continua (una serie de fases, pasos), que luego se programara en el servidor de
integración continua.
En este caso distinguiría entre las pruebas básicas que deben pasarse cada vez que se hace una
subida al control de versiones, un smoke test para dar feedback rápido al desarrollador de si las
cosas están medianamente bien y otra serie de pasos más avanzados con pruebas más a fondo
(Smoke test: Detecta lo más pronto posible si los elementos críticos de la aplicación no
funcionan.).
2.7 Elegir e instalar el servidor de integración continua Una vez hecho todos los puntos anteriores pasaríamos a instalar y configurar el servidor de
integración continua. Además de implementar el pipeline que hemos definido previamente.
Si por ejemplo usas Jenkins como servidor de integración continua, y en el paso anterior
pensaste las distintas fases, etapas por las que va pasando el software, te será muy sencillo
configurar el pipeline en Jenkins.
Cada etapa o fase puede ser una tarea (job) de Jenkins, que ejecutará la siguiente fase en caso
de que todo sea un éxito.
2.8 Automatizar pruebas No es obligatorio tener todas las pruebas automatizadas y ya listas para ejecutarlas desde el
servidor de integración continua. En su lugar, ve automatizando las pruebas del pipeline
definido que consideres más primordiales primero y ve enlazándolas en el servidor cuando
estén listas.
Y no te olvides de que las pruebas que automatices son código, que deberás mantener a lo
largo del tiempo.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA
2.9 Inspección continua Por inspección continua se entiende el ir realizando análisis de código periódicamente (por
ejemplo con herramientas como SonarQube) interpretar los resultados y plantear y llevar a
cabo acciones de mejora de calidad del software.
2.10 Implementar entrega continua y despliegue continuo Si tu empresa tiene superada ya la integración continua, le va bien, tiene una estrategia de
pruebas y un pipeline de integración continua fiable, se puede implementar la entrega continua
(dejar el software en un estado listo para pasar a producción) y despliegue continuo (que cada
cambio en el código, después de pasar por todo el pipeline de integración continua que
definimos, se suba a producción).
Recommended