Un entorno de preparación es bastante importante independientemente del tamaño de un proyecto.
Supongo que su principal preocupación es dedicar más tiempo a mantener un segundo entorno y cambiar y desplegar constantemente en dos lugares diferentes.
Esbozaré varias notas que lo ayudarán a priorizar el entorno de preparación.
- ¿Qué es el desarrollador independiente?
- Cómo obtener mi primer proyecto independiente de Data Science
- ¿Cuántas horas al día debe dedicar un desarrollador web o de aplicaciones móviles independiente a ganar al menos $ 2k por mes?
- ¿Qué es el trabajo independiente y cómo te conviertes en un profesional independiente a los 17 años?
- Si trabajo como experto independiente en la materia, ¿lo incluyo en mi CV?
Considere el proyecto como una nueva construcción
Si está desarrollando un nuevo proyecto para un cliente, de todos modos necesita un entorno de prueba / desarrollo. Esta es la única opción razonable para informar el progreso y permitir que su cliente valide el trabajo hasta la fecha.
Incluso cuando está mejorando una solución existente, la aplicación de actualizaciones en vivo puede causar regresiones o cambios que no se desean. Esta mentalidad lo convencerá de los beneficios de un entorno de preparación y le permitirá crear un sitio de prueba antes de que incluso intente comenzar a trabajar.
Proveedor de alojamiento gestionado
Hay docenas de proveedores de alojamiento administrado que ofrecen soporte de preparación con un clic. Considere cambiar a un buen proveedor que no solo mejore su rendimiento y seguridad de forma inmediata, sino que también le permita crear sitios de preparación fácilmente sin problemas.
La mayoría de los proveedores con los que estamos trabajando pueden fusionar los cambios de nuevo a producción y crear nuevos clones de producción en un subdominio en cuestión de minutos.
Un anfitrión de puesta en escena barato
Hemos comprado varias cuentas para proveedores populares como Bluehost, Dreamhost, InMotion utilizados para sitios de prueba. Cada vez que trabajamos en un proyecto paralelo nuestro (o una nueva construcción que estamos probando desde diferentes perspectivas), construimos una réplica en un sitio de prueba separado y la tomamos desde allí.
Esta es una manera fácil de resolver la falta de soporte por etapas de su host original. Puntos de bonificación para proveedores de alojamiento que admiten SSH que pueden acelerar la duplicación del sitio web para diferentes casos de uso.
Actualizaciones de etapas automatizadas
Incluso sin una configuración de puesta en escena con un solo clic, crear una réplica de un sitio web no tiene que ser una tarea tediosa.
Para proyectos más grandes, utilizamos capistrano para implementaciones automatizadas de la base de código y la base de datos. Dado que eso puede estar limitado para hosts compartidos más baratos, existen herramientas que ahorrarían algo de tiempo y gestionarían el trabajo pesado en su nombre.
Mire DeployBot: implemente su código en cualquier lugar como una alternativa viable que también sea compatible con FTP para mover archivos después de cada iteración. Otra buena opción es Beanstalk: un flujo de trabajo completo que admite SVN y Git y sirve como un entorno controlado por versión que podría enviarse a los diferentes servidores a los que tiene acceso.
Dependiendo del tipo de proyecto, es posible que pueda aprovechar una base de datos remota que comparte su sitio de preparación y producción. Esto no es ideal, ya que puede borrar algunos datos por error, pero funciona en ciertos escenarios, especialmente cuando crea vistas de base de datos que son de solo lectura. De manera similar, puede aprovechar el CDN existente y servir los medios desde allí en lugar de mover las carpetas de imágenes manualmente. O integre una solución que sirva datos a través de Amazon S3 para que su sitio de desarrollo local y su entorno de preparación puedan usar el mismo depósito.
Actualizaciones con visibilidad limitada.
Otro enfoque “hacky” es construir sus extensiones con condicionales específicos que pueden funcionar de forma independiente o se activan en un caso específico.
En términos de front-end, puede duplicar la página original y aplicar los cambios allí. Alojarlo en una página privada visible solo para administradores. En la aprobación, combine los cambios en la página de producción.
Lo mismo ocurre con las funciones de back-end que no serían visibles desde las pantallas correspondientes.
Una posible opción para lograrlo es clonar la pantalla o introducir condicionales a los que no se accedería de forma predeterminada. Una opción rápida y sucia es establecer un parámetro GET que muestre los nuevos cambios solo cuando se usa:
http://samplesite.com/testpage?s…
Su condicional activará la nueva característica solo cuando se establezca ese argumento GET.
O agregue una verificación de capacidad que aplique la nueva actualización solo para usuarios o administradores que hayan iniciado sesión.
En general, evitar la puesta en escena ciertamente no es preferible. Considere implementar un flujo de trabajo que maneje las implementaciones por etapas con menos tiempo de su parte y listo.