8-8-2015

DevOps para
principiantes
Manual de implementacin

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 sinnimo de integracin continua .................................................. 3

4.

DevOps est aqu para quedarse .................................................................................. 4

Los Principios de DevOps ............................................................................................................ 5

1.

Desarrollar y probar contra sistemas que emulan los de produccin ...................... 6

2.

Desplegar bajo procesos confiables y repetibles ........................................................ 6

3.

Monitorear y validar la calidad operacional ................................................................ 6

4.

Ampliar crculos de retroalimentacin ........................................................................... 7

Gestion de Versionamiento ........................................................................................................ 8

1.

El repositorio ....................................................................................................................... 9

2.

Modelos de versionado .................................................................................................... 9

El problema de compartir archivos .................................................................................. 10
La solucin bloquear-modificar-desbloquear ................................................................ 10
La solucin copiar-modificar-fusionar.............................................................................. 11

Integracin Continua ................................................................................................................ 12

1.

Las buenas prcticas ...................................................................................................... 13

Prctica de desarrollo de software .................................................................................. 13
Los miembros del equipo integran su trabajo frecuentemente .................................. 13

2.

Los pasos para implementar integracin continua ................................................... 14

2.1

Conciencia a las personas y da informacin sobre el tema ................................ 14

2.2

Tener claro el proceso de desarrollo de la empresa ............................................. 14

2.3

Tener clara la poltica de gestin y control de versiones ...................................... 15

2.4

Gestin de tareas y trazabilidad ............................................................................... 15

2.5

Automatizacin del build ........................................................................................... 15

2.6

Definir cual va a ser el pipeline de integracin continua ..................................... 16

2.7

Elegir e instalar el servidor de integracin continua .............................................. 16

2.8

Automatizar pruebas................................................................................................... 16

2.9

Inspeccin continua ................................................................................................... 17

2.10

Implementar entrega continua y despliegue continuo ........................................ 17

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

DevOps para principiantes

Captulo 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 prcticas para la gestin de
aplicaciones en la nube; una idea gil que se basa en la integracin continua, lo que permite
frecuentes liberaciones de cdigo.
La definicin de DevOps cubre todas estas cosas y ms. Pero dado que el trmino ha adquirido
estatus de palabra de moda, puede ser ms interesante preguntarse no lo que es DevOps, sino
lo que no es. En el artculo 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 sntoma de que las organizaciones que contratan no
entienden lo que DevOps es realmente. Ellos no lo entienden todava."
La postura de Ambler sobre DevOps va en contra de la sabidura convencional. DevOps apareci
en la lista de 10 ttulos 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
consultora de TI, Soluciones DTO. "El punto de DevOps es permitirle a su empresa reaccionar
ante las fuerzas del mercado lo ms rpido, eficiente y confiable como sea posible. Sin el
negocio, no hay otra razn para que estemos hablando de problemas DevOps, mucho menos
pasar tiempo resolvindolos".
Kevin Parker, experto de SearchSoftwareQuality, dijo que el nuevo reto que encaran los
gerentes de DevOps es toda la atencin que el tema obtiene por parte del negocio. "Lo que
antes era una tarea arcana, de elaborada coordinacin y gestin de proyectos es ahora en parte
diplomacia, parte protector y una buena cantidad de innovacin."

3. DevOps no es un sinnimo de integracin continua

DevOps se origin en Agile como una forma de apoyar la prctica gil de liberaciones de cdigo
ms frecuentes. Pero DevOps es ms que eso, dijo Ambler. "El hecho de que se practique la
integracin 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 dinmico mundo de la tecnologa, 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 lneas entre los desarrolladores y equipos de
operaciones mediante el fomento de los desarrolladores a tener una comprensin de los
principios de las operaciones, y alentar a los profesionales de operaciones para reforzar sus
habilidades de codificacin y automatizacin.
Como cada vez ms empresas mueven los datos hacia la Nube y necesitan mltiples centros de
datos de todo el mundo, los roles estratgicos son necesarios, y ah es donde el papel DevOps
encuentra su nicho.
El rol de DevOps apela a las empresas, pues est diseado para lograr ms con menos. El punto
de derribar los silos de TI tradicionales es aumentar la comunicacin entre los empleados. "Hay
que abrir lneas directas de comunicacin", dijo Robert Stinnett, Ingeniero de Automatizacin 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

