Ciclo de vida del software, repositorios de código, análisis estático de código, pruebas software, integración continua, entrega continua, despliegue continuo, DevOps.
Security Incident Log Review Checklist by Dr Anton Chuvakin and Lenny ZeltserAnton Chuvakin
The log cheat sheet presents a checklist for reviewing critical system, network and security logs when responding to a security incident. It can also be used for routine periodic log review. It was authored by Dr. Anton Chuvakin and Lenny Zeltser.
Know Software Engineering very well and see the difference between the Software Programming & Software Engineering. Including other concepts as well as where you will know how this Software engineering is different for the building the software compared to do only the programming.
El desarrollo y mantenimiento de aplicaciones empresariales, más que una profesión se ha convertido en todo un arte al darles soporte y mantenimiento, cobra mayor importancia y trascendencia cuando: diferentes desarrolladores modifican la funcionalidad, se utilizan versiones de API´s y frameworks diferentes sobre la misma aplicación sólo porque a "alguien" se le ocurrió, se duplica código por el desconocimiento de la aplicación y por si fuera poco....... existe código muerto en las diferentes capas de la aplicación (si es que se puede identificar alguna) una situación que nunca sucede en nuestro ámbito. Si el panorama no fuera ya de por si complejo, el realizar las pruebas (de todos los módulos de la aplicación) y promover la liberación de una nueva funcionalidad resulta en ocasiones más costoso en tiempo y recursos que la nueva funcionalidad por si misma. La presente sesión demuestra por medio de casos de éxito las ventajas que proporciona el someter aplicaciones existentes y nuevas sobre un proceso de integración contínua estandarizando: el versionado del código, el uso de herramientas de construcción, la automatización de pruebas, la evaluación de código y promoción de nuevas liberaciones de aplicaciones productivas. Todo esto sobre un ciclo iterativo, controlado y auditado para un objetivo final, producir aplicaciones con calidad de código.
Esta presentación es parte del contenido del curso de Programación Avanzada impartido en la Universidad Rafael Landívar durante el año 2015.
Incluye los temas:
• Técnicas de programación
• Estilo y codificación
• Documentación
• Depuración
• Pruebas
Creado por Ing. Alvaro Enrique Ruano
Presentacion sobre cómo elaborar procesos de QA en proyectos de desarrollo de software desde una etapa temprana hasta la validación final del software.
Se realizará caso práctico con Selenium.
Charla en Universidad ORT 2014 - Testing técnico (automatización, mobile, pe...Federico Toledo
Esta fue una charla dada en la Universidad ORT en el año 2014. Los temas tratados fueron varios, relacionados a la industria y a la academia.
Agenda:
- Test execution automation
- Test design automation
- Monkop (mobile testing, performance and security)
- Performance testing
Testing técnico - Automatización en web y mobile para pruebas funcionales y p...Abstracta
Introducción a distintos aspectos de calidad y testing de software, enfocando en ciertos puntos desarrollados en Abstracta:
- testing automatizado (Selenium, GXtest, JUnit)
- generación de pruebas con model driven approaches usando UML, UTP, ATL (model to model) y Acceleo (Model to Text)
- smart monkey testing (Monkop - monkop.com) para probar automáticamente aplicaciones Android
- pruebas de performance con OpenSTA
De esta forma mostramos cómo estamos volcando la empresa a la investigación en la industria, investigación en la academia, desarrollo de productos y servicios de alto valor agregado.
Security Incident Log Review Checklist by Dr Anton Chuvakin and Lenny ZeltserAnton Chuvakin
The log cheat sheet presents a checklist for reviewing critical system, network and security logs when responding to a security incident. It can also be used for routine periodic log review. It was authored by Dr. Anton Chuvakin and Lenny Zeltser.
Know Software Engineering very well and see the difference between the Software Programming & Software Engineering. Including other concepts as well as where you will know how this Software engineering is different for the building the software compared to do only the programming.
El desarrollo y mantenimiento de aplicaciones empresariales, más que una profesión se ha convertido en todo un arte al darles soporte y mantenimiento, cobra mayor importancia y trascendencia cuando: diferentes desarrolladores modifican la funcionalidad, se utilizan versiones de API´s y frameworks diferentes sobre la misma aplicación sólo porque a "alguien" se le ocurrió, se duplica código por el desconocimiento de la aplicación y por si fuera poco....... existe código muerto en las diferentes capas de la aplicación (si es que se puede identificar alguna) una situación que nunca sucede en nuestro ámbito. Si el panorama no fuera ya de por si complejo, el realizar las pruebas (de todos los módulos de la aplicación) y promover la liberación de una nueva funcionalidad resulta en ocasiones más costoso en tiempo y recursos que la nueva funcionalidad por si misma. La presente sesión demuestra por medio de casos de éxito las ventajas que proporciona el someter aplicaciones existentes y nuevas sobre un proceso de integración contínua estandarizando: el versionado del código, el uso de herramientas de construcción, la automatización de pruebas, la evaluación de código y promoción de nuevas liberaciones de aplicaciones productivas. Todo esto sobre un ciclo iterativo, controlado y auditado para un objetivo final, producir aplicaciones con calidad de código.
Esta presentación es parte del contenido del curso de Programación Avanzada impartido en la Universidad Rafael Landívar durante el año 2015.
Incluye los temas:
• Técnicas de programación
• Estilo y codificación
• Documentación
• Depuración
• Pruebas
Creado por Ing. Alvaro Enrique Ruano
Presentacion sobre cómo elaborar procesos de QA en proyectos de desarrollo de software desde una etapa temprana hasta la validación final del software.
Se realizará caso práctico con Selenium.
Charla en Universidad ORT 2014 - Testing técnico (automatización, mobile, pe...Federico Toledo
Esta fue una charla dada en la Universidad ORT en el año 2014. Los temas tratados fueron varios, relacionados a la industria y a la academia.
Agenda:
- Test execution automation
- Test design automation
- Monkop (mobile testing, performance and security)
- Performance testing
Testing técnico - Automatización en web y mobile para pruebas funcionales y p...Abstracta
Introducción a distintos aspectos de calidad y testing de software, enfocando en ciertos puntos desarrollados en Abstracta:
- testing automatizado (Selenium, GXtest, JUnit)
- generación de pruebas con model driven approaches usando UML, UTP, ATL (model to model) y Acceleo (Model to Text)
- smart monkey testing (Monkop - monkop.com) para probar automáticamente aplicaciones Android
- pruebas de performance con OpenSTA
De esta forma mostramos cómo estamos volcando la empresa a la investigación en la industria, investigación en la academia, desarrollo de productos y servicios de alto valor agregado.
Las pruebas de software (software testing) se basan en la investigación empírica y técnica que permite proporcionar información objetiva e independiente sobre la calidad de la aplicación a la parte interesada o stakeholder. Forma parte crítica del proceso de control de calidad. Es por ello que no se puede subestimar las pruebas de software, si se desea garantizar un producto de calidad a los usuarios.
Cómo incluir videoconferencia en tu web usando la tecnología WebRTC y servidores de media open source y comerciales. Se explora en más detalle OpenVidu, una plataforma de videoconferencias con ediciones open source y comerciales
Curso de Angular 9 para desarrollo de aplicaciones SPA (Single Page Application).
● Tema 1: Introducción a Angular: TypeScript y herramientas
● Tema 2: Componentes
● Tema 3: REST y Servicios
● Tema 4: Aplicaciones multipágina: Router
● Tema 5: Librerías de componentes
● Tema 6: Publicación
Concurrencia y asincronía: Lenguajes, modelos y rendimiento: GDG Toledo Enero...Micael Gallego
Una vista panorámica de la situación actual de la concurrencia y la asincronía. Comparando modelos de concurrencia y técnicas de programación asíncrona en lenguajes de programación como Java, C/C++ y JavaScript.
Dev Tools para Kubernetes - Codemotion 2019Micael Gallego
Charla impartida entre Pablo Chico y Micael Gallego en la que se muestran algunas herramientas para mejorar la experiencia de desarrollo de aplicaciones cloud native para Kubernetes. Concretamente, se presenta cómo okteto puede reducir el tiempo empleado en el ciclo de change, build, push, deploy de pods Java en Kubernetes usando la sincronización de ficheros.
Ejemplos de código en https://github.com/micaelgallego/k8s-dev-tools-codemo19
Testing cloud and kubernetes applications - ElasTestMicael Gallego
Kubernetes applications are complex distributed systems composed by several microservices. When some end to end test is failing in these kind of applications, root cause is difficult without good observability tools. In this presentation, several tools are presented to make easier root cause analysis of cloud and kubernetes applications. One of the most interesting ones is ElasTest, a platform that integrates several open source tools to provide observability to e2e testing of complex distributed systems.
Kubernetes es una plataforma cada vez más utilizada para poner en producción aplicaciones y servicios. Todos los grandes proveedores cloud la ofrecen y también puede instalarse on premises. En estas slides presentaremos los concetos básicos de la plataforma y aprenderemos a desplegar aplicaciones.
Las slides se han usado en un curso gratuito que ha sido grabado y publicado aquí: https://www.youtube.com/watch?v=5ovqsvqwtZM
Testeando aplicaciones Kubernetes: escalabilidad y tolerancia a fallosMicael Gallego
Kubernetes se ha convertido en una de las plataformas preferidas para la puesta en producción de aplicaciones escalables y tolerantes a fallos. Estas características son muy interesantes, pero suponen un reto para los sistemas de integración continua. ¿Cómo se prueba de forma automática que una aplicación se comporta como se espera cuando existen fallos o cuando la carga crece de forma importante? Y si no lo hace, cuál es el motivo? El Caos testing nos ayuda a simular fallos (matar contenedores, cortar la red...) pero además necesitamos monitorizar la aplicación para conocer su comportamiento interno. En la presentación damos un repaso por las técnicas y herramientas más utilizadas en este ámbito.
OpenVidu es una plataforma para incorporar videoconferencia y video streaming en tus aplicaciones web. Es muy fácil de usar y tienes multitud de ejemplos con diferentes tecnologías. Además, es open source. Qué más se puede pedir?
Estas slides son una presentación a las pruebas de software. Para qué sirven, qué tipos de pruebas existen, qué librerías, frameworks y herramientas se pueden utilizar para implemenar pruebas automatizadas, etc.
Node.js es una tecnología cada vez más popular para el desarrollo de servicios web. Grandes abanderados de Java como Netflix están usando cada vez más JavaScript para implementar parte de su backend. Pese a esta realidad, muchos javeros como yo no quieren tocar JavaScript ni con un palo, y cuando hay que hacerlo, sólo en el browser.
Si eres javero y no te gusta JavaScript, en esta presentación tendrás una visión general sobre cómo desarrollar servicios web con Node.js. Verás cómo con TypeScript, async/await y frameworks como Nest y TypeORM no echarás de menos a Spring y JPA. Pero lo mismo pasa al revés, verás cómo en Java también puedes implementar apps con los mismos principios reactivos y funcionales tan comunes en Node.js.
Testing fácil con Docker: Gestiona dependencias y unifica entornosMicael Gallego
Docker es una tecnología que permite empaquetar el software de forma que se pueda ejecutar de forma sencilla y rápida, sin instalación y en cualquier sistema operativo. Es como tener cualquier programa instalado en su propia máquina virtual, pero arranca mucho más rápido y consume menos recursos. Docker está cambiando la forma en la que desplegamos software, pero también está afectando al propio proceso de desarrollo y particularmente al testing.
En este taller pondremos en práctica cómo usar Docker para facilitar la implementación de diferentes tipos de tests y su ejecución tanto en el portátil como en el entorno de integración continua. Aunque las técnicas que veremos se podrán aplicar en cualquier lenguaje de programación, los ejemplos estarán basados en Java y en JavaScript.
Using Docker to build and test in your laptop and JenkinsMicael Gallego
Docker is changing the way we create and deploy software. This presentation is a hands-on introduction to how to use docker to build and test software, in your laptop and in your Jenkins CI server
Como ser mas productivo en el desarrollo de aplicacionesMicael Gallego
Charla impartida en la Universidad Politécnica de Madrid presentando algunas técnicas y herramientas para ser más productivo en el desarrollo de aplicaciones
Docker para Data Scientist - Master en Data Science URJCMicael Gallego
Presentación de Docker en el Master en Data Science de la URJC en la asignatura de Arquitecturas en la nube. En esta asignatura hablamos de AWS, Azure, Docker, Kubernetes, Mesos
El Aprendizaje Basado en Proyectos y la Clase Invertida para acercar el mundo...Micael Gallego
En este artículo se describe una metodología docente que pretende emular en el aula el trabajo que los alumnos realizarán cuando finalicen sus estudios. Esta metodología combina el Aprendizaje Basado en Proyectos y la Clase Invertida y está diseñada para la asignatura de Desarrollo Web del Grado en Ingeniería del Software de la URJC. La metodología propuesta se aplicará en el curso 2016/2017 y supone una evolución de una metodología previa, aplicada en el curso 2015/2016 en la misma asignatura. Se espera que los cambios introducidos en esta nueva metodología mejoren los resultados obtenidos en el curso pasado.
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
3. 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
4. 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
13. 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
14. Repositorio de código
● Similares a sistemas como Dropbox, pero con
funcionalidades específicas para desarrollo
software
15. Repositorio de código
● 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)
19. 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...
25. 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
26. Pruebas de Software (Tests)
Servidor de Integración Continua
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
33. Pruebas de Software (Tests)
Servidor de Integración Continua
Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Tests
Unitarios
Análisis
de
código
fuente
Tests
de
Integración
35. 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
36. ¿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
37. 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
38. Deuda técnica
Lo que le
puede pasar
a tu código si
su deuda
técnica crece
y crece...
39. Deuda técnica
Lo que le
puede pasar
a tu código si
su deuda
técnica crece
y crece...
40. ¿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...
42. 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
43. 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
44.
45.
46.
47.
48. 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
51. Pruebas de Software (Tests)
Servidor de Integración Continua
Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Tests
Unitarios
Análisis
de
código
fuente
Tests
de
Integración
52. Pruebas de Software (Tests)
● 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
53. ● 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"
Pruebas de Software (Tests)
54. ● 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)
Pruebas de Software (Tests)
55. ● 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 de Software (Tests)
56. 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)
57. 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)
58. 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
60. Pruebas de Software (Tests)
Servidor de Integración Continua
Realimentación
Construcción
(Build)
Descarga de
dependencias,
compilación,
empaquetado
Tests
Unitarios
Análisis
de
código
fuente
Tests
de
Integración
61. Servidor de Integración Continua
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
Pruebas de Software (Tests)
62. Servidor de Integración Continua
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
Pruebas de Software (Tests)
64. ● 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
65. ● 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)
Repositorio de artefactos y entornos
67. ● 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
Repositorio de artefactos y entornos
69. Repositorio de artefactos y entornos
Entornos más habituales
User AceptanceTests
(Pruebas de usuarios reales)
70. ● 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
Repositorio de artefactos y entornos
71. ● 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
Repositorio de artefactos y entornos
72. ● 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...
Repositorio de artefactos y entornos
73. ● 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
Repositorio de artefactos y entornos
STAGING
74. ● 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
Repositorio de artefactos y entornos
76. 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
92. 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
97. "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
98. "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
111. Entornos donde se
publica el software para
que esté accesible para
los desarrolladores, las
pruebas automáticas,
las manuales...
Entrega Continua
Continuous Delivery
112. Entornos donde se
publica el software para
que esté accesible para
los desarrolladores, las
pruebas automáticas,
las manuales...
Despliegue Continuo
Continuous Deployment
122. De la idea a producción
http://www.eferro.net/2018/01/code-continious-delivery-germinando-una.html
123. “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
128. ¿Qué se necesita?
● Integración continua
● Tests automáticos (TDD)
● Código de calidad (Clean code)
129. Integración Continua
● 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
134. 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/
135. 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
138. Despliegue Release
● Subir el software a las máquinas
● Verificaciones técnicas (sin
usuarios)
● No afecta al servicio
139. 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
141. Blue / Green Deployment
La “build” (paquete) sale de CI y está lista para desplegarse
142. Se despliega en el entorno de producción junto con la
versión anterior (pero sin publicarse a los usuarios)
Blue / Green Deployment
143. Se publica a los usuarios y se recibe feedback
Blue / Green Deployment
144. Si se detectan problemas, se puede volver a la versión
anterior rápidamente
Blue / Green Deployment
145. ● 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
Blue / Green Deployment
146. ¿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
147. Pruebas en producción
(Testing in production)
● Pruebas por usuarios reales
● En entorno real (de producción)
● Sin afectar a todos los demás
167. ● 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
168. 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)