¿Opciones o recomendaciones de configuración local/staging self-hosted?

Instalación
1

Después de investigar un poco, la cooperativa tecnológica con la que trabajo me ha presentado las siguientes opciones para configuraciones locales/de staging autoalojadas. Quizás tengamos que hacer un esfuerzo y duplicar nuestros costos de alojamiento* (cuando sea necesario), pero pensamos que sería bueno ver si alguien tiene consejos sobre las mejores prácticas o recomendaciones para alternativas.

*Somos una pequeña organización sin fines de lucro y tenemos alojamiento gestionado en el Reino Unido, por lo que el costo no es trivial.

— — —

OPCIONES:

1. Configuración local

pros:

  • Súper seguro y aislado: se pueden modificar plugins, temas o código principal de Discourse.

cons:

  • El rendimiento es bastante terrible: por defecto, realiza un docker image pull cada vez que reinicias el PC, tienes que volver a ejecutar bundle install (descargar y compilar muchos paquetes de Ruby) cada vez que lo inicias, y en OSX todo se ejecuta en una VM lenta debido a la falta de soporte nativo de contenedores.
  • Requiere un parche manual al código de Discourse para que funcione el plugin WP-Discourse (se necesita más investigación para averiguar cómo aplicarlo).
  • La sincronización con el sitio en vivo requerirá trabajo en las herramientas, la carga de datos en vivo puede o no funcionar de manera confiable.

estimación: 4-6 horas de configuración

2. Servidor de staging

pros:

  • Facilita la incorporación de personas nuevas, sin configuración.
  • Puede ser relativamente fácil hacerlo coincidir con la versión, plugins, etc. del sitio principal.
  • La sincronización “podría” ser tan fácil como restaurar una copia de seguridad del sitio en vivo.

cons:

  • Altos costos continuos.

estimación: 1-2 horas de configuración + costos de alojamiento.

3. (Encontrar una forma de) probar de forma segura en el sitio en vivo

pros:

  • Definitivamente siempre se prueba con la misma versión de Discourse, plugins y temas.

cons:

  • Necesitamos encontrar una forma de no enviar spam a los usuarios con alertas de ‘¡nueva publicación!’ / riesgo de que si lo hacemos mal, la gente reciba spam. Pequeño riesgo para los datos, podría requerir restaurar desde una copia de seguridad.

estimación: 1-2 horas de configuración

2

Recomendaría tener el entorno de staging en la nube como una instancia dedicada. Probar en el sitio en vivo no es ideal y sería muy comparable a producción. Alojarlo localmente es factible, pero implica muchos dolores de cabeza innecesarios por poca o ninguna recompensa, excepto quizás ahorrar unos cuantos dólares que quemarías en costos de electricidad.

1 me gusta