Configuración del flujo de trabajo perfecto para el desarrollo web con 2-3 personas que usan la subversión

Question

Dirijo una pequeña empresa de desarrollo web junto con mi hermano y amigo. Después de hacer una extensa investigación, he decidido usar subversion para el control de versiones.

Así es como actualmente planeo ejecutar un desarrollo típico. Tenga en cuenta que somos 3 de nosotros cada uno en un lugar diferente.

Configuré una cuenta con springloops (springloops.com) host de subversión. Cada vez que trabajo en un nuevo proyecto, creo un repositorio para él. Digamos que en este caso estoy trabajando en el sitio1. Quiero tener 3 versiones del sitio en Internet:

1. Desarrollo Web - Este es el servidor mí y los otros desarrolladores publican a. (Site1.dev.bythepixel.com)
2. de vista previa de cliente - Este es el servidor que actualizamos cada pocos días con una buena revisión para que el cliente vea. (site1.bythepixel.com)
3. Sitio vivo - El sitio publico a cuando se va en vivo (site1.com)

Cada máquina desarrollo web (en cada lugar) tendrá una copia local de xamp ejecutando un host virtual para permitir trabajar en varios sitios web. La raíz de la copia local está configurada para ser la misma que la copia local del repositorio de subversión. Esto está configurado para que podamos hacer ajustes pequeños y obtener una vista previa de ellos inmediatamente. Cuando se ha realizado algún trabajo, se realiza una confirmación en el repositorio del sitio. Haré que el sitio de desarrollo se presione automáticamente (es una opción en springloops). Luego, cada vez que me sienta listo para ingresar al sitio del cliente, lo haré. La etapa final será presionar al sitio en vivo.

Ahora, tengo algunas preocupaciones con los flujos de trabajo:

1. estoy usando CodeIgniter actualmente, y en el archivo de configuración por lo general establecer la raíz del sitio. Ex. http://www.site1.com. Entonces, parece que cada vez que publico en uno de los servidores de Internet, ¿tendré que modificar el archivo de configuración? ¿Hay alguna manera de hacerlo de manera que ciertos archivos estén configurados para cada servidor? Entonces, cuando presiono publicar en la vista previa del cliente, solo carga el archivo de configuración para el servidor de vista previa del cliente.

2. No quiero que el sitio en vivo, el sitio de vista previa del cliente y el sitio de desarrollo compartan el mismo servidor mysql por una variedad de razones. Entonces, ¿esto significa una vez más que tengo que ajustar la información del servidor db cada vez que presiono para un sitio diferente?

3. ¿Tiene sentido este flujo de trabajo? Si tienes alguna sugerencia, házmelo saber. Planeo que este sea el flujo de trabajo que utilizo para los próximos años. ¡Solo necesito poner en funcionamiento un sistema que permita una expansión futura!

Answer 1

1) Mire en el concepto de integración continua. (Hay una docena libre para servidores pequeños proyectos de IC, por ejemplo TeamCity)

2) Tener 1. Preparar procedimiento de despliegue que va a ser capaz de dirigirse a cualquiera de sus tres ambientes

3) Considere SIEMPRE comprobar que no no es .los archivos accesibles a los usuarios sobre desplegadas situada SVN, porque es muy insegura

también leer algo sobre el trabajo con las etiquetas/ramas en SVN

A continuación, me gustaría proponer la siguiente flujo de trabajo

Primer caso (simple) Todo el mundo realiza el pago y funciona en copia local. Habiendo comprometidos (bien probado) cantidad de nueva funcionalidad, su disparador (tal vez de forma automática) de vista previa para ser construir Tener vista previa exhaustiva prueba, que desencadenan la construcción de la producción

segundo caso (mejor) Todo el mundo comete una rama en cada cantidad considerable de cambios y puede enviar cualquier cosa a su propia sucursal. Después de haber rama rama estable, de combinarlo en el tronco lo que desencadena la máquina de prueba para obtener y construir lo que usted nombre de vista previa y marcar una etiqueta vista previa Integralmente probado va a liberar rama

punto de tener tantas ramas es poder para almacenar el historial de cambios personales y compilaciones estables a la vez.

Answer 2

Hay mejores soluciones de control de versiones para los sistemas de control de versiones distribuidos que la subversión, yo altamente recomiendo mirar en uno de estos:

1. https://www.mercurial-scm.org
2. https://git-scm.com/
3. http://bazaar.canonical.com/en/

ver here, here y here para algunos homosexuales discusión nítida

también, como dijo vittore, consideraría que una solución de CI es bastante útil, que podría automatizar su impulso del entorno de desarrollo a la "producción" donde el cliente podría verlo en un ciclo de compilación/prueba exitoso .

Answer 3

No desea utilizar la raíz de su repositorio como raíz de su copia de trabajo. Eso hace que sea imposible usar ramas más tarde. (O siempre siempre verificamos todas las sucursales localmente ... haciendo las copias baratas de Subversion, caras en la copia de trabajo)