Environnement de développement - VCS du développement à la mise en scène serveur à la production

Question

J'ai lu un certain nombre de sujets dans le même genre de stade que celui-ci, mais en toute honnêteté, je ne suis pas encore sûr de la meilleure approche (en tant que point de départ). Je suis un développeur solo dans un petit bureau et j'ai environ 30 sites Web qui sont hébergés sur un VPS Linux. Je veux commencer à utiliser le contrôle de version (probablement SVN) et également mettre en place un serveur de transfert. Pour l'instant, je fais du développement soit localement sur ma machine avant d'utiliser FTP pour uploader sur le serveur live, soit occasionnellement pour de petits changements j'édite directement les fichiers distants, ce qui n'est pas une approche idéale.

Je cherche des conseils sur la façon d'améliorer mon environnement de développement. J'imagine que je devrais installer SVN sur le serveur web, ce qui me permettrait alors de vérifier les versions sur ma machine locale (ce qui nécessiterait aussi SVN je pense). De même, si je veux configurer un serveur de transfert, devrais-je simplement configurer des sous-domaines pour chacun des sites Web en direct, puis utiliser ces sous-domaines pour montrer aux clients les modifications apportées au site avant de les mettre en ligne?

Espérons que cela a du sens!

Answer 1

Vous pouvez réellement installer le serveur SVN sur votre machine locale, que je recommande au lieu de l'installer sur le serveur Web (en supposant que vous faites des sauvegardes). La chose la plus facile à faire, puisque c'est seulement vous l'utiliser, serait d'utiliser le protocole file://, mais en utilisant svnserve est un peu plus robuste, et la méthode préférée si vous voulez prendre le temps de le faire.

Answer 2

@Michael, je ne suis pas d'accord - Je dirais qu'il vaut mieux installer sur le linux vps, surtout si vous payez déjà pour le service d'hébergement. Je trouve très utile de pouvoir parcourir et télécharger des choses de mon svn repo où que je sois, quel que soit l'ordinateur sur lequel je suis.

@nicky, j'ai commencé avec svn (et le contrôle de version) il y a plusieurs années et j'ai pris des petits pas qui m'ont permis de m'attaquer plus facilement. Si je devais recommencer, je commencerais par lire le svn book. Le livre est très bien présenté et n'a pas pris plus de 1-2 jours à labourer.

Pendant que vous lisez, installez svn sur votre vps Linux avec un apache front end.

Une fois que vous avez cela, choisissez l'un de vos sites Web et importez-le dans svn. C'est ainsi que je structure mon svn repo. Par exemple, dire que mon repo est hébergé chez http://mysvn.mydomain.com/svn/:

mywebsite1 
    - trunk 
    - tags 
    - branches 
    mywebsite2 
    - trunk 
    - tags 
    - branches 

Ne vous inquiétez pas de créer la structure parfaite. C'est assez facile à réorganiser, surtout quand vous commencez. Après avoir importé quelques projets dans svn, vous commencerez à avoir une idée des projets qui devraient avoir leur propre structure de répertoire "trunk/tags/branches" et qui peuvent être combinés.

Pour créer des environnements de test, je fais exactement ce que vous décrivez. J'utilise des scripts de construction à partir de svn et télécharge des fichiers dans des répertoires qui sont mappés à des sous-domaines comme "test.clientsite.com" (je travaille principalement sur java et utilise ant et maven, mais je pense que vous pouvez utiliser n'importe quel langage de script familier avec). Une fois que vous serez habitué au contrôle de version, vous ne reviendrez jamais, bonne chance!

Answer 3

C'est ce que nous faisons au travail:

Nous avons un serveur intermédiaire en cours d'exécution Apache et un serveur Subversion.Nous avons un hook de validation de publication qui met à jour une copie de travail dans le répertoire htdocs, de cette façon, lorsqu'un développeur valide quelque chose qu'il met automatiquement à jour sur le serveur de transfert, afin que tout le monde puisse voir le dernier code.

Sur les serveurs de production du client (ceux que nous pouvons contrôler), le client Subversion est installé et le site Web est une copie de travail. Lorsque nous avons besoin de mettre à jour le site en direct, nous nous connectons à un shell et exécuter svn up. Si vous faites quelque chose comme ceci, assurez-vous de limiter l'accès aux répertoires .svn, soit avec les fichiers .htaccess, soit depuis la configuration principale d'Apache.

Nous avons une application personnalisée qui gère les projets, mais c'est seulement parce que nous sommes paresseux et ne veulent pas configurer chaque projet à la main, l'application crée les répertoires et les copies de travail nécessaires. Vous pourriez écrire un script rapide pour le faire.

Nous jamais, jamais, éditer des fichiers via FTP sur le site en direct. Dans l'ensemble, nous utilisons cette configuration depuis presque 2 ans et, en dehors du conflit occasionnel sur le serveur de transfert, nous n'avons jamais eu de problème.