Desarrollo web con flujo de trabajo de control de versiones

Breve:
Trabajo en un equipo de 2 hombres (podemos expandirnos en el futuro).
Tenemos un server de desarrollo web y tenemos un server de producción.
Actualmente, cuando comenzamos el desarrollo, los iniciamos en localhost, luego los implementamos en web-dev (al que tenemos acceso a través de un disco montado) y enviamos cambios desde este disco "compartido" a SVN. Prueba final en web-dev, aprobación desde la parte superior y fuera de FTP a nuestro server de producción.
(Puedo escuchar a Lynch venir …)
Sí, soy consciente de que todo está mal al compartir files desde una location y enviarlos desde allí, pero esta no era una mala idea en aquel entonces cuando conocí SVN. Y ahora quiero cambiarlo.

Por lo tanto, sé conceptos básicos sobre el control de versiones, y que la forma en que funciona ahora es errónea. He pasado por wikipedia y algunas páginas svn, pero no he podido encontrar una solución perfecta para saber cómo debería funcionar.

¿Podrían algunos de ustedes, personas con mucha experiencia, sugerir cómo esto realmente debería funcionar?

Cosas que he descubierto:

  • deberíamos trabajar en copys locales en nuestras máquinas
  • luego enviamos cambios a SVN.

Cosas que quiero saber:

  • ¿Cómo hacemos la actualización de web-dev después de la confirmación de SVN?
  • cómo implementar parches en el server de producción? files ftp? es esto lo que haces? o alguna otra solución inteligente?
  • cualquier otra cosa que deba saber sobre el flujo de trabajo de web-dev.

Subversion tiene enlaces de confirmación de publicación que le permiten realizar acciones en una confirmación.

También puede ver una solución de continuous integration como CruiseControl.net o Team City.

Nuestro process es que los desarrolladores individuales trabajan en configuraciones locales. Nos comprometemos con Subversion y CruiseControl.net verifica y construye el sistema cada vez que uno de nosotros se compromete.

Hay una compilation progtwigda para el instalador de actualizaciones que se ejecuta semanalmente y actualiza la installation en un server que QA utiliza para verificar las correcciones. Una vez que se verifican las correcciones, alguien (manualmente) aplica la actualización que se aplicó al server de QA en los sitios de producción.

Recomiendo mirar los ganchos de confirmación de publicación, como sugiere nickd. Incluso puede rechazar una confirmación, si no puede comstackr (digamos que genera files HTML desde algunos files 'fuente' y si esa compilation falla puede esperar que la persona corrija eso antes de una confirmación).

  • ¿Cómo hacemos la actualización de web-dev después de la confirmación de SVN?
  • cómo implementar parches en el server de producción?

Ya sea automáticamente, a través del gancho, o puede considerar una "actualización svn" manual en las máquinas de producción, que le permite controlar cuándo, qué revisión y demás para utilizar.

El libro de SVN es excelente para leer. Uno puede leer solo las secciones relevantes y regresar más tarde para get más información. ¿Está utilizando troncales y tags? Son pan y mantequilla para el uso de svn y control de liberación.

Así es como lo he estado haciendo durante algunos años.

Servidor Dev: ubicado en la casa, contiene la stack LAMP, el repository y una copy de trabajo. Esto tiene las mismas versiones de software que el server de producción.

Servidor de producción: tiene un entorno de ensayo con copy de trabajo del repository, también tiene un entorno de producción con una versión del proyecto que no es svn (es decir, el sitio en vivo).

Desarrollador: tiene la stack LAMP y la copy de trabajo del repository en su máquina local.

Proceso típico:

El desarrollador actualiza la copy de trabajo del proyecto. Funciona en copy local, cuando se realizan los cambios actuales y sin errores, comtestingn la copy en el repository.

El enganche post-commit actualiza la copy de trabajo del server Dev. Es posible que desee hacerlo manualmente, especialmente si su equipo comienza a crecer.

Si los cambios están funcionando en Dev Server, la copy de trabajo en el entorno de ensayo se actualiza manualmente.

Si los cambios están funcionando en el entorno de ensayo, entonces usamos RSYNC para enviar cualquier cambio de la copy de trabajo del entorno de ensayo al entorno de producción.

Obviamente, esta es una explicación muy general de lo que sucede, ya que querrás integrar cosas como testings unitarias en el process, pero espero que esto ayude.

Un model que he utilizado con éxito es el siguiente

  • En lugar de subversión, use un sistema de control de versiones distribuidas, como Mercurial o Git
  • Todos los desarrolladores tienen un repository local con el que se comprometen localmente durante la implementación
  • Hay un repository de testing adicional al que todos los desarrolladores envían sus cambios después de que se hayan completado. Esto es verificado por QA y probado
  • Si todo está bien con el repository probado, se label y luego se envía al repository de producción

La forma en que lo hacemos es bastante simple, y al ser un equipo pequeño, es posible que puedas relacionarte.

  • El desarrollo se realiza en el host local y se compromete con una twig del tronco.
  • Para QA, la twig se fusiona con el tronco, y el entorno dev (que es copy del tronco) simplemente hace un svn up
  • Si todo está bien en QA, hago un svn up en el entorno en vivo (que también es una copy de trunk) y listo.

Todavía no lo he hecho, pero este process se puede simplificar agregando un enganche post-commit para actualizar automáticamente el entorno de desarrollo (como otros han sugerido).