Implementación de software

El despliegue de software comprende todas las actividades que hacen que un sistema de software esté disponible para su uso. ^{[ 1 ] [ 2 ]}

El despliegue puede implicar actividades del lado del productor ( desarrollador de software ), del lado del consumidor ( usuario ) o de ambos. El despliegue para los consumidores es una tarea difícil debido a que los sistemas de destino son diversos e impredecibles. ^{[ 3 ] [ 4 ]} El software como servicio evita estas dificultades al desplegarse únicamente en servidores dedicados que, por lo general, están bajo el control del productor.

Dado que cada sistema de software es único, resulta difícil definir los procesos o procedimientos precisos dentro de cada actividad. Por lo tanto, el término "despliegue" debe interpretarse como un proceso general que debe personalizarse según los requisitos o características específicas. ^{[ 5 ]}

Cuando las computadoras eran extremadamente grandes, caras y voluminosas ( mainframes y minicomputadoras ), el software a menudo venía incluido con el hardware por los fabricantes y se proporcionaba de forma gratuita. ^{[ 6 ]} Un momento crucial ocurrió en 1969 cuando IBM, influenciada por demandas antimonopolio, comenzó a cobrar por el software y los servicios por separado del hardware. Esta "desagregación" creó efectivamente la industria moderna del software, convirtiendo el software en un producto comercial. ^{[ 7 ]} Los primeros procesos de implementación estaban altamente estructurados; el Modelo por Fases de Lincoln Labs, desarrollado en 1956 para el sistema de defensa aérea SAGE, introdujo fases secuenciales que influyeron en metodologías posteriores. ^{[ 8 ]} Este enfoque se formalizó en el modelo de cascada , que se volvió dominante después de ser descrito por Winston Royce en 1970. Condujo a ciclos de lanzamiento poco frecuentes, costosos y largos, que a menudo tomaban años. ^{[ 9 ]} Si se necesitaba instalar software empresarial , a menudo requería una visita costosa y que consumía mucho tiempo de un arquitecto de sistemas o un consultor . ^{[ 10 ]} En el caso de instalaciones complejas de software empresarial en las instalaciones del cliente, esto a veces sigue siendo así. ^{[ 11 ]}

El desarrollo de software de consumo masivo para la nueva era de las microcomputadoras en la década de 1980 trajo consigo nuevas formas de distribución de software : primero cartuchos , luego casetes compactos , luego disquetes y, más tarde (en la década de 1990 y posteriores), medios ópticos , internet y unidades flash . ^{[ 12 ] [ 13 ]} Este cambio significó que la implementación del software podía dejarse en manos del cliente. ^{[ 14 ]} Durante este período, surgieron alternativas al rígido modelo de cascada. El Modelo Espiral , propuesto por Barry Boehm en 1988, introdujo un enfoque iterativo basado en el riesgo que desafió la estructura lineal de la cascada y allanó el camino para metodologías más flexibles y ágiles. ^{[ 15 ]} A medida que la implementación dirigida por el cliente se convirtió en el estándar, se reconoció que la configuración debía ser fácil de usar. En la década de 1990, herramientas como InstallShield se popularizaron, proporcionando asistentes de instalación que eliminaban la necesidad de que los usuarios realizaran tareas complejas como editar entradas del registro. ^{[ 16 ]} 

En las implementaciones de software anteriores a Internet, los lanzamientos eran, por naturaleza, costosos y poco frecuentes. ^{[ 17 ]} La expansión de Internet transformó fundamentalmente la distribución de software e hizo viable el desarrollo ágil de software de extremo a extremo al permitir la colaboración rápida y la entrega digital. ^{[ 18 ]} Las bases para la implementación rápida moderna se establecieron en la década de 1990 cuando Kent Beck desarrolló la Integración Continua como una práctica central de la Programación Extrema , abogando por que los desarrolladores integraran su trabajo diariamente. ^{[ 19 ]} La llegada de la computación en la nube y el software como servicio (SaaS) en la década de 2000 aceleró aún más esta tendencia, permitiendo que el software se implementara para una gran cantidad de clientes en minutos. Este cambio también significó que los cronogramas de implementación ahora generalmente los determinaba el proveedor de software, no los clientes. ^{[ 20 ] [ 21 ]} Tal flexibilidad condujo al auge de la entrega continua como una opción viable, especialmente para aplicaciones web . ^{[ 22 ]}