Captulo 2

Los Principios de DevOps

DevOps no es solo una palabra nueva en nuestro vocabulario, sino tambin una nueva forma de
hacer negocios. El nombre "DevOps" (una combinacin de las palabras "desarrollo" y
operaciones") an no est en el diccionario Webster. Sin embargo, se est convirtiendo
rpidamente en un esfuerzo popular para la gestin y el uso comn 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 filosofa.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

1. Desarrollar y probar contra sistemas que emulan los de

produccin
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 produccin. De esta manera se puede observar cmo se comporta la aplicacin y tambin su
desempeo, mucho antes de que est lista para su despliegue.
Se busca probar la aplicacin bajo el ambiente ms parecido al real y simultneamente tambin
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 cmo se
comporta el ambiente que debe soportar la aplicacin y permite eventualmente crear las bases
para poder entonar ese ambiente en funcin de la aplicacin.

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 produccin. La automatizacin es esencial para poder crear procesos
que cumplan con las siguientes condiciones: iterativos, frecuentes, repetibles y confiables. Esto
le permite a la organizacin crear una cartera de entregables, donde los despliegues y las pruebas
se pueden realizar en forma automtica y continua. La ejecucin frecuente de despliegues
tambin 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

Tpicamente las organizaciones son muy buenas monitoreando aplicaciones y sistemas en
produccin, ya que existen muchas opciones para hacer esto y ellas utilizan herramientas que
permiten capturar las mtricas de produccin en tiempo real. Sin embargo, este monitoreo es
realizado sobre aplicaciones individuales, donde las aplicaciones no estn conectadas las unas
con las otras. DevOps exige que el monitoreo sea realizado ms temprano en el ciclo, requiriendo
adems que se haga monitoreo de las caractersticas funcionales y de las caractersticas nofuncionales de la aplicacin.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

En cualquier momento, a medida que las aplicaciones estn siendo desplegadas y probadas,
DevOps exige que se capturen mtricas de calidad y que sean analizadas. Este monitoreo
frecuente provee aviso tempranero sobre temas operacionales y de calidad que podran aparecer
posteriormente en la etapa de produccin. Adicionalmente, las mtricas deben ser capturadas
en un formato que sea entendible y utilizable para todos los interesados, incluyendo a los
responsables de las aplicaciones en las lneas de negocio.

4. Ampliar crculos de retroalimentacin

Uno de los principales objetivos de DevOps es permitir a las organizaciones reaccionar y poder
realizar cambios rpidamente en sus procesos de negocio. En la entrega de software, el objetivo
se transforma en proveer retroalimentacin en un corto tiempo y adems poder aprender
rpidamente de cada accin que se toma. Las organizaciones deben crear canales de
comunicacin que permitan a todas las partes interesadas accesar a la informacin y actuar sobre
la base de la retroalimentacin y por ello:

Desarrollo puede actuar ajustando sus planes de proyecto o sus prioridades.

Produccin (Operaciones) puede actuar mejorando los ambientes de produccin.

Las Lneas de Negocios pueden actuar modificando sus planes de implementacin.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

DevOps para principiantes

Captulo 3

Gestion de Versionamiento
La Gestin de Versiones es la encargada de la implementacin y control de calidad de todo el
software y hardware instalado en el entorno de produccin.
La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de Software Definitivo
(DSL), donde se guardan copias de todo el software en produccin, y el Depsito de Hardware
Definitivo (DHS), donde se almacenan piezas de repuesto y documentacin para la rpida
reparacin de problemas de hardware en el entorno de produccin.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

1. El repositorio
Un gestor de versionamiento es un sistema centralizado para compartir informacin. En su
ncleo est un repositorio, que es un almacn central de datos. El repositorio almacena
informacin en forma de un rbol de archivos (una jerarqua tpica de archivos y directorios). Un
nmero de clientes se conectan al repositorio, y luego leen o escriben esos archivos. Al escribir
datos, el cliente hace que la informacin est disponible para los otros; al leer los datos, el cliente
recibe informacin de los dems.

Figura 1

Cuando un cliente lee datos de un repositorio, normalmente ve nicamente la ltima versin

del rbol de archivos. Pero el cliente tambin tiene la capacidad de ver estados previos del
sistema de archivos. Por ejemplo, un cliente puede hacer preguntas histricas, como qu
contena este directorio el ltimo mircoles?, o quin fue la ltima persona que cambi este
archivo, y qu cambios hizo? Esta es la clase de preguntas que forman el corazn de
cualquier sistema de control de versiones: son sistemas que estn diseados 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: cmo permitir el sistema compartir informacin 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 compaeros 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

despus)

accidentalmente

Sally

sobre-escribirlos

pueda
con

su

propia versin nueva del archivo.

Mientras que la versin 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 versin 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 versin del archivo) y
probablemente por accidente. Esta es una situacin que definitivamente tenemos que evitar!
La solucin bloquear-modificar-desbloquear

Muchos sistemas de control de versiones

utilizan

un

modelo bloquear-modificar-

desbloquear para enfrentarse al problema, lo

cual es una solucin muy simple. En estos
sistemas, el repositorio slo 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 ningn
cambio en l. Si ella intenta bloquear el
archivo, el repositorio le denegar la peticin.
Todo lo que ella puede hacer es leer el archivo,
y esperar a que Harry termine sus cambios y libere su bloqueo. Despus 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 solucin copiar-modificar-fusionar

La mayora 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 versin final. El sistema de control de versiones a
menudo ofrece ayuda en la fusin, 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 simultneamente, 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 ms 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 ms 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

Captulo 4

Integracin Continua
Muchas veces, se tiende a pensar que la integracin continua es tener instalado el servidor de
integracin continua (por ejemplo Jenkins) y que este compile el cdigo peridicamente; o tener
automatizados los despliegues dndole a un botn desde dicho servidor. Pero la integracin
continua engloba mucho ms que esto. Es una serie de buenas prcticas, de comprobaciones
interconectadas entre s, para conseguir software de mejor calidad.
Martin Fowler define la integracin continua de la siguiente manera:
Prctica de desarrollo software donde los miembros del equipo integran su trabajo
frecuentemente, al menos una vez al da. Cada integracin se verifica con un build
automtico (que incluye la ejecucin de pruebas) para detectar errores de integracin tan
pronto como sea posible.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

1. Las buenas prcticas

Partiendo de la definicin de Fowler, poder identificar a los componentes e ideas claves de las
buenas prcticas de integracin continua.

Prctica de desarrollo de software

Para implantar integracin 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
podra ser que con cada subida de cdigo 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 cdigo
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 cmo es el desarrollo,
cul es el criterio para que el cdigo promocione de un entorno a otro, y qu se hace en cada
entorno.
Y si el cdigo no pasa algn punto hay que establecer cul es la estrategia para resolver el error,
quin se encarga de ello, cmo 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 todava no estn
implementados o que est programando otra persona. Y hasta que no se junta todo ese cdigo,
no son visibles los errores de integracin que se cometen.
Antes, lo que se tenda a hacer es que cada desarrollador programara de forma independiente y
luego al final se realizaba la integracin de todo el cdigo. Esto se traduce en integraciones
difciles, que tardan mucho en completarse y mucho sufrimiento, ya que hay muchos cambios,
mucho cdigo que integrar. Uno de los motivos por los que surge la integracin continua es para
evitar esto. La idea es que en vez de dejar la integracin para el final, se vayan haciendo pequeas
integraciones de cdigo frecuentemente.
La frase que podramos aplicar aqu es que si algo te cuesta, debes hacerlo ms 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 integracin continua

