¿Cómo poner software de calidad en manos del usuario de forma rápida?

PreparaTIC
Micael Gallego
Correo: micael.gallego@urjc.es
Twitter: @micael_gallego
02-2021
¿Cómo poner software de
calidad en manos de los
usuarios de forma rápida?

¿Quién soy?
@micael_gallego micael.gallego@urjc.es @micaelgallego
Micael Gallego
Profesor Universitario, Formador y Consultor
Desarrollador software

http://codeurjc.es https://www.codeurjc.es/mastercloudapps/
Desarrollo y Despliegue de
Aplicaciones en la Nube
Laboratorio de
Software
Cloud Computing
Distributed Systems
WebTechnologies
Extreme Programming
AutomatedTesting
CI / CD
Consultoría y
Formación
Plataforma de
Videoconferencia
http://openvidu.io

Ciclo de vida del software
1
¿Cómo poner software de calidad en
manos de los usuarios de forma rápida?
2 DevOps y despliegue continuo

Ciclo de
vida del
software
1

¿Cuál es el ciclo de vida
del software?

Ciclo de vida del software
Software listo para ser
desplegado (puesto a
disposición de los usuarios)
Control
de
Calidad

Repositorio de código
● El software se suele desarrollar en
equipos de desarrolladores
● Los desarrolladores tienen que compartir
el código que van desarrollando con los
demás
● El código de cada desarrollador se
integra para crear la app
● Para ello usan los repositorios de código

● Similares a sistemas como Dropbox, pero con
funcionalidades específicas para desarrollo
software

● Los sistemas de control de versiones
(VCS) (Version control system) son
herramientas para desarrollo colaborativo
● Otros nombres:
● Gestor de código fuente (SCM) (Source
Code Manager)
● Repositorios de código (Code repository)

Tipos de repositorio de código

Repositorios git
● Zonas de trabajo
independientes
(ramas, branches)
● Funcionalidades,
experimentos,
bug fixes...

Servidores para repositorios git

GitHub
● GitHub es un servicio para desarrolladores que
proporciona repositorios git en sus servidores
● Gratuito para repositorios públicos con software libre
● Comercial para otros servicios
● Funcionalidades adicionales:
● Historias de usuario, Bug reports, wiki, releases...

GitHub
Comentarios
asociados a
cambios en el
código
(code review)

Servidor de
Integración Continua

Servidor de Integración Continua
● Un servidor que monitoriza el repositorio de
código para detectar cuando un desarrollador
publica un cambio en el código
● Cada vez que hay un cambio en el código, el
servidor de integración continua hace un
control de calidad del mismo
● El control de calidad pasa por diferentes
etapas

Pruebas de Software (Tests)
Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Tests
Unitarios
Análisis
de
código
fuente
Tests
de
Integración
Software pipeline

Realimentación

Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Tests
Unitarios
Análisis
de
código
fuente
Tests
de
Integración

Análisis de código fuente
● La calidad del código es un indicador sobre
cómo de rápido los desarrolladores pueden
añadir valor a un sistema software
● El análisis estático del código (SCA) consiste
en realizar un análisis de un programa sin
ejecutarlo
● En la mayoría de los casos el análisis se realiza
sobre código fuente, aunque puede hacerse
sobre el bytecode o binario

¿Por qué medir la calidad del código?
● El código fuente es el corazón de un sistema
software
● Desarrolladores (casi nunca) escriben nuevo
software, siempre mantienen código heredado
● Un software (casi) nunca se termina
● Lo que no se mide, no se puede mejorar
● Hay que tener en cuenta la teoría de las
ventanas rotas

Deuda técnica
● El ahorro inicial en calidad, pasará factura
a medio plazo en forma de dificultad para
añadir más funcionalidad
● Si la deuda crece lo suficiente, el equipo
empleará más tiempo en “pagar la deuda”
del que invierta en incrementar el valor

Deuda técnica
Lo que le
puede pasar
a tu código si
su deuda
técnica crece
y crece...