Las estrategias de despliegue modernas que se basan en estos principios incluyen el despliegue azul-verde y el despliegue de lanzamiento canario . ^{[ 23 ]}

Liberar

La actividad de lanzamiento se deriva del proceso de desarrollo completado y, en ocasiones, se clasifica como parte del proceso de desarrollo en lugar del proceso de despliegue. ^{[ 24 ]} Incluye todas las operaciones necesarias para preparar un sistema para su ensamblaje y transferencia al o los sistemas informáticos en los que se ejecutará en producción. Por lo tanto, a veces implica determinar los recursos necesarios para que el sistema funcione con un rendimiento aceptable y planificar o documentar las actividades posteriores del proceso de despliegue.

Instalación y activación

En sistemas sencillos, la instalación implica establecer algún tipo de comando , acceso directo, script o servicio para ejecutar el software (manual o automáticamente). En sistemas complejos, puede implicar la configuración del sistema —posiblemente mediante preguntas al usuario final sobre su uso previsto o preguntándole directamente cómo desea que se configure— y /o la preparación de todos los subsistemas necesarios. La activación es la actividad de iniciar el componente ejecutable del software por primera vez (no debe confundirse con el uso común del término activación en relación con una licencia de software, que es una función de los sistemas de gestión de derechos digitales ).  

En implementaciones de software de mayor tamaño en servidores , la copia principal del software que utilizarán los usuarios —la versión de producción— podría instalarse en un servidor de producción dentro del entorno de producción. Otras versiones del software implementado podrían instalarse en un entorno de prueba , un entorno de desarrollo y un entorno de recuperación ante desastres.

En entornos complejos de entrega continua o sistemas de software como servicio , pueden coexistir versiones del sistema con diferentes configuraciones en el entorno de producción para distintos clientes internos o externos (esto se conoce como arquitectura multiusuario ), o incluso implementarse gradualmente en paralelo para diferentes grupos de clientes, con la posibilidad de cancelar una o más de las implementaciones paralelas. Por ejemplo, se sabe que Twitter utiliza este último enfoque para realizar pruebas A/B de nuevas funciones y cambios en la interfaz de usuario . También se puede crear un grupo "en vivo oculto" dentro de un entorno de producción, compuesto por servidores que aún no están conectados al balanceador de carga de producción , con el fin de implementar el modelo azul-verde .

Desactivación

La desactivación es lo opuesto a la activación y se refiere al apagado de cualquier componente de un sistema que ya esté en ejecución. La desactivación suele ser necesaria para realizar otras actividades de implementación; por ejemplo, un sistema de software puede necesitar ser desactivado antes de realizar una actualización. La práctica de retirar del servicio sistemas poco utilizados u obsoletos se conoce comúnmente como retiro o desmantelamiento de aplicaciones.

Desinstalación

La desinstalación es el proceso inverso a la instalación. Consiste en la eliminación de un sistema que ya no es necesario. También puede implicar la reconfiguración de otros sistemas de software para eliminar las dependencias del sistema desinstalado .

Actualizar

El proceso de actualización reemplaza una versión anterior de un sistema de software, total o parcialmente, por una versión más reciente. Generalmente consiste en la desactivación seguida de la instalación. En algunos sistemas, como Linux al usar el gestor de paquetes del sistema , la versión anterior de una aplicación de software también se desinstala automáticamente como parte del proceso. (Esto se debe a que los gestores de paquetes de Linux no suelen admitir la instalación simultánea de varias versiones de una aplicación de software, a menos que el paquete de software haya sido diseñado específicamente para sortear esta limitación).

