¿Debo hacer de mi repositorio mi DocumentRoot para mi sitio web?

Question

Configuro mercurial en mi servidor, pero no tengo claro cómo deberían ser las cosas. Estoy buscando más ejemplos de configuraciones diferentes, pero tal vez estoy usando las palabras clave incorrectas. En este momento, solo va a haber un puñado de desarrolladores, y no estoy seguro de si debería hacer el repositorio como DocumentRoot. Realmente no sé qué preguntas hacer, ya que esto es nuevo para mí, pero agradecería que alguien pudiera proporcionar algún conocimiento y orientación. Algunas de las preguntas que tengo ahora son, ¿cómo debo configurar mis servidores y repositorios? ¿Debo configurar un VirtualHost por separado para un clon de prueba antes de hacerlo en vivo? ¡Cualquier cosa sería útil! ¡Gracias por adelantado!

Answer 1

Probablemente no haya una razón para hacer esto. Los mantendría separados pero configuraría un proceso automatizado (ya sea un script personalizado o continuous integration (CI)) para implementar desde Mercurial al sitio ejecutando un solo comando. Opcionalmente, puede hacer que cada confirmación desencadene una implementación.

EDITAR: Con la integración continua, es responsabilidad del servidor del CI la implementación. Si usa SSH, el CI extraerá de hg, exportará y luego lo cargará a través de SSH. Eso debería abordar sus problemas. Para una comparación de los servidores de CI que admiten Mercurial, consulte this question.

Answer 2

no tengo El respuesta a dar a usted, ya que muchas variables, y tiene por qué afectar el flujo de trabajo, pero aquí es algunos enlaces para empezar:

1. http://www.zdnetasia.com/a-development-workflow-for-mercurial-62204755.htm
2. https://www.mercurial-scm.org/wiki/Workflows
3. http://www.webdevelopment.nicholastuck.com/tools/one-project-one-repository-mercurial-used-right/

También le recomendaré que lea esta excelente introducción de Mercurial: http://hginit.com/

También puede encontrar varias preguntas sobre SO sobre los flujos de trabajo con Mercurial, eche un vistazo a las barras laterales de la derecha, por ejemplo.

Cuando tenga una pregunta más específica, ¡no dude en preguntar otra vez!

Answer 3

que haría su directorio DocumentRoot un subdirectorio de primer nivel de su repositorio, y aquí es algunas razones por las cuales:

1. Si está usando algo como Apache para administrar el servidor, se puede poner otra meta información, como sitios disponibles y archivos de configuración habilitados por sitios, en un directorio hermano, ya que no son realmente parte de los documentos del sitio web.
2. Del mismo modo, puede mantener un directorio "docs" al lado del código.
3. Si la raíz de su repositorio es su DocumentRoot, siendo todo lo demás igual, también está publicando su directorio .hg, donde está todo su historial de repositorio, y su archivo .hgignore, ese tipo de cosas. Puede arreglar esto con un archivo .htaccess, por supuesto, pero es más simple tener la carpeta secundaria.

Básicamente, las bases de código tienden a no ser exactamente iguales a los sitios desplegados, por lo que tiendo a favorecer que la raíz del documento sea un subdirectorio.

El despliegue es una nueva 'caja de sorpresas'.Realmente depende de sus necesidades en cuanto a lo que haces, pero esto es lo que hago:

que ejecutar una instancia VirtualBox en mi equipo que se ve lo más cerca posible a lo que mi servidor desplegado se parece, al menos lo más cerca como puedo obtener los archivos de configuración. Yo diría que este enfoque es menos propenso a errores que una entrada VirtualHost adicional. Dependiendo del proyecto, puedo hacer que esto sea idéntico, tal vez algunas entradas de DNS, así que puedo configurar todo para apuntar a testing.myproject o production.myproject, y esto I siempre automatizar (uso chef, pero eso es exagerado para un proyecto más pequeño) para que sea un código comprobable y no propenso a manipular los dedos. No hay nada peor que ejecutar pruebas de humo que borren su base de datos y que la configuración apunte accidentalmente a su prod db. La ejecución de una máquina virtual le permite probar sin esfuerzo las actualizaciones al entorno o sistema operativo de su servidor, y puede realizar una operación nukeada y restaurar a una instantánea si desea ir a un estado anterior de la configuración de la máquina.

Si realmente desea impedir el acceso desarrollador SSH para sus máquinas prod - y la OMI, que es una mala idea, porque si usted tiene problemas en el servidor de producción, que ha impedido a los desarrolladores de diagnóstico o fijándolo - entonces creo que su mejor opción es usar algo como hudson, que es un marco de integración continuo. Solo le da acceso a ssh al usuario de Hudson para ejecutar su script de implementación, pero cualquiera (con los privilegios correctos establecidos en Hudson) puede ejecutar ese trabajo. De hecho, es útil tenerlo en un entorno en el que tenga, por ejemplo, algunos miembros de administración de productos desean tener la capacidad de actualizar el servidor de producción sin poder iniciar sesión. La versión de "pobre" de esto está usando sudo para permitir a sus desarrolladores ejecutar un comando ya que otro usuario que tiene tiene ssh acceso - and only allowing them to run the publish script.

Todavía recomendaría dar a sus desarrolladores acceso a su máquina, aunque no tiene que entregar las llaves del reino. Simplemente cree un grupo de "desarrolladores", asigne sus desarrolladores y déle permisos suficientes para jugar con los directorios necesarios del servidor, y debería estar listo para comenzar.