¿Qué determina la calidad del código?
● Bugs y bugs potenciales
● Violación de los estándares de código
● Código duplicado
● Falta de (suficientes) tests
● Mala distribución de la complejidad
● Diseño espagueti (complejidad ciclomática,
referencias circulares...)
● Pocos o muchos componentes...

Herramientas y plugins
http://checkstyle.sourceforge.net/
http://pmd.github.io/ http://findbugs.sourceforge.net/
https://www.sonarsource.com/

Sonarqube
● Reglas
● Reglas de formato o estilo de código
● Buenas prácticas en el uso de funcionalidades
del lenguaje o librerías
● Detección de malos olores en el código
● Vulnerabilidades de seguridad
● Detección de mal funcionamiento con análisis
formal

Sonarqube
●Sonar es un lugar centralizado para
gestionar la calidad del código
●Ofrece informes visuales de los
proyectos
●Permite analizar la evolución de las
métricas a lo largo del tiempo

Sonarqube
● Métricas: Issues (Malos olores)
● Posibles bugs
● Posibles problemas de seguridad
● Violaciones de las reglas de estilo
● Números mágicos en el código

Sonarqube
● Métricas: Issues (Malos olores)

● Escribir software libre de defectos, es sumamente
difícil
● No existen métodos formales que se puedan
aplicar a software real para demostrar que no
existen defectos

● Una de las mejores formas que tienen
los desarrolladores softwares de tener
un grado razonable de certeza de que
el software desarrollado se comporta
como se espera es probar su
funcionamiento en ciertas
circunstancias
● A estas ejecuciones o ensayos de
funcionamiento se las denomina
"pruebas" o "tests"

● Al ejercutar un caso de prueba (de forma
manual o automática) pueden ocurrir dos
cosas:
● Que la prueba sea un éxito (SUCCESS): El
sistema se comporta de la forma esperada.
Cumple con los requisitos. En esa prueba no
se observa ningún defecto. (VERDE)
● Que la prueba falle (FAIL): El sistema no se
comporta de la forma esperada. No cumple
con los requisitos. La prueba ha puesto de
manifiesto un defecto o bug en el SUT. (ROJO)

● Existen muchos tipos de pruebas
● Las pruebas se pueden clasificar
atendiendo a diferentes criterios (tamaño,
quién las crea, qué prueban…)
● Tests funcionales vs no funcionales
● Tests unitarios vs Tests integración vs Tests
de sistema

Pruebas unitarias
● Son aquellas pruebas que verifican el
comportamiento de las partes internas del
código
● Se ejecutan muy rápidamente porque no
acceden al disco ni se conectan a otros
sistemas
● Son ejecutadas por el desarrollador de forma
habitual mientras desarrolla
● Son las que se desarrollan cuando se aplica el
Test Driven Development (TDD)

Pruebas de integración
● Son aquellas pruebas que verifican cómo los
módulos del software se integran entre sí
(Bases de datos, envío de correos...)
● Tardan más en ejecutarse porque se conectan
con otros sistemas mediante protocolos de red
● Necesitan más recursos para ejecutarse, el
desarrollador no las ejecuta frecuentemente
(suelen impedir el trabajo con el ordenador
durante la ejecución)

Pruebas de sistema (e2e)
● Prueban el sistema completo, simulando las
interacciones de un usuario usando la interfaz de
usuario (UI)
● Pueden ser funcionales o no funcionales
● Son las que más tardan más en ejecutarse porque
involucran todos los elementos de la aplicación
● Simular las interacciones del usuario de forma
automática es un proceso mucho más costoso
que implementar las pruebas unitarias y de
integración

Pirámide del testing
https://martinfowler.com/articles/practical-test-pyramid.html

Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Análisis
de
código
fuente
Test
Unitarios
Tests
de
Integración
Repositorio
artefactos
Package Deploy
Tests
sistema
e2e
Entorno
dev

Repositorio
de artefactos y
entornos

