1

2
4
5
Notas del instructor:
La automatización cambia el enfoque hacia las tareas de ingeniería
Esta es una dispositiva animada. Presione la tecla Enter para avanzar la dispositiva.
Explica la matriz a los participantes tal como esta en la dispositiva.

Notas del participante:

La automatización cambia el enfoque hacia las tareas de ingeniería
La imagen muestra los cuadrantes de la clasificación de tareas por Charles Perrow. La
matriz esta basada en dos dimensiones: Tarea de la habilidad de analizar y la tarea de
variabilidad. Su distinción:

• La Tarea para analizar se define como una extensión que cuando se encuentra con
una excepción, se conocen métodos analíticos para tratar con ello.
• La Variedad de tareas se define por el número de excepciones a los procedimientos
estándares estimulados en la aplicación de una tecnología dada.

Tipos de tareas:
• Rutinarias: Caracterizadas por la carencia de excepciones y su profundidad de
compresión. Se realiza la fabricación de tecnología tradicional, como la tarea de la

6
 línea de producción que pertenecen a esta categoría.
• De oficio: Caracterizadas por la carencia de excepciones e resultados imprevisibles
que son difíciles de analizar. Las tareas de estructuración que exigen la elaboración
de nuevos diseños para resolver problemas de construcción es uno de los ejemplos
de la tecnología de oficio aplicada.
• La Ingeniería: Caracterizadas por la carencia de excepciones y su profundidad de
compresión. Los métodos estándares y aceptados están disponibles para dar solución
a los problemas. El diseño de Software y tareas de codificación pertenecen a esta
categoría. Contadores, la mayoría de ingenieros y técnicos de laboratorio usan
tecnología de ingeniería.
• No rutinarias: Caracterizadas por muchas excepciones y pobre compresión. Los
problemas aparecen frecuentemente sin ninguna solución existente. Las tareas de
Investigación y desarrollo pertenecen a esta categoría. La ingeniería espacial
comercial es un ejemplo de tecnología no rutinaria.

Considerando el proceso de entrega de Software, muchas de las tareas de entrega de

Software tienen relativamente una baja tarea de variabilidad y altas tarea para analizar
o el proceso de entrega de Software se puede transformar usando tareas con baja
variabilidad. Un análisis de valor de flujo puede determinar por donde los procesos
pueden ser mejorados y ayudan en decidir la identificación de tareas de alta habilidad
de análisis y de baja variabilidad. Un valor de flujo de análisis pueden ayudar a
determinar los procesos que pueden mejorar y ayuda a determinar a identificar las
tareas con baja variabilidad y altas posibilidades para analizar.
Una vez que estos manuales de tareas rutinarias son identificadas, estas tareas pueden
ser automatizadas con ingeniería. La evaluación de ejecución escrita (manual) y la
compilación de códigos (manual) son ejemplos de tareas rutinarias dentro de un
proceso de entrega del Software.

Esto resulta en un cambio, donde los miembros del equipo de Entrega de Software
ejecutarán principalmente las tareas con alta variabilidad y alta posibilidades de
analizar. En otras palabras, tareas de ingeniería. Esto requiere que una empresa se base
en una estructura orgánica, grandemente autónoma, multidisciplinaria, auto
organizada, y equipos de ingeniería. Las organizaciones deben aplicar los principios de
DevOps.

6
Notas del participante:
La automatización cambia el enfoque hacia las tareas de Ingeniería
Cuando los procesos son altamente programados y automatizados, resultarán con la
productividad prevista y estandarizada. Los procesos automatizados son repetitivos. El
costo del proceso de ejecución es minimizado. Joan Woodward definió la complejidad
técnica como una extensión donde el proceso de producción puede programarse y por
tanto se puede controlar y volverse previsto. En otras palabras, la automatización
resulta con la productividad prevista y estandarizada. Estos conceptos se pueden aplicar
a los procesos de entrega de Software.

7
Notas del participante:

Implementación automatizada: ¿Qué es la implementación de aplicaciones?

Proporcionar una nueva funcionalidad es siempre un punto de choque tradicional entre

el desarrollo y las operaciones, ya que las operaciones son responsables de la
continuidad. A las unidades de negocio les gustaría tener una nueva funcionalidad en la
producción lo antes posible, mientras que la gestión de servicio se encarga de
mantener las aplicaciones en una perspectiva técnica y las operaciones del alojamiento
de las aplicaciones (hosting).

El despliegue de aplicaciones es donde se encuentran los dos mundos y hay mucha

confusión en identificar el límite de estos.

Los desarrolladores suelen ocuparse de:

• Comprensión de las funciones solicitadas

• Diseño de componentes

8
• Escribir código
• Escribir casos de prueba
• Compilar código
• Código de prueba

Generalmente, un Operador se ocupa de:

• Instalación del hardware del servidor y del software operativo (SO)

• Configuración de servidores, red y almacenamiento
• Supervisión de servidores
• Respuesta a interrupciones
• Aplicación de medidas de seguridad
• Mantener protocolos de recuperación ante desastres

Nota: Es esencial que, especialmente en los límites de la organización, todo funcione

como sea posible. La repetibilidad, estabilidad y consistencia son fundamentales para el
buen funcionamiento.

Notas del instructor:

Implementación automatizada: ¿Qué es la implementación de aplicaciones?

Esta es una diapositiva animada. Pulse la tecla Enter para avanzar la diapositiva. Esta
diapositiva visualiza la implementación de un paquete de software versionado en varios
entornos. Explique a los participantes que la capacidad de implementar el mismo
paquete versionado en varios entornos es importante. Los entornos deben ser
coherentes y los parámetros de configuración específicos deben ser externalizados
utilizando archivos de configuración / diccionarios. Estas capacidades garantizan un
comportamiento uniforme en los entornos y la trazabilidad.

8
Notas del instructor:

Beneficios de la implementación automatizada

Antes de presentar la diapositiva en la clase, pregunte a los participantes cuáles son los
beneficios de la automatización del despliegue. Animar a los participantes a participar
en la discusión y resumir los resultados.

9
Notas del participante:
DevOps permite que los equipos se enfoquen en el Valor de Entrega
El desarrollo de tecnología ha resultado en más y más tipos de tareas que hoy en día
pueden ser automatizadas fácilmente. La automatización, combinada con otros
principios de DevOps garantiza que los equipos se enfoquen en la entrega de valor. Este
deseo de enfoque es el primero de los 14 principios enlistados en el Manifiesto Ágil:
“Nuestra máxima prioridad es satisfacer a los clientes a través de la Entrega Continua y
temprana del valioso Software”. Los equipos se deberían enfocar en entregar valor
empresarial y todo lo que entorpece debe ser eliminado. La automatización se puede
aplicar en muchas actividades en el proceso de entrega del Software. Como resultado,
los equipos de DevOps se enfocan más en las tareas de ingeniería requeridas para la
entrega del valor de Software. Adicionalmente, pueden utilizar la entrega de proceso de
Software el cual Entrega Continuamente nuevas características de Software utilizado un
flujo de optimización.

La práctica de la Entrega Continua depende considerablemente en la automatización

para optimizar los procesos de entrega de Software. La Entrega Continua esta descrita
con más detalles en los temas posteriores.

10
Notas del Instructor:
Por favor explicar los conceptos claves de la definición de la Entrega Continua.

Notas del participante:

La definición de Entrega Continua por Jez Humble describe características claves (en
negrita) de la Entrega Continua. Estas características no solo requieren automatización.
La Entrega Continua aplica prácticas abarca el proceso, las personas, y tecnología. Dada
esta definición, la Entrega Continua y DevOps están estrechamente asociadas.

Los equipos que han adoptado la Entrega Continua definida por las características
enlistada en la definición de Jez Humble son altamente efectivas. Han tenido éxito en
lograr:
• Aumentar la velocidad y repetitividad en la automatización
• Agilidad como no hay WIP.
• Flujo en la entrega.
• Manera autónoma de funcionar.
• Hacer las cosas correctas de la manera correcta.

11
Notas del Instructor:
Preguntar a los participantes de los beneficios de la Entrega Continua, que han
observado en su organización. Debate las ventajas claves en la clase.

Notas del participante:

Autonatizacion De La Entrega Continua:
Automatización del proceso de entrega del Software es uno de la
los medios principales de entrega rápida, económica, y mejor entrega.
• Rápida porque:
• La elaboración de la tarea automatizada no depende de la disponibilidad humana, el
tiempo de espera se elimina.
• La elaboración de la tarea automatizada no requiere tiempo de interacción humano -
maquina.
• La elaboración de la tarea automatizada reduce la necesidad (manuales) tareas de
meta (como la revisión de un documento de instalación)

• Económico porque:
• La elaboración de la tarea automatizada es más fiable que la elaboración de tareas

12
 manuales. Los errores en la elaboración manuales son caras y no se podrían
detectar inmediatamente.
• La elaboración de la tarea automatizada es más repetitiva que las tareas de las
elaboración manuales.
• La elaboración de la tarea automatizada no requiere esfuerzo humano (que es más
caro que las maquinaria de tiempo).
• La elaboración de la tarea automatizada necesita estandarización, basados en
mínimos requerimientos. Cada variación requiere procesos y mantenimiento
precisos.

Superior porque:
• La elaboración de la tarea automatizada es predecible, estandarizada, fiable y los
resultados son repetitivos.
• Automatización elimina errores en la elaboración de tareas manuales.
• Automatización (con automatización de prueba) resulta en un rápido feedback, los
defectos son detectados lo más temprano posible.
• Automatización permite evaluación de medidas determinadas de la presentación del
Software entregado.

No es solamente automatización
Sin embargo, automatización existente de las tareas y procedimientos para los
tradicionales procesos de proyectos-determinados y de organizaciones no resultaría en
las características de definición de Entrega Continua. Automatización no solo es una
implementación de actividad técnica. equipos específicos con capacidad, actitud,
agilidad y principios Lean, y comportamiento son requeridos para implementar
exitosamente la Entrega Continua. Estos requerimientos de no automatización deben
de llevar a la actual necesidad de la tarea de automatización e implementación de la
tarea de automatización. Los principios y técnicas fueron en gran parte tratados en el
modulo 5.

En resumen, Entrega Continua:

• El equipo se esfuerza en optimizar el flujo de entrega del Software. El equipo usa
técnicas como el análisis del flujo de valor para reducir la duración de ciclo de
entrega.
• El equipo es multidisciplinario, auto organizado, y autónomo.
• El equipo se asegura de que ellos se pueden enfocar en entregar negocios con valor

12
 agregado en las actividades de ingeniería, como escribir códigos para un nueva
función. El equipo identifica pro-activamente y elimina manuales de tarea de suporte
de entrega rutinaria usando automatización.
• El equipo trabaja juntos como una unidad de entrega altamente efectivo, predictible,
con resultados altamente de calidad.
• El equipo se asegura las presentaciones son entregadas correctas desde el primer
comienzo, listas para producción. Que la calidad son este afectada.
• El equipo mejora la velocidad, calidad, fiabilidad, y repetitividad de los procesos
usando automatización.
• El equipo aplica mejora de nomás continuadas. El equipo mide el impacto de las
entregas de las presentaciones, para asegurarse que las mejoras están basadas en
medidas (negocios) resultados (feedbacks).
• El equipo se asegura que las presentaciones requieren esfuerzo limitado para que
sean entregados y lanzados rápidamente en producción.

12
13
Notas del participante:
Entrega Continua puede ser adoptada con tres bases principales:
• Automatización Rigurosa: automatización de entrega de actividades del software,
como ejecución de pruebas y resultados de despliegue, hace que el proceso de
entrega del software sea rápida, económica, y superior. Ejecución de tareas de
automatización no requieren interacción de tiempo en las maquinas manuales
(humano), elimina tiempo de espera como resultado de dependencia en las tareas
manuales , y elimina la necesidad de tareas manuales de la ejecución de las
actividades de validación. Resultados de Automatización son altamente fiables,
repetibles, procesos estandarizados que transforman ideas de negocio en software
funcional en producción.

• Feedback extremo: Feedback extremos ayuda al grupo a analizar: la efectividad del

proceso de entrega del software, la efectividad (valor real del negocio) de
presentaciones que han entregado, hacen que los grupos experimenten con (la
implementación de) las presentaciones del software usando métodos estadísticos en
las evaluaciones y Feedback reales de los clientes.

• Cambio Continuo: Los dos primeros principios: Automatización Rigurosa y

Comentarios extremos, permite cambios continuados. El grupo utiliza Feedback
colectivo, ideas y observaciones de los miembros del grupo, y las mejores practicas
de su organización o las mejores practicas externas para mejorar su proceso de

14
entrega del software y su (software) producto.

14
Notas del participante:
Efectivamente, integración continua es parte de la entrega continua. Dentro de un
proceso de entrega de automatización continua, la integración continua abarca
mayormente la etapa de desarrollo.

Hay una sutil diferencia entre la Entrega Continua y despliegue continuo. Donde la
Entrega Continua tiene un explicito (manual) lanzamiento en la decisión de producción.
Con el Despliegue Continuo , los lanzamientos son automáticamente impulsados a
producción. No hay una decisión humana en el lanzamiento. Desde una perspectiva de
implementación, la Entrega Continua y Despliegue continuo no son realmente
diferentes, ya que la automatización es impulsada a la producción, esta no es difícil de
implementar cuando el software esta hasta ahora impulsado y automáticamente
validados en todos los entorno de prueba.

15
16
17
18
19
Notas del participante:
La entrega continua puede ser adoptada usando seis temas de enfoque. estos son:
• Organización Ágil: Una organización Ágil adopta principios Ágil y Lean combinado
con autonomía, grupos multidisciplinarios. Una organización DevOps con su cultura y
principios, como ya tratado en los módulos anteriores, representa tal ágil
organización y mas.
• Estructura Automatizada: Estructura automatizada esta definida como el proceso
de automatización para transformar cambios en los códigos (comprometida por los
miembros del grupo), automáticamente para la publicación de despliegue de
artefactos, listo para desplegar, y validación en (pruebas) ambientes en una manera
consistente.
• Prueba automatizada: pruebas automatizadas involucra la ejecución de la prueba
automatizada de las pruebas de especificaciones/ pruebas de scripts. Ejemplo de
pruebas son: código estático de calidad de análisis, pruebas unitarias, pruebas
funcionales, y pruebas de carga.
• Despliegue automatizado: Despliegue automatizado es definido como el proceso
para desplegar automáticamente el despliegue de artefactos publicados para la
aplicación de ambientes. Esto incluye pasos para mover despliegue de artefactos
para obtener maquinas (virtual) y pasos para configurar estos ( maquinas virtuales)y
otros servidores/componentes usados por el software.
• Provisión Automatizada: Provisión automatizada se asegura que los componentes,
como la red de componentes, servidores de componentes, y tiempo de ejecución del

20
 software se apile , de (pruebas) ambientes que puedan ser creados en demanda
usando un completo sistema de automatización (sistema de aprovisionamiento).
• Arquitectura: La Arquitectura (s), definida en todos los niveles (por ejemplo,
empresa, negocios, aplicación, y técnica) o bien se amplia o perjudica la habilidad de
optimizar el proceso de entrega del software de los grupos. Por ejemplo fuerte
acoplamiento entre grupos resultando en baja autonomía de grupos debido al cruce
de dependencia. Otro ejemplo la arquitectura del software determina la complejidad
de adoptar cambios de código del software.

• Una entrega continuada de modelo de madurez define características especificas en

diferentes niveles de madurez para estos (son similares) temas de enfoque. En
general cada nivel de madurez implica cierta capacidad de entrega continua.
Diferente entrega continuas de modelo de madurez están publicados en el internet.
Estos modelos de madurez ayudan a identificar mejoras concretas en la entrega
continua.

Notas del Instructor:

Explicar a los participantes como la entrega continua puede ser integrada usando un
listado con seis temas de enfoque.

20
Notas del Instructor:
Explicar el proceso de optimización del desarrollo del Software a los participantes como
se muestra en la diapositiva.

Notas del participante:

Entrega Continua quiere decir que el Software tiene fluidez, asegurando una fluidez
continuada de ideas de Software característica en el lanzamiento de productos. En el
desarrollo del proceso tradicional en el que no a continua, hay solamente una limitada
cantidad de fluidez. Hay muchas barreras de fluidez, como manuales de entrega,
inventarios y otros tipos de desperdicio. En el modulo 5, los diferentes tipos de
desperdicios fueron abarcados.

Las características del Software no optimizado en el proceso de entrega:

• El proceso esta basado en una organización con los equipos aislados, donde las
personas trabajan en tareas especializadas (funcionalidad) con muchas entregas
entre las diferente especialidades. Por ejemplo, un arquitecto escribe una solución
de arquitectura en un documento, una vez terminado, se entrega la información de
análisis para especificar la funcionalidad del diseño.
• Apoyar actividades para estructurar, validar (aprobar, evaluar) y desplegar el
Software son actividades manuales basados en (creadas recientemente o
actualizadas) instrucciones/especificaciones, cada vez una actividad de apoyo tiene

21
 que ser llevado a efecto.
• Finalmente, la prueba de tiempo de ejecución y ambientes de producción son
implementadas y manualmente mantenidas.

Para incrementar la fluidez en el proceso, las barreras y perdidas de la fluidez tienen que
ser eliminadas. Por ejemplo:
• No se puede tener una alta cantidad de fluidez sin una rigurosa automatización del
proceso de entrega del Software (Entrega Continua Principio de Base 1),
• Si la (esperado) frecuencia del manual (rutina) de ejecución de tarea es raro en un
momento dado en el proceso de entrega del Software, la ejecución manual de estas
tareas pueden ser justificadas. Un plan de proyecto de un proyecto de tres meses,
puede incluir una cantidad limitada de iteraciones para el despliegue de tarea. Por
ejemplo una iteración para el despliegue de producción de ambientes y menos de
cinco iteraciones para la prueba de despliegue de ambientes. Imagínese que desea
lanzar a producción semanalmente o más. La repetición de la ejecución de
despliegue de tareas serán significativamente más altas. La ambicion de lanzar más
seguido te presiona a tener otra perspectiva en el proceso de entrega del Software.

21
Notas del Instructor:
Explicar el proceso de optimización del desarrollo del Software a los participantes como
se nuestra en la diapositiva

Notas del participante:

La organización DevOps basada en el desempeño del equipo DevOps enlazado con
automatizaciones rigurosas del proceso de entrega del Software resulta en un flujo
optimizado. Con un optimizado flujo, empuje de cambios de Software (códigos) se
pueden lanzar en minutos. El equipo DevOps asegura alta calidad de Software, cambios
se lanzan a través de Softwares completamente automatizado y canalizados.
Han optimizado su proceso de entrega, la automatización garantiza rápidas reacciones
disponible con una tasa de eficiencia de eliminación de defecto alto (falla rápida), sus
características son:
• Alto desempeño equipo Agil DevOps.
• La cantidad de fluidez es optimizado
• Actividades de soporte (desarrollo, prueba, y despliegue) son automatizados.
• Ambientes de tiempo de ejecución son automáticamente provistos y administrados.

22
Notas del participante:
Un optimizado proceso de entrega del Software es vital para el desempeño grupal de
DevOps. Estos procesos integran un circulo de rápido feedbacks y reiterar las
características de la entrega del Software.

Automatización de Entrega Continua optimiza el proceso de entrega del Software de tal

manera que permite lanzamientos frecuentes de pequeñas porciones de funcionalidad
o las características del Software. Lanzamiento frecuentes asegura ofrecer feedbacks
regulares, ambos, la entrega de proceso (calidad entregada) y el cliente (valor del
producto). Los feedbacks regulares permite al equipo adaptarse rápidamente,
incorporando los feedbacks en sus Software, así ellos se convierten en un rápido
equipo de aprendizaje usando fallas rápidas, desarrollo continuo, y principios de
experimentación para optimizar sus aportes (desempeño)

23
Notas del Instructor:
Esta es una diapositiva animada. Presione la tecla Enter para avanzar la diapositiva.
Enseñara ejemplos de feedback (ver las notas de participante) graficado en la parte
superior de la fluidez del proceso de entrega del Software. La fluidez del proceso de
entrega del Software es definida por los rectángulos redondeados y flechas azules.

