¿Por qué no implementar el código directamente desde el repository git o bzr?

En una configuration de desarrollo / testing para una aplicación web, al usar un dvcs (bzr, git) ¿por qué sería incorrecto ejecutar la aplicación desde el directory del repository ?

Todos los equipos que he encontrado tienen una secuencia de commands de implementación separada que exporta la salida del repository a otro directory o server, pero realmente nunca entendí por qué y tenía miedo de pedirle al "adulto" que no pareciera "estúpido" … Es decir, es un server de desarrollo de todos modos, no la producción, entonces …?

Para aclarar, el problema no es realmente acerca de cómo se implementa, esa es otra pregunta. El principio más profundo es que su entorno de testing debe estar lo más cerca posible de la producción por las razones @DaveE mencionadas: pequeñas diferencias de implementación pueden hacer que sus testings sean inútiles.

Realmente parece que piensas que duplicar la installation de producción es demasiado trabajo para tus testings mientras desarrollas. Hay dos soluciones para eso. Hacer que su entorno de testing difiera de la producción no es uno de ellos.

Primero, facilite la installation de la producción. Esto podría estar convirtiendo un process manual (copyr files aquí, ejecutar estos scripts, cambiar estos permissions …) en un process automatizado. O podría estar networkinguciendo lo que hace la implementación. No puedo decir más sin conocer los detalles.

Si no tiene un entorno de testing, su entorno de desarrollo se convierte en su entorno de testing y debe seguir las reglas más estrictas de ser su única línea de defensa antes de la producción. Para evitar eso, crea un server de ensayo para probar. Un server de transición es uno que refleja la producción en la mayor cantidad posible. Las copys de desarrollo se instalan primero en el server de ensayo y se testingn antes de pasar a producción. Esto le da un sistema de testing de dos etapas. Hace algunas testings en su entorno de desarrollo less que exacto, y la batería completa de testings se realiza en el entorno de ensayo. El set de testings completo no tiene que ejecutarse todo el time, por lo que el server de transición no tiene que actualizarse constantemente. YMMV. A continuación, puede networkingucir las esquinas en su entorno de desarrollo para acelerar el desarrollo, sabiendo que todo se probará en una installation completa antes de la producción.

Si tiene los resources, un server intermedio es un espejo perfecto de todo el hardware y software en producción. Probablemente no tenga eso, entonces puede ser una máquina virtual o simplemente un subdirectory. Ambos pueden vivir en su máquina de desarrollo si no tienen acceso al rest del equipo.

La automation del process de installation, más un server de transición, significa que puede comenzar a realizar testings de continuous integration . Este es un término elegante para "ejecutar automáticamente las testings en un server de testing en cada confirmación". Un ejemplo de un sistema de continuous integration es Jenkins . Entonces, no importa cuán complicada sea su implementación, sus robots se encargarán de eso.

Entonces, aunque a primera vista parece mucho trabajo, al final todo se junta para permitir las testings sin que siquiera presiones un button.

En última instancia, su nuevo código debe probarse en un entorno tan similar como sea posible a la producción antes de ser publicado. Hay muchas forms de lograr eso, pero esa es una regla sólida.

¿Preferirías ver un time de ejecución donde las routes y los permissions están cerca, ya que serán reales, por lo que cualquier error podría reflejar la realidad, o te gustaría pasar el time corriendo por problemas extraños que se resolverán en una implementación no estándar? idiosincracias? Ya sabes, cosas como

  • usted es un administrador local, por lo que todos los resources están disponibles para usted, pero cuando algo se implementa donde la count de usuario no es un administrador, falla
  • ruta de acceso que se resuelve localmente pero no en una installation implementada
  • esa nueva cosa que no se convirtió en el check-in de [su | otra persona], por lo que "¡Funciona en mi máquina!" ™

o cualquiera de una serie de otras cosas que disminuyen la velocidad pero no contribuyen a la entrega de código de calidad.

tl; dr: lo que dice @Schwern a continuación.