Traspasar software existente a un nuevo equipo
Compruebe el traspaso desde una versión identificada del código fuente hasta un cambio pequeño y reversible en el entorno de pruebas.
Deje que el nuevo equipo siga el recorrido
La entrega se concreta cuando el nuevo equipo puede preparar la aplicación con sus propias cuentas autorizadas y comprobar un cambio acordado. Un archivo de código y una demostración del equipo anterior aún no aportan todas las pruebas.
Relacione primero la versión en uso con una revisión fuente identificada. Registre archivos necesarios, dependencias, versiones de herramientas y pasos hasta un resultado ejecutable. SLSA distingue fuentes, otras entradas, construcción y artefactos distribuidos. Así el nuevo equipo puede seguir qué entradas produjeron la versión entregada.
Ejemplo: del montaje a la reversión de un texto
El escenario es ficticio. Se entrega un formulario de servicio en v2.3.0. El nuevo equipo debe precisar la ayuda «Nota de entrega» como «Acceso y entrega». Campos de datos y esquema de base no cambian en este ejemplo. La tabla describe pruebas esperadas, no un test ejecutado.
Paso | Tarea acordada | Evidencia esperada |
|---|---|---|
Acceder a fuentes | Recuperar revisión documentada y archivos adicionales con cuenta propia autorizada. | La revisión entregada está identificada; también se accede a paquetes privados y contenidos adicionales necesarios del repositorio. |
Preparar el entorno | Seguir instrucciones de entorno de ejecución, instalación de paquetes y configuración de pruebas. | La aplicación de prueba arranca sin accesos de producción ni archivos privados del desarrollador anterior. |
Comprobar un cambio pequeño | Cambiar la ayuda y recorrer el guardado existente con datos sintéticos. | Aparece el texto nuevo; el guardado acordado sigue funcionando. |
Revertir el cambio | Deshacer el cambio de texto en pruebas y seguir el arranque documentado. | Vuelven el texto original y el flujo del formulario antes comprobado. |
La última fila solo demuestra la vuelta de ese cambio. Restaurar una base o pasar a producción necesita sus propias comprobaciones adecuadas.
Añada operación y asuntos abiertos
Documente nombres de configuración, vías seguras para obtener secretos, fuentes de paquetes privados y configuración de construcción, incluido un archivo de bloqueo adecuado. Los secretos reales no pertenecen al archivo fuente. Compruebe también archivos grandes separados y repositorios incorporados si se usan.
Aclare accesos y responsables de despliegue, supervisión, copias y fallos. La transferencia de un repositorio GitHub mantiene asociaciones como webhooks, secretos y claves de despliegue. Revise expresamente qué conexiones y accesos deben continuar. Transferir no los limpia por sí solo.
Si falla un paso, registre requisito ausente, rol responsable y próxima evidencia. Separe pendientes de resultados demostrados. Acuerde cuándo el nuevo equipo asume cada tarea y quién queda disponible hasta entonces.
Fuentes
Escrito por
- Katharina WeberRedactora de software y tecnologíaKatharina Weber se encarga en ASES de los artículos sobre desarrollo de software. Escribe sobre las cuestiones que se plantean las empresas al elegir software, desarrollar nuevas aplicaciones y modernizar sus sistemas existentes.
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles