¿Es una buena idea instalar Mercurial en su servidor y hg pull to deploy?

Esta es ciertamente una buena idea y es un método común para usar en la implementación. Es posible que desee utilizar una rama estable para fines de implementación mientras mantiene el tronco para el desarrollo continuo, de modo 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 las claves de API, etc.) que no desea cargar en servidores de terceros (en su caso sería Bitbucket). En este caso, un simple script que se ejecuta una vez que haya extraído los datos del repositorio para restaurar los datos confidenciales en el lugar correcto resolverá ese problema.

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 pueden estar en el estado anterior mientras se está golpeando la aplicación. Esto puede causar efectos secundarios inesperados.

Una forma de realizar implementaciones atómicas es, por ejemplo, utilizando enlaces simbólicos. Crea 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 antigua a su alrededor, también puede revertirla fácilmente.

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 es necesario que esté en Internet) que configuró para monitorear sus repositorios, y cada vez que hay nuevos conjuntos de cambios en los repos, el servidor construye su código (AFAIK 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:

• Artículo de Wikipedia sobre CI
• pregunta de desbordamiento de pila: ¿Cuál es el punto de un "Servidor de compilación "?

Hay muchos productos diferentes para CI por ahí , 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 lo seguí.

Solución barata alternativa:

Si configurar un servidor de compilación es un esfuerzo excesivo o si desea tener más control sobre cuando se implementa exactamente su sitio, simplemente configure un archivo de script (Batch / Powershell on Windows, o algo similar en Linux / Mac) que extrae la versión más reciente de su repositorio y la envía por FTP al servidor de producción.

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

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

Desea poder desplegar 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 estrés.

Hacemos esto, o cosas similares a esto. El no atómico @johannes menciona el ángulo 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, lo más importante que esta no-atomicidad sería "cómo administrar las actualizaciones del esquema de la base de datos": implementar el código incorrecto de esta manera hace que la solución sea más fácil. El gran problema es cuando implementa una actualización que cambia la base de datos que desea revertir. O si estás haciendo malas actualizaciones y corrompiendo datos.

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

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

• Trate de no comprometerse en el servidor (aunque en raras ocasiones tiene sentido hacerlo, por ejemplo, instalando un complemento o agregando activos de contenido)
• Utilice un servidor de ensayo o un despliegue de repositorio secundario para realizar pruebas
• Tenga siempre cuidado de que hg update -C no 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 el contenido) e ignore los datos del usuario (por ejemplo, archivos adjuntos / subidas, caché, etc.)
• Siempre tenga una salida hg status limpia en el servidor (esto le ayudará a asegurarse de que está ignorando las 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 versiones de los archivos de configuración (especialmente con contraseñas de bases de datos u otras)
• No utilice en lugar de una copia de seguridad de producción, esta es una copia de seguridad de desarrollo para el código de producción , no los 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 forma de detectarlo fácilmente sin algo como Control de versión (especialmente distribuido, ya que el aspecto distribuido a VCS facilita la verificación de la integridad de sus archivos).

Me han pirateado algunos sitios algunas veces, y Mercurial me ayuda literalmente a deshacer estos hacks simplemente emitiendo un hg update -C en el servidor (por supuesto, es posible que desee hacer un hg status y obtener los archivos afectados para su posterior análisis).