Deployability

Intención y alcance arquitectónico

Deployability describe qué tan fácil, segura y autónomamente una versión o cambio puede pasar a un entorno ejecutable. Incluye esfuerzo, tiempo, coordinación y riesgo, junto con capacidad de observar el resultado y responder si no es aceptable. El tratamiento de SEI, extraído de Software Architecture in Practice, cuarta edición, examina previsibilidad, granularidad, control y eficiencia del deployment.

deployment examina las unidades que se instalan o actualizan juntas o por separado. Este atributo evalúa qué tan fácil y seguro resulta hacerlo. Contratos, datos, procesos y dependencias determinan qué puede desplegarse, en qué orden y con qué alcance. Automatizar los pasos puede mejorar repetibilidad; no elimina una obligación estructural de cambiar varias capacidades juntas.

La evaluación necesita un escenario: artifact, entorno, respuesta y medida. «Desplegamos frecuentemente» es una observación incompleta si cada entrega necesita coordinación costosa o expone todo el sistema a un defecto. La frecuencia deseada depende del producto, sus restricciones y sus prioridades.

Deployment, release y otras qualities

Deployment coloca software en un entorno donde puede ejecutarse. Release expone o habilita una capacidad para usuarios. Un proveedor de pagos puede estar instalado y permanecer deshabilitado hasta que producto habilite su uso. Pete Hodgson explica ese desacoplamiento mediante Feature Toggles.

Flags, configuración o exposición progresiva pueden separar los eventos, con costo de estados adicionales y control de configuración. No todos los sistemas los distinguen operacionalmente: en algunos, instalar la versión también hace accesible el comportamiento. La distinción ayuda a investigar obligaciones, no exige inventar dos procedimientos.

Deployability no equivale a releaseability. La segunda preocupación puede involucrar decisiones de habilitación y entrega a usuarios; aquí analizamos llevar cambios a ejecución. Tampoco equivale a operability, que observa manejo del sistema en operación, ni a portability, que trata adaptación a otros entornos. Se relacionan sin convertirse en sinónimos.

Estímulos, entornos y medidas

Un estímulo puede ser una versión preparada, una corrección urgente o una actualización de configuración y datos. El artifact incluye unidades desplegables y dependencias relevantes. Preproducción y producción normal difieren de recuperación bajo incidente: permisos, tráfico, ventanas y recursos disponibles condicionan la respuesta.

La respuesta instala o sustituye versiones, mantiene condiciones acordadas de servicio y permite intervenir si falla. Las medidas pueden incluir tiempo y esfuerzo, equipos coordinados, interrupción, errores y alcance de la intervención. Hay que definir cuándo comienza y termina el deployment, y qué observación permite declararlo aceptable.

Estos ejemplos son propios del Atlas, con presupuestos que deben acordarse. No establecen frecuencia universal ni una tolerancia obligatoria de downtime para todos los sistemas.

Module y deployment unit

Un architectural module agrupa responsabilidades y protege decisiones. Una deployment unit es la unidad de software que se instala o actualiza como conjunto. Sus fronteras pueden coincidir, pero representan preguntas distintas.

Orders module ────┐
Billing module ───┼──→ One application deployment unit
Inventory module ─┘

Un modular-monolith puede localizar perfectamente un cambio en Orders y desplegar junto el artifact común. modifiability evalúa esa localidad; deployability evalúa entrega y consecuencias. Una capacidad mayor también puede distribuirse entre varios deployment units, por ejemplo un API y un worker con versiones propias.

Deployment compartido no implica mala deployability automáticamente. Para un equipo y una ventana adecuada, una entrega común, repetible y rápida puede satisfacer el escenario mejor que numerosas unidades que requieren compatibilidad distribuida. Modularidad del código y autonomía de delivery deben comprobarse separadamente.

Independencia efectiva

Independent deployment permite actualizar una unidad sin exigir una entrega coordinada de capacidades no relacionadas. Repositorios separados, procesos separados o el nombre «microservice» no prueban esa capacidad. Si contratos, datos o dependencias exigen la misma versión simultáneamente, existe lockstep aunque cada equipo tenga su pipeline.

La literatura de Continuous Delivery sobre arquitectura relaciona deployment independiente con encapsulación y APIs compatibles. Esa autonomía requiere ownership, automatización y comportamiento y datos gestionables con límites adecuados. microservices puede favorecerla, con costos de versiones coexistentes, más entregas y obligaciones operacionales.

En nuestro ejemplo, agregar un proveedor debería poder entregarse sin redesplegar Inventory por una dependencia accidental. Si Orders cambia un significado usado por Billing, esa coordinación puede ser legítima. «Independiente» no significa que nunca exista colaboración; significa distinguir obligaciones reales de acoplamientos evitables.

