¿Es una buena idea instalar Mercurial en su servidor y hg pull para implementar?

13

Acabo de comenzar un nuevo trabajo el mes pasado y parece que NO tienen control de fuente para su código. Confían en las copias de seguridad que su proveedor de hosting toma para ellos.

Después de hablar un poco, convencí a mi jefe de que definitivamente deberíamos usar el control de fuente y después de dar un breve seminario sobre él, todo el equipo está a bordo; ellos amaban a Mercurial.

Así que ahora esta es la forma en que trabajamos:

º----------BitBucket
º---------/
º--------/

Yo y los otros tres desarrolladores hg pullde BitBucket, hacemos nuestros cambios, luego hg pusha BitBucket.

Ahora para la implementación, alguien necesitaría enviar por FTP los últimos archivos hacia el servidor de producción.

Estaba pensando en instalar Mercurial en nuestro servidor, y usar hg clone(posteriormente hg pull) para mantener las versiones actualizadas en producción.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

¿Es esta una buena idea? ¿Alguna dificultad potencial que no esté viendo? ¿Alguien aquí ha hecho algo similar? ¿Cómo se implementa una gran aplicación de marco PHP (estamos usando Moodle)?

php mercurial production

— sergserg
fuente

Es una idea genial. ¿Por qué tienes dudas?

— Nikolay Fominyh

Es un proceso que muchos consideran y de hecho consideran lo suficientemente "normal" que Microsoft ahora ha incorporado el soporte para hacer implementaciones basadas en Git (con soporte de hg posible en el futuro) en su servicio de Azure.

— Alan Barber

12

Esta es ciertamente una buena idea y es un método común para usar para la implementación. Es posible que desee utilizar una rama estable para fines de implementación mientras mantiene el tronco para el desarrollo continuo para que pueda probar la rama estable antes de implementarla en producción.

El único problema puede surgir cuando tiene información confidencial en su base de código (como claves de API, etc.) que no desea cargar en servidores de terceros (en su caso, sería Bitbucket). En este caso, una secuencia de comandos simple que se ejecuta una vez que ha extraído los datos del repositorio para restaurar los datos confidenciales en el lugar correcto resolverá ese problema.

— Cromulento
fuente

10

Tenga en cuenta que esta estrategia de implementación no es atómica. Puede suceder que algunos archivos ya estén actualizados, mientras que otros archivos aún podrían estar en el estado anterior mientras se aplicaba la aplicación. Esto puede causar efectos secundarios inesperados.

Una forma de hacer despliegues atómicos es, por ejemplo, usar enlaces simbólicos. Cree un directorio que contenga los nuevos archivos. cuando todo esté listo, cambie un enlace simbólico para el directorio utilizado. Si mantiene la versión anterior, también puede revertir fácilmente.

— johannes
fuente

3

Puede retroceder fácilmente de todos modos, ese es el punto de VCS.

— Rob

1

no necesariamente, entonces debe mantener la configuración o algunos archivos generados que pueden depender de la versión y del sistema en el VCS. Además, tendría que usar etiquetas (que no se mencionan en el proceso descrito en la pregunta) para alentar a volver a una versión de trabajo conocida.

— johannes

2

Otra posibilidad (en mi opinión mejor) : usar un servidor de compilación / servidor de integración continua.

Breve explicación breve: este es un servidor (puede ser interno, no necesita estar en Internet) que configuró para monitorear sus repositorios, y cada vez que hay nuevos conjuntos de cambios en los repositorios, el servidor construye su código ( AFAIK esto no es necesario en PHP) , ejecuta pruebas unitarias e implementa su código en el servidor web.

Para obtener más información, consulte estos enlaces:

Existen muchos productos diferentes para CI , pero el único que he usado hasta ahora es TeamCity . Muy fácil de configurar ... de hecho, es el primero que probé, y me gustó tanto que me quedé con él.

Solución barata alternativa:

Si configurar un servidor de compilación es demasiado esfuerzo o si desea tener más control sobre cuándo se implementa exactamente su sitio, simplemente configure un archivo de script (Batch / Powershell en Windows, o algo similar en Linux / Mac) que extraiga el versión más reciente de su repositorio y FTP en el servidor de producción.

Básicamente, es lo mismo que un servidor de compilación, pero más simple.

No importa cómo lo resuelva exactamente al final ... ¡asegúrese de automatizarlo de alguna manera!

Desea poder implementar con un solo clic / escribiendo un solo comando, para que TODOS puedan hacerlo sin tener que saber nada especial y sin cometer errores, incluso en caso de desastre o bajo estrés.

— Christian Specht
fuente

1

Hacemos esto o cosas similares a esto. El ángulo no atómico de @johannes menciona que es un problema, aunque en términos realistas sucede tan rápido que debería estar bien y hay formas de evitarlo, como él señala.

Probablemente, más importante que esta no atomicidad sería "cómo se gestionan las actualizaciones del esquema de la base de datos": la implementación de código incorrecto de esta manera facilita la reparación. El gran problema es cuando implementa una actualización que cambia la base de datos que desea revertir. O si está realizando malas actualizaciones y corrompiendo datos.

El otro problema que tuvimos con las herramientas DCVS (a diferencia del uso de SVN) es que ahora tiene una copia de toda la base de código en la máquina en algún lugar que un atacante podría obtener. Y también que esa base de código DCVS puede ser bastante pesada en cuanto al tamaño, lo que podría importar si está pagando por el almacenamiento y / o la copia de seguridad. Todavía estamos usando SVN para la implementación final por estos motivos.

— Wyatt Barnett
fuente

1

Es una gran idea, sin embargo, tenga en cuenta lo siguiente:

Intente no comprometerse en el servidor (aunque algunas veces tiene sentido hacer esto, por ejemplo, instalar un complemento o agregar activos de contenido)
Utilice un servidor intermedio o una implementación de repositorio secundario para realizar pruebas
Tenga siempre cuidado de que hg update -Cno afecte la producción (es decir, elimine archivos importantes)
Tener una rama de producción y desarrollo, solo implementar la rama de producción
Trate los activos como copia de seguridad (por ejemplo, imágenes para contenido) e ignore los datos del usuario (por ejemplo, archivos adjuntos / cargas, caché, etc.)
Siempre tenga una hg statussalida limpia en el servidor (esto lo ayudará a asegurarse de que está ignorando cosas como caché)
No implemente el repositorio en la carpeta web. Utilice enlaces simbólicos desde fuera del espacio público (por ejemplo, ln -s / myrepo / src / web / public_html / myapp)
Tenga cuidado de no versionar archivos de configuración (especialmente con contraseñas de bases de datos u otros)
No use en lugar de una copia de seguridad de producción, esta es una copia de seguridad de desarrollo para código de producción , no datos de producción

Finalmente, creo que lo más valioso para agregar un DVCS a su proceso de implementación es que esto agregará seguridad a su implementación, a veces los piratas informáticos inyectan código malicioso a sus cosas y realmente no tiene medios para detectarlo fácilmente sin algo como el control de versiones ( especialmente distribuido, ya que el aspecto distribuido a VCS hace que sea más fácil verificar la integridad de sus archivos).

Algunas veces me han hackeado algunos sitios, y Mercurial me ayuda a deshacer literalmente estos hacks simplemente emitiendo un hg update -Cen el servidor (por supuesto, es posible que desee hacer hg statusy obtener los archivos afectados para un análisis posterior).

— dukeofgaming
fuente