Comment utiliser correctement svn lors du développement d'une application web

Question

J'ai récemment commencé à me familiariser avec svn et même si cela semble assez simple pour le développement de code "normal", cela me laisse un peu confus au sujet du développement web.

Le développement Web nécessite un serveur web interagissant directement avec la source afin de tester les changements (souvent petits et très fréquents), donc je suppose que la racine du document du projet devrait être une copie de travail. Mais chaque utilisateur est supposé avoir sa propre copie de travail pour être fusionnée et validée dans le référentiel, puis exportée. Ce cycle entier n'est clairement pas réalisable lorsque vous devez modifier une feuille de style encore et encore pour satisfaire tous les navigateurs. Les utilisateurs ne peuvent clairement pas travailler sur la même copie de travail (c'est le point de svn) et vous ne pouvez pas vérifier différentes copies de travail dans la racine du document pour des raisons de chemin, donc quelle est la meilleure façon de travailler avec svn et web développement d'applications? Est-ce que chaque utilisateur doit avoir un interpréteur web/php sur la machine cliente?

Answer 1

Je l'ai toujours fait où chaque utilisateur a son propre interprète webserver/php, bien que tout ce dont vous avez besoin est votre propre apachectl qui passe le httpd.conf spécifique de l'utilisateur. Ensuite, chaque utilisateur a besoin de son propre httpd.conf. Donc tout ce que vous devez répliquer est le httpd.conf et l'apachectl, tout le monde peut partager la même installation Apache.

Answer 2

En un mot, oui.

Votre environnement de développement doit être distinct de votre environnement de production. Une fois que vous avez testé un changement sur votre machine, vous pouvez le valider sur SVN. Pour voir les changements que d'autres ont faits, vous mettez à jour votre copie de travail. Ensuite, lorsque vous souhaitez créer une version, vous exportez du serveur SVN vers votre serveur de production (ou un serveur de test pour que le contrôle qualité fonctionne correctement).

Answer 3

Chaque développeur dispose d'un poste de travail avec un IDE, un serveur web local et des outils client SVN. La webapp est extraite sur chaque poste de travail afin que les développeurs puissent valider les modifications dans le repo.

Answer 4

En fonction de la taille de l'équipe et la structure, ne serait-il plus sage dans ce cas

• travaux avec la même copie de travail dans ce cas par le réseau local, et d'employer le verrouillage sage fichier sur OS niveau

ou

• gère un répertoire « travail », dans laquelle tous les changements sont très souvent engagés pour que les autres peuvent mettre à jour leurs copies de travail, et un repo « finale » dans lequel l'équipe s'engage à la fin de la journée, ou à atteindre un point prédéfini?

Une application Web scriptée n'a généralement pas de processus de construction. Imaginez quelqu'un travaillant sur un fichier CSS, apportant des modifications et les vérifiant dans le navigateur toutes les quelques secondes. Imaginez quelqu'un d'autre travaillant sur un fichier HTML associé, faisant la même chose.

S'ils ont leurs propres environnements de test séparés, ils ne pourront jamais voir comment les changements de l'autre personne se reflètent dans leur travail. Et je sais ce qu'il en est de l'ajustement de certains détails CSS dans le navigateur - il peut prendre des dizaines de mesures jusqu'à ce que quelque chose se passe bien. Selon la structure de l'équipe, cela peut rendre l'interaction horriblement lourde.

N'hésitez pas à me corriger si je me trompe, je n'ai pas beaucoup d'expérience avec SVN dans une équipe de développement d'applications web.

Answer 5

Il n'y a vraiment rien de différent à propos du travail avec le développement web, par rapport à tout autre type de source (comme un client lourd). Ils sont tous les mêmes:

• Les développeurs vérifient une version du système.
• Ils apportent des modifications à ce qui est extrait.
• Le cas échéant (*), ils vérifient les modifications dans le référentiel. Les choses sont testées (dans une certaine mesure)
• Les modifications sont acceptées.
• Le système est extrait (ailleurs) et utilisé pour mettre à niveau la production.

Tous les logiciels en développement devrait avoir au moins trois cas différents:

développement
• (pour chaque développeur)
• test (pour chaque groupe d'essai)
• production

Si vous effectuez des modifications de développement directement dans votre copie de production, cela est généralement considéré comme imprudent. Cela peut sembler rapide, mais vous ne prenez pas en compte le «risque» correctement (et cela vous mordra un jour). Si vous partagez simplement un serveur Web entre développeurs de serveurs en cours de développement, vous demandez toujours des problèmes. Chaque instance de développement doit disposer de son propre environnement "complet". Chaque développeur doit avoir son propre serveur web, sa propre source, ses propres configs, etc. Utilisez le référentiel pour rassembler tous les éléments, cela fait partie de son travail. La structure de développement doit correspondre aux structures de test et de production "aussi près que possible". Il réduit les erreurs lors des installations.