Implementar integracin continua conlleva un cambio en la forma de trabajo del equipo, en el
da a da de las personas, que debe ir siendo aceptado poco a poco.
Aqu enumeramos los pasos principales para implementar la integracin continua, y unos
pequeos consejos, puesto que debers adaptar los pasos a tu empresa, al software etc.

2.1 Conciencia a las personas y da informacin 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 integracin continua.
Incluso, podra 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 cmo lo mejoraran.
Adems, es importante ir formando al equipo en las nuevas tecnologas que vayas a implantar,
en hacer pruebas unitarias, de integracin, en buenas prcticas, patrones de diseo, 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-produccin y produccin), cules 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 integracin continua como Jenkins va a
ser un elemento de enlace para todo esto.
Es decir, vamos a intentar mejorar el desarrollo, introduciendo ms comprobaciones, pero
tambin vamos a intentar automatizar todos los procesos repetibles, manuales que se puedan

automatizar para invertir tiempo en otras cosas.

Por ejemplo, podramos programar el servidor de integracin continua para que cuando el cdigo
que alguien suba al control de versiones se compile y pase ciertas pruebas, se despliegue
automticamente y promocione a otro entorno.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

2.3 Tener clara la poltica de gestin y control de versiones

Sin control de versiones, la integracin continua no funciona. El servidor de integracin 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 integracin continua es necesario
pensar cmo vamos a combinar nuestra estrategia de control de versiones con la integracin
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) tambin influir qu herramienta de control de
versiones utilizis 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 ms fcil
y eso es algo a tener en cuenta.

2.4 Gestin de tareas y trazabilidad

Algo muy til para controlar los pequeos trozos de cdigo que se agregan al repositorio esto
son las herramientas de gestin de tareas, como Jira o Redmine.
Y otra cosa importante es conseguir trazabilidad entre las tareas o requisitos, y el cdigo, el cul
es el commit (la modificacin) del control de versiones en el que dicho requisito se ha
implementado. Esto es indispensable siempre, pero muy til cuando detectemos fallos en el
cdigo.
As tendremos controlado en qu commit del cdigo se ha dado el fallo y que hay
implementado y que no.

2.5 Automatizacin del build

Para automatizar el build (compilacin), puedes emplear scripts, herramientas como Ant o
Maven. Otro consejo es que intentes que la compilacin no tarde demasiado. Ve optimizando
el proceso de compilacin a lo largo del tiempo.
La compilacin es el primer paso dentro de la integracin 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 rpido sobre qu falla en la aplicacin.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

2.6 Definir cual va a ser el pipeline de integracin continua

Se debe pensar qu pasos, o por qu fases deber ir pasando el cdigo. Define un pipeline de
integracin continua (una serie de fases, pasos), que luego se programara en el servidor de
integracin continua.
En este caso distinguira entre las pruebas bsicas que deben pasarse cada vez que se hace una
subida al control de versiones, un smoke test para dar feedback rpido al desarrollador de si las
cosas estn medianamente bien y otra serie de pasos ms avanzados con pruebas ms a fondo
(Smoke test: Detecta lo ms pronto posible si los elementos crticos de la aplicacin no
funcionan.).

2.7 Elegir e instalar el servidor de integracin continua

Una vez hecho todos los puntos anteriores pasaramos a instalar y configurar el servidor de
integracin continua. Adems de implementar el pipeline que hemos definido previamente.
Si por ejemplo usas Jenkins como servidor de integracin 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 integracin continua. En su lugar, ve automatizando las pruebas del pipeline
definido que consideres ms primordiales primero y ve enlazndolas en el servidor cuando
estn listas.
Y no te olvides de que las pruebas que automatices son cdigo, que debers mantener a lo
largo del tiempo.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

2.9 Inspeccin continua

Por inspeccin continua se entiende el ir realizando anlisis de cdigo peridicamente (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 integracin continua, le va bien, tiene una estrategia de
pruebas y un pipeline de integracin continua fiable, se puede implementar la entrega continua

(dejar el software en un estado listo para pasar a produccin) y despliegue continuo (que cada
cambio en el cdigo, despus de pasar por todo el pipeline de integracin continua que
definimos, se suba a produccin).