Como dice el refrán, no hay almuerzo gratis. Aunque algunos servicios ofrecen repositorios de Subversion privados gratuitos (RiouxSVN, Springloops, etc.), estos generalmente vienen con limitaciones significativas (ya sea en términos del tamaño máximo de almacenamiento o la cantidad de usuarios que pueden acceder al repositorio).
Realmente, la decisión depende de si paga un repositorio de Subversion completamente administrado que esté preconfigurado (como el que ofrece Cloud Forge o Beanstalk) o si, en cambio, paga por una Infraestructura-como-una- Servicio de hospedaje de nube de servicio (IaaS) (como Compute Engine, AWS EC2 o Azure) para una máquina virtual y asuma la responsabilidad de la configuración del servidor de Subversion en esa instancia de máquina virtual, asuma la responsabilidad de la seguridad y el control de acceso de esa máquina virtual. y asumir la responsabilidad del nombre de dominio, certificados SSL, etc. que se utilizan para acceder a ese servidor de forma remota a través de Internet. También existe un enfoque intermedio, como utilizar una imagen/configuración de máquina virtual de un tercero específicamente para ejecutar un servidor de Subversion en un proveedor de alojamiento en la nube (como es el caso del uso del Cloud Launcher Subversion image proporcionado por Bitnami, que simplifica el aprovisionamiento , mantenimiento, implementación, etc. de Subversion en Compute Engine).
Para todas las diferentes opciones/enfoques, la compensación suele ser entre costos y molestias; usar un proveedor de alojamiento en la nube y configurar un servidor Subversion usted mismo es más complicado pero también más económico. También hay una compensación en términos de riesgo/seguridad; si despliega un servidor de Subversion en Compute Engine o en una VPC en AWS y no expone la máquina a Internet pública (de modo que solo sea accesible para otras VM aprovisionadas en esa subred/VPC), entonces el riesgo es relativamente bajo; Sin embargo, una vez que lo configure para que sea accesible para la Internet pública, debe considerar si prefiere poseer ese riesgo y la seguridad de la VM usted mismo, o pagar más para que un tercero administre ese riesgo. Otra compensación a considerar es la flexibilidad; el enfoque hágalo usted mismo puede permitirle personalizar elementos del comportamiento del servidor de Subversion (como detalles de cómo autoriza a los usuarios) que no podrá controlar tan fácilmente con una opción completamente alojada. Por último, otra desventaja a tener en cuenta es el costo y la facilidad de realizar copias de seguridad del repositorio; si vale la pena almacenarlo en un repositorio, es probable que también valga la pena realizar una copia de seguridad; algunas soluciones hacen que sea más fácil/más barato realizar copias de seguridad que otras.
¿Su proyecto es de código abierto? –
no. es un proyecto de la compañía. ¿Cuál es la mejor manera para este tipo de proyectos? svn privado? el problema es que no tenemos un servidor (que podría estar funcionando 24 * 7). ¿Cuál es la mejor solución entonces? –
LMAO en el título actual de "purblic ... server". Eso es maravilloso, y no voy a editar el título para que se deletree correctamente. –