Es de suponer que el desarrollador ha probado el software y ha descubierto que funciona suficientemente bien, por lo que el desafío es asegurarse de que el software funcione igual de bien, es decir, igual, en las máquinas del usuario final.
Me referiré informalmente a esto como implementación correcta: dadas entradas idénticas, el software debería comportarse de la misma manera en una máquina del usuario final que en la máquina del desarrollador.
La implementación de software es el problema de administrar la distribución de software a las máquinas de los usuarios finales. Es decir, un desarrollador ha creado alguna pieza de software y, en última instancia, tiene que acabar en las máquinas de los usuarios finales. Después de la instalación inicial del software, es posible que deba actualizarse o desinstalarse.
Este debería ser un problema simple. Por ejemplo, si el software consta de un conjunto de archivos, la implementación debería ser una simple cuestión de copiarlos en las máquinas de destino. En la práctica, el despliegue resulta mucho más complicado. Esto tiene varias causas. Estos se dividen en dos categorías amplias: y
Problemas ambientales La primera categoría tiene que ver esencialmente con la corrección. El software puede hacer todo tipo de demandas sobre el entorno en el que se ejecuta: que ciertos otros componentes de software estén presentes en el sistema, que existan ciertos archivos de configuración, que se hayan realizado ciertas modificaciones en el registro de Windows, etc. Si alguna de esas características ambientales no se cumple, existe la posibilidad de que el software no funcione de la misma manera que en la máquina de desarrollo. Algunas cuestiones concretas son las siguientes:
Un componente de software casi nunca es autónomo; más bien, depende de otros componentes para hacer algún trabajo en su nombre. Estas son sus dependencias. Para una correcta implementación, es necesario que todas las dependencias estén identificadas. Sin embargo, esta identificación es bastante difícil, ya que a menudo es difícil probar si la especificación de dependencia está completa. Después de todo, si nos olvidamos de especificar una dependencia, no descubrimos ese hecho si la máquina en la que estamos probando ya tiene instalada la dependencia. Las dependencias no son solo un problema de tiempo de ejecución. Para construir un componente en primer lugar, necesitamos ciertas dependencias (como compiladores), y estas no necesitan ser las mismas que las dependencias de tiempo de ejecución, aunque puede haber cierta superposición. En general, la implementación de las dependencias en tiempo de compilación no es un problema del usuario final, pero puede ser en escenarios de implementación basados en el origen; es decir, cuando un componente se implementa en forma de origen. Esto es común en el mundo del código abierto. Las dependencias también deben ser compatibles con lo que espera el componente de referencia. En general, no todas las versiones de un componente funcionarán. Este es el caso incluso en presencia de interfaces de tipo verificado, ya que las interfaces nunca dan una especificación completa del comportamiento observable de un componente.
Además, los componentes a menudo exhiben variabilidad en el tiempo de construcción, lo que significa que se pueden construir con o sin ciertas características opcionales, o con otros parámetros seleccionados en el momento de la construcción. Peor aún, el componente podría depender de un compilador específico o de opciones de compilación específicas que se utilicen para sus dependencias (por ejemplo, para compatibilidad con la interfaz binaria de aplicaciones (ABI)).
Incluso si todas las dependencias requeridas están presentes, nuestro componente aún tiene que encontrarlas para establecer realmente una composición concreta de componentes. Esta es a menudo una parte bastante laboriosa del proceso de implementación. Los ejemplos incluyen configurar la ruta de búsqueda del enlazador dinámico en sistemas Unix o CLASSPATH en el entorno Java. Los componentes pueden depender de artefactos que no son de software, como archivos de configuración, cuentas de usuario, etc. Por ejemplo, un componente puede mantener un estado en una base de datos que debe inicializarse antes de su primer uso. Los componentes pueden requerir ciertas características de hardware, como un tipo de procesador específico o una tarjeta de video. Estos están un poco fuera del alcance de la implementación del software, ya que como máximo podemos verificar tales propiedades, no darnos cuenta de ellas si faltan. Finalmente, la implementación puede ser un problema distribuido. Un componente puede depender de otros componentes que se ejecutan en máquinas remotas o como procesos separados en la misma máquina. Por ejemplo, un servicio web típico de varios niveles consta de un servidor HTTP, un servidor que implementa la lógica empresarial y un servidor de base de datos, posiblemente todos ejecutándose en diferentes máquinas.
Así que tenemos dos problemas en la implementación: debemos identificar cuáles son los requisitos de nuestro componente en el entorno y, de alguna manera, debemos realizar esos requisitos en el entorno de destino. La realización puede consistir en instalar dependencias, crear o modificar archivos de configuración, iniciar procesos remotos, etc.