Notas del participante:

Diferente fuentes de feedback se pueden recolectar durante la entrega y utilización del
Software. Estos diferente fuente datos se pueden utilizar para optimizar el proceso de
entrega del Software. Por ejemplo, una fallida unidad de prueba ya indica un problema
de calidad en el Software en el que te hace reaccionar. Ignorar estos feedbacks (por
ejemplo, sin mencionarlos) pueden resultar un fracaso en las pruebas posteriormente
el lanzamiento del proceso o inclusive incidentes en la producción.

Los tipos de feedback son:

• Feedback en estructura y actividades de prueba: Por ejemplo, resultados de la
unidad de prueba automatizado, y resultados de los análisis de códigos sin
movimiento.
• Feedback en Despliegue: Por ejemplo resultados de ejecución de despliegue
automatizado, pruebas automatizadas de la aplicación de despliegue “humo”, y
aplicación automatizada de sostenibilidad.
• Feedback en el comportamiento de ejecución de tiempo: Por ejemplo, interrelación

24
 automatizado del usuario con la funcionabilidad de los resultados de prueba o
resultados de prueba de carga automatizada.
• Feedback del Cliente: Por ejemplo, ingreso/tasa de conversión.

El primer y segundo tipo de feedback ofrece principalmente feedback en la calidad

interna del Software, el tercero y el cuarto tipo de feedback ofrece feedback
principalmente en la calidad externa del Software.

24
Notas del Instructor:
Preguntar a los participantes de lo que han absorbido del método de la Entrega
Continua. Resume los debates con temas planteados por los participantes.

Notas del participante:

El método de Entrega Continua se enfoca en una visión donde los equipos se pueden
concentrar en un limitado entorno de cambios de Software lanzado frecuentemente a
través del proceso de entrega del Software que es optimizado con automatización
estricta. Esto no encaja con el planteamiento de entrega de la base de proyectos
tradicionales como el proceso de cascada o el proceso racional unificado (RUP),
además, estableciendo Entrega Continua requiere un diseño nuevo del proceso de
entrega del Software. No puede tener éxito con solo optimizaciones locales.

Diferencia entre tradicional y Entrega Continua:

• La habilidad de lanzar constantemente en producción requiere automatización de las
actividades de la entrega del Software. Tareas típicamente planeadas con limitada
cantidad de repeticiones en un proyecto tradicional son ahora realizadas (alta
frecuencia).
• El volumen de trabajo tiene que ser distribuido entre los miembros del equipo. Tarea
y base de recursos de gestión de proceso no funcionara.
• Gestión de recursos y tareas como proyectos no son posibles. El equipo tiene que ser
responsable, auto-gestionado, y mayormente autónomo.