Compatibilidad y coordinación de versiones

Producer v2
    ↓ compatible contract
Consumer v1

Esa coexistencia puede permitir despliegues separados si el cambio mantiene las obligaciones que Consumer v1 necesita. En otro cambio, el consumidor nuevo debe aceptar primero ambas representaciones. La secuencia depende del contrato y del sentido de la modificación; agregar un campo no prueba compatibilidad semántica.

Un consumidor puede rechazar campos desconocidos, asumir valores exhaustivos o interpretar de manera diferente una unidad monetaria. La evidencia debe representar combinaciones permitidas y su comportamiento. testability aporta control y diagnóstico para investigar esas condiciones, no únicamente probar la versión más reciente de todo el sistema.

Sato describe expansión, migración y retiro como etapas para cambios incompatibles en parallel-change. Fuente primaria. Sostener temporalmente ambas formas puede reducir necesidad de actualización simultánea, pero agrega complejidad. Si nunca se retira la anterior, la transición deja obligaciones permanentes; desplegar código nuevo no prueba que el último consumidor haya migrado.

Aplicación, schemas y reversión

Desplegar una aplicación puede requerir modificar un schema y transformar datos. Una ventana de compatibilidad, cambios aditivos y una secuencia deliberada pueden permitir que versiones viejas y nuevas funcionen durante el rollout. Fowler y Sadalage muestran cambios compatibles y evolución coordinada de aplicación y datos en Evolutionary Database Design.

En nuestro caso, añadir una representación nueva antes de usarla puede conservar lectores antiguos mientras migran consumidores. El costo incluye almacenamiento o traducciones temporales, validación y retiro posterior. Estas decisiones dependen de significado, volumen y restricciones; no constituyen aquí un procedimiento universal de migración.

Rollback del binary no restaura necesariamente el estado anterior. Si hubo transformación irreversible, cobros externos o eventos con un schema que la versión vieja no entiende, volver al executable puede ser inseguro. idempotency y delivery-guarantees mantienen el tratamiento de efectos y mensajes; el deployment necesita reconocer esas obligaciones.

Fowler advierte que Blue Green Deployment necesita atender compatibilidad de schemas. Para nuestro escenario, «rollback disponible» debe incluir verificar datos, tráfico y efectos, no solo conservar una imagen anterior. Si revertir no es seguro, una corrección hacia adelante puede ser una respuesta deliberada; necesita tiempo, autoridad y evidencia acordados, sin prometer recuperación automática.

Mecanismos, fuerzas y trade-offs

architectural-tactics permite vincular movimiento y resultado esperado. Automatizar busca repetibilidad y menor esfuerzo; su evidencia incluye una ejecución completa en condiciones representativas. Una pipeline puede automatizar downtime, cambios de database coordinados, secuencias manuales y un gran alcance de fallo. Tener CI/CD no demuestra alta deployability.

SEI presenta mecanismos de sustitución y rollout gradual, incluyendo blue/green, rolling y canary. Permiten investigar exposición y control del cambio, con recursos y observación adicionales. Feature flags controlan exposición funcional; ninguno de estos mecanismos constituye la quality por sí mismo.

Limitar alcance puede reducir blast-radius si las dependencias conservan aislamiento efectivo. Fragmentar demasiado puede aumentar versiones, coordinación y costo operacional. Un deployment unit grande puede ampliar impacto de una versión defectuosa; uno pequeño puede seguir afectando capacidades dependientes. quality-attribute-trade-offs compara el paquete completo.

Escenario: nueva versión de Orders

Campo	Escenario propio
Source	Equipo de delivery y automatización de deployment.
Stimulus	Una nueva versión de la capacidad Orders está lista para producción.
Artifact	Deployment unit de Orders y sus dependencias relevantes.
Environment	Operación normal en producción, contratos y datos compatibles durante la transición.
Response	Se despliega la versión mientras continúa el tráfico compatible y permanece disponible una reversión segura bajo los supuestos acordados.
Response Measure	Termina dentro del tiempo convenido, sin despliegue coordinado de capacidades no relacionadas y sin superar el presupuesto acordado de interrupción y errores.

Para evaluar el escenario se necesitan combinaciones de versiones admitidas, condiciones de tráfico, secuencia de datos y criterios para detener o revertir. Debe registrarse coordinación real y verificarse el resultado después de mover el artifact. Si cambia un supuesto de reversibilidad, la respuesta prevista necesita revisarse.

Al incorporar un proveedor de pagos, la pregunta equivalente es si ese cambio puede llegar a ejecución sin coordinar capacidades ajenas y con efectos controlables. evolvability examina opciones futuras; modifiability el trabajo del cambio; testability la evidencia que respalda su comportamiento. Su interacción orienta decisiones situadas, sin declarar ganador universal entre profiles.