● Cuando el software pasa
algunos controles de calidad,
se empaqueta en un
artefacto
● El formato del artefacto
depende de la tecnología
utilizada (.zip, .exe, carpeta...)
● Usando el artefacto, el
software se puede desplegar
en cualquier entorno
Repositorio de artefactos y entornos

● Los repositorios de
artefactos alojan los
artefactos generados en
el pipeline de CI
● Existen repositorios
específicos (para una
tecnología concreta) o
genéricos (para múltiples
formatos)

● Un entorno (environment) es un despliegue de
una aplicación (generalmente web)
● Cuando se empaqueta una aplicación web, se
despliega en un entorno llamado “dev”
● “dev” es interno, no está disponible para los
usuarios
● Ese entorno se usa para realizar los tests de
sistema (e2e) o para que los desarrolladores
realicen pruebas manuales

Entornos más habituales

Entornos más habituales
User AceptanceTests
(Pruebas de usuarios reales)

● Entorno de desarrollo DEV:
● Se usa para tests de sistema y para ser
manipulado por los desarrolladores.
● Se pueden tener tantos entornos dev como
sean necesarios
● Se actualizan en cada cambio del código o a
petición del desarrollador

● Entorno de Quality Assurance QA:
● Se usa para pruebas manuales por el equipo
de QA (si existe)
● Se suele tener un único entorno QA
● Se actualiza cuando el código está estable
como para ser probado manualmente

● Entorno de User Acceptance Test (UAT):
● En contextos en los que es posible, es un entorno
usado por un grupo de usuarios para validar el
software
● Se suele tener un único entorno UAT
● Se actualiza con el código estable y listo para
producción
● Se le suele llamar versión BETA, Preview...

● Entorno de Staging:
● En ciertos contextos existe un entorno en el que se
realizan pruebas no funcionales llamado staging
● Es el entorno más parecido al de producción, pero sin
usuarios reales
● Se actualiza con el código estable y listo para
producción
● También se le llama PRE o PRE-Producción
STAGING

● Entorno de Producción:
● El software está publicado a los usuarios
● Se actualiza en cada release
● Generalmente se tiene que parar el servicio
(downtime), pero nuevas técnicas permiten
actualizar el software sin que sea necesario

Conclusiones
● Los repositorios de código permiten compartir el
código entre los desarrolladores
● Los servidores de integración continua verifican la
calidad del código cada vez que se publica un
cambio en el repositorio
● Si los controles pasan, el código se publica en un
repositorio de artefactos y se despliega en
diferentes entornos para ser sometido a más
pruebas
● Finalmente, se publica en el entorno de
producción

DevOps y
Despliegue
Continuo
2

¿Quién participa en la
creación y puesta a
disposición de los usuarios
del software?

Developer
Desarrollador software, programador, analista,
arquitecto

Operaciones
Administrador de sistemas, sysadmin, admin, DBA

Negocio / UX / QA / Diseño
Todos los demás

https://msdnshared.blob.core.windows.net/media/2016/06/image846.png
https://msdnshared.blob.core.windows.net/media/2016/06/image846.png

https://medium.com/@yevgeniy.zhitomirskiy/what-is-devops-9a1acc0c2a28

http://www.wirfs-brock.com/PDFs/QA2AQThree.pdf

https://blog.rocketsoftware.com/2015/05/silo-madness-put-end-silos-devops-alm/#.XOhnd3UzbRY

Desarrollo en cascada
https://medium.com/@davidjbland/the-state-of-waterfall-9e06a64665aa

Metodologías ágiles
Sprints de 2 semanas
Feedback constante

Metodologías ágiles
Sprints de 2 semanas
Feedback constante
?

Ciclos de publicación (release)
● Se publica una nueva versión a los usuarios
cada varios meses (4, 6, 12...)
● Hay que dejar de parar el servicio para
hacerlo
● Se hace por la noche para reducir el impacto
en negocio (pero puede durar varios días)
● Suele haber problemas, suele ser un evento
estresante

https://medium.com/signal-sciences-labs/more-silo-smashing-ideas-bringing-infosec-and-devops-together-c338eb3b36ad