25
Notas del instructor:
DevOps versus la Entrega Continua
Anima a los participantes a leer los siguientes libros:
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
Automation (Addison Wesley Signature Series) por Jez Humble y David Farley.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
(Hardcover – Importación, 10 de enero del 2013 por Gene Kim, Kevin Behr, y George
Spafford.

Notas del participante:

DevOps versus la Entrega Continua
En los temas anteriores, hemos abarcados los conceptos de Entrega Continua,
automatización de la Entrega Continua y otros aspectos de los temas de enfoque de la
no automatización. Los temas a los que se refiere son Ágil y Arquitectura.
Estos dos temas centrados en la Entrega Continua van más allá de la automatización y
la optimización científica de los procesos de entrega de Software. Los temas centrados
en la no automatización de la Entrega Continua abarcan:
• El tema con enfoque en Ágil abarca la cultura, colaboración, compartiendo
conocimientos y una mentalidad de entrega y respaldo de productos.

26
• La Arquitectura abarca no solamente en las aplicaciones e infraestructuras del paisaje
de TI, sino también abarca aspectos de organización.
Los principios base de la Entrega Continua combinados con los conceptos de temas
centrados estrechamente combina con los principales de DevOPS. Por ejemplo, los
principios clave de DevOps son:
• El Software solo es valioso cuando se encuentra en la etapa de producción
• Unificar la responsabilidad del producto
• De inicio a fina (ciclo de vida completo). La ideología es “Tú lo construiste,, tú lo
ejecutas”
• La completa automatización une la continuidad e innovación
• Lean y la Mejora Continua implica nuevas retrospectivas para evaluar
• Cultura de colaboración y compartir entre equipos.
La Entrega Continua y DevOps acepta los principios, conceptos e implementaciones
incluso cuando no existe un mismo origen y cada de una de ellos se enfoque en ciertos
temas o aspectos. Por esta razón, DevOps y la Entrega Continua deben considerarse
juntos como un complemento de cada uno. La Entrega Continua no se debe observar
como parte de DevOps o de alguna otra manera.

26
Notas del instructor:

Estructura de la automatización: permite el flujo automatizado de entrega de paquetes

de software
Esta es una diapositiva animada. Pulse la tecla Enter para avanzar la diapositiva.

Notas del participante:

Estructura de la automatización: permite el flujo automatizado de entrega de paquetes

de software

La estructura de la automatización transforma los cambios de código, comprometidos

por los miembros del equipo y los publica automáticamente a los artefactos de
despliegue que están listos para la implementación y la validación en los entornos (de
prueba).

Una vez que un miembro del equipo realiza una serie de cambios de código, estos
pueden fusionarse, analizarse, compilarse, probar unidades y agruparse
automáticamente. El proceso automatizado de estructuración puede crear un nuevo

27
paquete de implementación y publicarlo en un archivo de artefactos. De esta manera,
se puede implementar un flujo continuo desde el código comprometido hasta el
paquete de despliegue validado.

El proceso automatizado de estructuración es importante para una estrategia de fail-

fast. Es el componente que proporciona el primer feedback sobre la calidad de los
cambios de código comprometidos. Un sistema de estructuración central puede
adoptar una estrategia de fail-fast. Por ejemplo, si hay conflictos de combinación de
código, la estructura podría fallar, por lo que los miembros del equipo pueden
solucionar el conflicto de combinación de código. Un sistema automatizado de
estructuración típicamente incluye:

• Sistema de control de versión de origen: Por ejemplo, Git, Gitlab, GitHub, Atlassian
Stash, Subversion
• Servidor de integración continua: Por ejemplo, Atlassian Bamboo, Jenkins
• Análisis y Reporte de Calidad de Código: Por ejemplo, Sonarcube
• Archivo de artefactos: Por ejemplo, Nexus o Artefactory
• Herramientas de estructuración: Por ejemplo, Maven, Gradle, Grunt, NPM, Bower,
Ant, Gulp
• Análisis estático: Por ejemplo, FindBugs, CheckStyle, PMD, PHPMD.
• Prueba de unidad de marco: Por ejemplo, Junit y Karma

27
Antipattern: Deploying Software Manually
La mayoría de las aplicaciones modernas de cualquier tamaño son complejas de
implementar, Muchas organizaciones lanzan el software manualmente. Con esto
queremos decir que los pasos requeridos para implementar tal aplicación son tratados
como separados y atómicos, cada uno realizado por un individuo o equipo. Los juicios
deben hacerse dentro de estos pasos, dejándolos propensos al error humano. Incluso si
esto no es el caso, las diferencias en el orden y la oportunidad de estos pasos pueden
conducir a resultados diferentes. Estas diferencias rara vez son buenas.

Antipattern: Deploying to a Production-like Environment Only after Development Is

Complete
En este patrón, la primera vez que el software se despliega en un entorno similar a la
producción (por ejemplo, staging) es una vez que la mayor parte del trabajo de
desarrollo se realiza-al menos, "realizado" según lo define el equipo de desarrollo.

Antipattern: Manual Configuration Management of Production Environments

Muchas organizaciones gestionan la configuración de sus entornos de producción a
través de un equipo de personas de operaciones. Si se necesita un cambio, como un

28
cambio a Configuración de conexión de base de datos o un aumento en el número de
subprocesos en un grupo de subprocesos en un servidor de aplicaciones, se realiza
manualmente en los servidores de producción. Si se mantiene un registro de tal cambio,
es probablemente una entrada en una base de datos de gestión de cambios.

28
29