Comme le dit l'adage, il n'y a pas de repas gratuit. Bien que certains services proposent des référentiels Subversion privés gratuits (RiouxSVN, Springloops, etc.), ils présentent généralement des limitations importantes (en termes de taille de stockage maximale ou de nombre d'utilisateurs pouvant accéder au référentiel). En réalité, la décision revient à savoir si vous payez pour un référentiel Subversion entièrement géré et préconfiguré (tel que celui proposé par Cloud Forge ou Beanstalk) ou si vous payez pour une Infrastructure-as-a- Service d'hébergement cloud Service (IaaS) (Compute Engine, AWS EC2 ou Azure) pour une machine virtuelle et assumer la responsabilité de l'installation du serveur Subversion sur cette instance de machine virtuelle, prendre en charge la sécurité et le contrôle d'accès de cette machine virtuelle, et assumer la responsabilité du nom de domaine, des certificats SSL, etc. utilisés pour accéder à distance à ce serveur via Internet. Il existe également une approche intermédiaire, comme l'utilisation d'une image/configuration de machine virtuelle tierce pour exécuter un serveur Subversion sur un fournisseur d'hébergement cloud (comme c'est le cas avec l'utilisation du fourni par Bitnami, ce qui simplifie le provisionnement , maintenance, déploiement, etc. de Subversion sur Compute Engine).
Pour toutes les différentes options/approches, le compromis est généralement entre les coûts et les tracas; l'utilisation d'un fournisseur d'hébergement cloud et la mise en place d'un serveur Subversion vous-même est plus difficile mais aussi moins cher. Il y a aussi un compromis en termes de risque/sécurité; si vous déployez un serveur Subversion sur Compute Engine ou dans un VPC sur AWS et n'exposez pas l'ordinateur à l'Internet public (afin qu'il ne soit accessible qu'aux autres machines virtuelles provisionnées dans ce sous-réseau/VPC), le risque est relativement faible; Cependant, une fois que vous l'avez configuré pour être accessible à l'Internet public, vous devez déterminer si vous préférez posséder ce risque et la sécurité de la VM par vous-même plutôt que de payer un tiers pour gérer ce risque. Un autre compromis à prendre en compte est la flexibilité. l'approche de bricolage peut vous permettre de personnaliser les éléments du comportement du serveur Subversion (tels que les détails de la façon dont il autorise les utilisateurs) que vous ne pouvez pas contrôler aussi facilement avec une option entièrement hébergée. Enfin, un autre compromis à considérer est le coût et la facilité de sauvegarde du référentiel; si cela vaut la peine d'être stocké dans un dépôt, il vaut probablement la peine de le sauvegarder; Certaines solutions rendent la sauvegarde plus facile/moins coûteuse que d'autres.
Votre projet est-il open source? –
no. C'est un projet d'entreprise. quel est le meilleur moyen pour ce genre de projets? svn privé? le problème est que nous n'avons pas de serveur (qui pourrait être opérationnel 24h/24 et 7j/7). quelle est la meilleure solution alors? –
LMAO au titre actuel de "purblic ... server". C'est merveilleux, et je ne vais pas éditer le titre à épeler correctement. –