https://www.accenture.com/us-en/blogs/blogs-reshma-shinde-devops-transformations-operations

"DevOps es un conjunto de prácticas
que tienen como objetivo reducir el
tiempo desde que se añade una
funcionalidad (o se soluciona un
problema) en un producto software
y este cambio llega a producción,
siempre asegurando la calidad”
Len Bass, Ingo Weber, and Liming Zhu
DevOps: A Software Architect's Perspective. 2015

"DevOps es una cultura, movimiento
o práctica que enfatiza la
colaboración y comunicación de los
desarrolladores software y otros
profesionales de las tecnologías de
la información mientras automatiza
el proceso de la entrega de software
y los cambios en la infraestructura”
https://www.youtube.com/watch?v=HnWuIjUw_Q8

https://www.accenture.com/us-en/blogs/blogs-reshma-shinde-devops-transformations-operations
DevOps

https://www.telehouse.com/2016/03/devops-how-a-culture-of-empathy-creates-massive-productivity/
Damon Edwards y John Philips
a principios de los 2000s como
una forma de definir la cultura
de la empatía
Principios DevOps

https://www.telehouse.com/2016/03/devops-how-a-culture-of-empathy-creates-massive-productivity/
● Culture > Gente, procesos, herramientas
● Automation > Scripts, infraestructura como
código, contenedores
● Measurement > Mide todo
● Sharing > Colaboración, realimentación
Principios DevOps

https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0

Prácticas DevOps
https://devops.com/eight-critical-devops-practices-innovate-deliver-repeat/

https://www.linkedin.com/pulse/9-critical-steps-devops-transformation-enterprises-sakthi-vadivelu/

Integración continua,
entrega continua y
despliegue continuo

Continuous Integration

Entrega Continua
Continuous Delivery
Software listo para ser
desplegado (puesto a
disposición de los usuarios)

Entornos donde se
publica el software para
que esté accesible para
los desarrolladores, las
pruebas automáticas,
las manuales...
Entrega Continua
Continuous Delivery

Entornos donde se
publica el software para
que esté accesible para
los desarrolladores, las
pruebas automáticas,
las manuales...
Despliegue Continuo
Continuous Deployment

DevOps Report 2016
https://puppet.com/resources/whitepaper/2016-state-of-devops-report

Saber más...
https://es.slideshare.net/jallspaw/1
0-deploys-per-day-dev-and-ops-co
operation-at-flickr
10+ Deploys Per
Day: Dev and Ops
Cooperation at
Flickr
https://conferences.oreilly.com/v
elocity/velocity2009/public/sched
ule/detail/7641
2014 2016
2009 2010

¿Cómo se implementa el
Despliegue Continuo?

http://www.eferro.net/2018/01/code-continious-delivery-germinando-una.html
Eduardo Ferro Aldama
https://youtu.be/hbggtXmQcf8

Gestión del riesgo / Adaptabilidad

De la idea a producción
http://www.eferro.net/2018/01/code-continious-delivery-germinando-una.html

“Rolling release, rolling update, in software
development, is the concept of frequently
delivering updates to applications.This is in
contrast to a standard or point release
development model which uses software versions
that must be reinstalled over the previous version”.
https://en.wikipedia.org/wiki/Rolling_release
Reducción del tiempo / aumento
frecuencia

¿Qué se necesita?
Sistema de despliegue
fiable y rápido

¿Qué se necesita?
● De commit a producción < 15m
● Despliegue 100% fiable
● Despliegue sin pérdida de
servicio (Zero downtime)

¿Qué se necesita?
Recuperarnos rápido
(en caso de fallo)

¿Qué se necesita?
Confiar en el software que
vamos a desplegar
en cualquier momento

¿Qué se necesita?
● Integración continua
● Tests automáticos (TDD)
● Código de calidad (Clean code)

● Integrar lo que hace cada desarrollador
al menos 1 vez al día
● Cada contribución (commit) se construye
y verifica (tests)
● Trunk based vs Feature branches

● Rama por funcionalidad (Feature branches)