Actualización integrada

Algunos sistemas de software incorporan mecanismos para instalar actualizaciones (o, en el caso de algunos sistemas operativos como Linux , Android e iOS , están integrados en el propio sistema operativo). La automatización de estos procesos de actualización varía desde la automatización completa hasta la iniciada y controlada por el usuario. Norton Internet Security es un ejemplo de un sistema con un método semiautomático para obtener e instalar actualizaciones tanto de las definiciones del antivirus como de otros componentes del sistema. Otros productos de software ofrecen mecanismos de consulta para determinar cuándo hay actualizaciones disponibles.

Seguimiento de versiones

Los sistemas de seguimiento de versiones ayudan al usuario a encontrar e instalar actualizaciones de software. Por ejemplo: el Catálogo de Software almacena la versión y otra información de cada paquete de software instalado en un sistema local. Con un solo clic, se abre una ventana del navegador con la página web de actualización de la aplicación, incluyendo el autocompletado del nombre de usuario y la contraseña para los sitios que requieren inicio de sesión. En Linux, Android e iOS, este proceso es aún más sencillo, ya que el sistema operativo incorpora un proceso estandarizado de seguimiento de versiones (para paquetes de software instalados de la forma oficialmente compatible), eliminando la necesidad de iniciar sesión, descargar y ejecutar el software. De esta forma, el proceso puede configurarse para automatizarse por completo. Algunos programas de terceros también permiten el seguimiento y la actualización automáticos de versiones para ciertos paquetes de software de Windows. 

La complejidad y variabilidad de los productos de software han propiciado la aparición de roles especializados para coordinar y diseñar el proceso de despliegue. En el caso de los sistemas de escritorio, los usuarios finales suelen convertirse también en los "desplegadores de software" cuando instalan un paquete de software en su máquina. El despliegue de software empresarial implica muchos más roles, y estos roles suelen cambiar a medida que la aplicación avanza desde los entornos de prueba (preproducción) a los de producción. Los roles típicos involucrados en los despliegues de software para aplicaciones empresariales pueden incluir: ^{[ 25 ]}

• en entornos de preproducción:
  • Desarrolladores de aplicaciones: consulte el proceso de desarrollo de software.
  • Ingenieros de compilación y lanzamiento: consulte Ingeniería de lanzamiento
  • gestores de versiones: véase Gestión de versiones
  • Coordinadores de despliegue: véase DevOps
• en entornos de producción:
  • administrador del sistema
  • administrador de bases de datos
  • Coordinadores de lanzamiento: véase DevOps
  • gestores de proyectos de operaciones: véase ITIL ^{[ 26 ]}

• Gestión del ciclo de vida de las aplicaciones
• gestión del ciclo de vida del producto
• Gestión de sistemas
• Implementación del sistema
• Lanzamiento de software
• Biblioteca multimedia definitiva
• Léame
• Gestión de lanzamientos
• Entorno de despliegue

• Esfuerzos de estandarización
  • Solicitud de envío del esquema de instalación de la solución al W3C
  • TC del descriptor de implementación de la solución OASIS
  • Especificación OMG para el despliegue y la configuración de aplicaciones distribuidas basadas en componentes (OMG D&C)
  • JSR 88: Implementación de aplicaciones Java EE
• Artículos
  • Carzaniga, Antonio; Fuggetta, Alfonso; Hall, Richard S.; Van Der Hoek, André; Heimbigner, Dennis; Wolf, Alexander L. (abril de 1998). "Un marco de caracterización para tecnologías de despliegue de software: informe técnico CU-CS-857-98" (PDF) . Boulder, CO : Departamento de Ciencias de la Computación, Universidad de Colorado Boulder .
• Recursos
  • Gestión de versiones de Visual Studio