¿Debería estar en los servidores de desarrollo o en un servidor de Subversion?¿Dónde debería estar un repositorio Subversion?
Supongo que esto podría ampliarse a cualquier sistema de control de versiones de cliente-servidor.
El repositorio físico debe estar en un sistema estable que obtiene copias de seguridad periódicas.
Generalmente, un servidor de desarrollo no se ajusta a esta descripción ... puede ser aceptable colocar el servidor apache en el servidor de desarrollo y alojar los archivos de forma remota en un servidor de archivos estable y respaldado (aunque hay un número de trampas con este enfoque) si no puede obtener recursos adicionales del servidor. Hospedarlo en el servidor de desarrollo puede estar bien si tiene un sistema de respaldo agresivo para proteger su código ...
Solo tenga en cuenta que los servidores de desarrollo son propensos a cambios de configuración, voladura o de lo contrario son molestos con eso podría derribar su repositorio en un momento crítico.
¿Cómo lo respaldaría normalmente? rsync? – Liam
Tiene varias opciones, incluida rsync. Si su repositorio fue configurado usando Berkley FS, hay algunos scripts de respaldo que puede ejecutar. Puede hacer una copia de seguridad de esos archivos utilizando cualquier mecanismo de copia de seguridad que desee. Si está utilizando FSFS, puede hacer una copia de seguridad en vivo del repositorio directamente. –
Guardo el mío en el servidor de desarrollo, que también ejecuta Trac, Apache presentando una copia actualizada automáticamente del proyecto JavaDocs y la plataforma de compilación CI. Un proyecto tendría que ser de proporciones bastante épicas para requerir un servidor Subversion dedicado.
Sin embargo, tenga en cuenta que es muy importante mantener su repositorio de Subversion respaldado en otra máquina en otra ubicación: ¡su repositorio es su activo más valioso!
Me gusta mantener el mío en su propio servidor, solo porque en mi opinión es uno de los servidores más importantes de una organización y lo mantiene en su propio servidor ayuda a los administradores a hacer copias de seguridad y otras actividades de mantenimiento. Y como el servidor es por lo que es importante, no quiere que otros desarrolladores lo estropeen de ninguna manera que pueda comprometerlo por accidente.
Además, si tiene un grupo de desarrolladores y un servidor activo de integración continua ejecutándose, en realidad podría aumentar la CPU bastante y lo último que desea hacer es tener algo que obstaculice la ejecución de los cambios de código.
Las cajas de desarrollo serán, por definición, destruidas y se caerán. ¡Viene con el territorio!
Está seguro de querer que esto suceda a sus repositorios de código fuente? ...
Además de lo que otras personas mencionadas acerca de los servidores dev siendo destrozados con regularidad, hay un argumento rendimiento también. Si alguien está realizando algún desarrollo o prueba en el servidor de desarrollo, no querrá que disminuya la velocidad del servidor SVN para realizar el pago o la sincronización. Además, si decide ejecutar algo así como la integración continua en el mismo servidor, no desea que todas las pruebas de su unidad bloqueen las operaciones regulares de desarrollo/prueba en ese servidor.
En mi empresa lo ponemos en una máquina dedicada que proporciona almacenamiento redundante. Creo que en nuestra cultura valoramos mucho la fuente, el tiempo y el esfuerzo necesarios para crear nuestros códigos fuente. Nunca pusimos ningún tipo de máquina de prueba que podría dañarse o borrarse porque la configuración se volvió inmanejable.
woops. también mantenemos nuestro seguimiento de defectos en la misma caja, pero por la misma razón.
Utilizamos una pizarra limpia y en blanco para nuestros repositorios. Específicamente, utilizamos Slicehost para nuestro repositorio principal.
Comenzamos con un segmento de 256MB y luego lo actualizamos a 512MB. Slicehost es excelente porque, para empezar, sabe que tiene un servidor completamente limpio y puede construir las cosas que necesita por su cuenta.
Slicehosts' articles son de primera clase.
Nuestro servidor de recompra se ve así:
Y eso es todo. No hay mucha sobrecarga.
Editar: No estoy tratando de vender Slicehost aquí, así que si eso no es kosher, ¡házmelo saber!
Editar nuevamente: James hace una excelente observación sobre el alojamiento de código propietario en un servidor de terceros. Se debe tener especial cuidado al seleccionar un host para hacer tal cosa. Desafortunadamente, muchas empresas simplemente no tienen los recursos para construir y administrar servidores internos, que es donde nos encontramos antes de seleccionar un host para nuestro código.
Alojar su código con terceros remotos y no establecidos conlleva * GRANDES * riesgos que deben sopesarse con los beneficios. La bancarrota, la seguridad, el robo de IP, las interrupciones, los problemas de conectividad de red, etc. pueden dejarlo a merced de la empresa de terceros en un momento crítico. –
Es por eso que tiene copias de seguridad automáticas, James. – ceejayoz
¿Cómo ayuda la copia de seguridad automatizada con el robo de IP por parte de un tercero? Y las copias de seguridad automatizadas no cambiarán el hecho de que no tiene servidores locales. Si el servicio de alojamiento se apaga, ¿cuánto tiempo hasta que esté funcionando nuevamente? ¿Cuánto te cuesta eso? –
Siempre es mejor mantener sus repositorios en un servidor estable donde puede realizar copias de seguridad de manera confiable siempre que sea necesario.
¿Podría describir algunos objetivos o restricciones que permiten que esta pregunta se responda de manera más analítica? –