● Trabajar en trunk / máster > Integración continua

● ¿Qué hacemos con las funcionalides “sin
terminar”?
https://martinfowler.com/articles/feature-toggles.html
Feature toggles
(Selector de funciones)

Feature toggle
https://launchdarkly.com/blog/beta-testing-using-feature-flags/

Tests Automáticos
● Confiar en que el
código “funciona”
siempre
● Podemos desplegar en
cualquier momento
● Test Driven
Development
https://josemyduarte.github.io/2018-12-09-tdd-outside-in/

Código de calidad
● Que pueda evolucionar
a lo largo del tiempo de
forma sostenible
● Sin complejidad
innecesaria
● Para que se puedan
hacer tests
automáticos

¿Qué se necesita?
Diferenciar entre
despliegue y release

Despliegue Release
● Subir el software a las máquinas
● Verificaciones técnicas (sin
usuarios)
● No afecta al servicio

Despliegue Release
● Subir el software a las máquinas
● Verificaciones técnicas (sin
usuarios)
● No afecta al servicio
● Las nuevas funcionalidades se
activan
● Los usuario empiezan a usarlas

Blue / Green Deployment
La “build” (paquete) sale de CI y está lista para desplegarse

Se despliega en el entorno de producción junto con la
versión anterior (pero sin publicarse a los usuarios)

Se publica a los usuarios y se recibe feedback

Si se detectan problemas, se puede volver a la versión
anterior rápidamente

● Cuando hacemos release de una
nueva versión llega a todos los
usuarios
● Las nuevas funcionalidades de la
release pueden fallar o necesitar
refinamiento
● Necesitamos feedback de los
usuarios cuanto antes

¿Podemos hacer que sólo se active la
release para algunos usuarios?
● Se reduce el impacto en caso de
problemas
● Se recibe feedback de un grupo reducido
de usuarios
● Se mejora la funcionalidad y se publica a
los demás
● Los usuarios “reales” también prueban

Pruebas en producción
(Testing in production)
● Pruebas por usuarios reales
● En entorno real (de producción)
● Sin afectar a todos los demás

Testing in production
Alex Soto
Red Hat Engineer
@alexsotob

Producción ha dejado de
ser un entorno sagrado

La nueva pirámide? del testing

Dark Launches
La nueva versión se despliega primero a usuarios internos

Dogfooding
https://appinstitute.com/dogfooding-in-business/
https://deviq.com/dogfooding/
Come tu propia
comida de perro

Canary Release
La nueva release (build) está lista para ser desplegada

Canary Release
Se despliega en el entorno de producción, sin usuarios

Canary Release
Sólo algunos usuarios empiezan a usar la nueva release

Canary Release
Su número crece en función del feedback recibido

Canary Release
El número es cada vez mayor

Canary Release
Finalmente no quedan usuarios usando la versión anterior

Herramientas y servicios para
implementar DevOps

Herramientas
http://www.netforthtech.com/blogs/best-10-devops-tools-for-every-software-development-company/

● DevOps es una cultura en la que
desarrolladores y administradores
colaboran estrechamente y tienen los
mismos objetivos
● Desplegar frecuentemente permite
responder antes a las necesidades
de los usuarios y reduce los errores
y caídas del servicio
Conclusiones

Conclusiones
● Desarrollo con ciclos cortos, con realimentación para
poder adaptarse y conocer
● El software tiene que llegar a los usuarios reales, a
producción
● Hay que eliminar los silos y fomentar la colaboración
● El código debe estar preparado para desplegarse en
cualquier momento (Integración continua)
● El despliegue tiene que ser rápido, fiable y sin detener
el servicio (Despliegue continuo)

¿Cómo poner software de calidad en manos del usuario de forma rápida?

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a ¿Cómo poner software de calidad en manos del usuario de forma rápida?

Similar a ¿Cómo poner software de calidad en manos del usuario de forma rápida? (20)

Más de Micael Gallego

Más de Micael Gallego (19)

¿Cómo poner software de calidad en manos del usuario de forma rápida?