Passer au contrôle de code source

La nôtre est une assez petite entreprise (3-4 programmeurs et 3-4 concepteurs de sites) qui développe une application Web PHP à usage unique qui fournit les fonctionnalités à environ 100 sites Web. Nous opérons depuis quelques années dans un environnement de développement et de production distinct qui fonctionne assez bien. Il y a toujours eu suffisamment de fonctionnalités distinctes à développer pour que les programmeurs ne se heurtent jamais vraiment et il était plus pratique de travailler sans le contrôle de code source; même s'il y avait un risque de perte de données et nous avons eu notre juste part de fichiers disparus dans un mouvement par inadvertance.

L'autre considération est que nos concepteurs ne sont pas technophiles (je les ai introduits dans le balisage html, au lieu d'utiliser les WYSIWYG). Cela a été l'une des raisons d'hésiter à passer au versioning.

Cependant, maintenant que nous avons atteint plus de 100 sites et que l'équipe de développement s'agrandit, j'essaie de standardiser nos procédures et le contrôle des sources semble une étape logique pour les programmeurs. J'espère que cela accélérera également nos déploiements de correctifs.

Malheureusement, j'ai une expérience très limitée de la mise en place d'un système de contrôle de source. Ce que je suis curieux d'entendre de la part de personnes ayant une configuration similaire, ou de l'expérience en effectuant le changement:

1) Est-ce que vous versionnez tout (sites, css, modèles html et code d'application) et forcez-vous ainsi les concepteurs à apprendre le contrôle de version? Ou est-ce seulement les développeurs qui travaillent sur le code de l'application?

2) Quels sont les pièges à éviter lors de la configuration initiale du contrôle de source?

3) Déploiement de dev => conseils de production pour le contrôle des sources.

Merci pour toute perspicacité.

Édition 1: Dang. Jusqu'à présent, tout le monde recommande de tout contrôler. Cela va me faire perdre mes cheveux tôt. Cela va probablement déclencher une nouvelle question dans un proche avenir. Merci pour les conseils jusqu'à présent, continuez à venir!

Edit 2: Beaucoup de bonnes réponses, et nous examinerons les différents systèmes de contrôle de version. Merci à tous pour vos réponses!

Il est utile d'avoir tout versionné, même pour les concepteurs. Et s'il est bien mis en œuvre avec une bonne formation, je pense qu'ils trouveront cela plus utile que fastidieux.

Si vous débutez, je vous suggère fortement d'utiliser un système de contrôle de version distribué comme git ou mercurial . C'est la tendance générale dans le monde, et il y a beaucoup d'avantages. Il est facile de travailler en mode déconnecté, sans dépendance réseau et la possibilité de faire un travail privé et non poli toujours sous contrôle de version, en vérifiant tout de manière centralisée quand il est prêt.

Et, pour ne pas recourir aux appels à l'autorité ou quoi que ce soit, mais découvrez ce que Joel Spolsky a à dire sur le sujet . (Citation de choix: "Subversion = Sangsues. Mercurial et Git = Antibiotiques.") approche depuis le début est une victoire.

Je dirais de tout mettre sous contrôle de version. Une fois que tout fonctionne, vous pouvez le copier dans une balise qui, pour la plupart des systèmes SCM, ne nécessite pas beaucoup d'espace disque sur le serveur.

En ce qui concerne les pièges initiaux, vous ne devriez pas avoir à vous inquiéter beaucoup; tout valider sur le serveur et s'il n'est pas correct, vous pouvez le mélanger et supprimer les éléments supplémentaires plus tard. La seule chose que je ne commettrais pas, ce sont les artefacts qui sont construits à partir des sources, c'est-à-dire que les fichiers de code java appartiennent au contrôle de version mais pas les classes compilées ou des ISO / DVD entiers de binaires "construits à partir des sources".

Le développement vers la production est facile, à chaque étape importante, créez une succursale. La disposition du répertoire dans le système de contrôle de version ressemble généralement à ceci:

/ trunk / project / branches / project / version1 / branches / project / version2 / branches / project / version3

Supposons donc que vous trouviez un bogue dans la version 2 du produit, que vous accédiez à cette branche, le corrigiez et libériez la version 2.1. Pendant que vous travaillez sur le dossier / trunk / project pour la nouvelle version 4 et c'est à vous de décider quelles fonctionnalités sont fusionnées en avant et en arrière.

Ne laissez pas les buveurs SCM kool-aid vous tromper, il existe très peu de différences fonctionnelles entre les systèmes de contrôle de version populaires, à savoir Subversion et Git. La chose la plus importante pour votre équipe sera la bonne intégration de ces serveurs avec vos outils existants. Je n'aime pas non plus les WYSIWYG, mais il est bien sûr d'avoir eclipse-php ou d'autres IDE compatibles avec le serveur.

Je suis développeur et j'ai déjà travaillé en tant qu'administrateur informatique.

Pour répondre à vos questions spécifiques:

1) Oui, tout version.

2) Suggérer de mettre en place un référentiel de contrôle de version factice et un projet factice pour que les gens apprennent.

3) Identifiez les versions mises en production. même les épreuves. Ensuite, vous pouvez toujours vérifier une version spécifique que quelqu'un exécute.

Je vois que vous avez marqué la question CVS.

Ma suggestion est de considérer sérieusement la subversion, combinée avec TortoiseSVN, ce qui la rend très facile à utiliser. Il existe également un TortoiseCVS.

Je vous suggère d'exécuter un didacticiel en interne sur le contrôle de version. Je serai surpris si vos développeurs / concepteurs n'ont jamais rencontré cela auparavant. La tortue la rend très conviviale.

Il peut également être avantageux d'installer l'une des interfaces Web dans cvs ou subversion.

La raison pour laquelle je suggère la subversion par rapport à CVS est que même si CVS est très bon, il présente de sérieux problèmes de conception et de mise en œuvre. Les gros problèmes pour moi étaient: 1) Vous ne pouvez pas versionner les répertoires 2) La gestion des fichiers binaires n'est pas trop bonne car beaucoup de choses par défaut sont du texte. 3) Aucun commit atomique. 4) Je me souviens qu'il a souvent gâché et laissé des fichiers de verrouillage que j'ai dû supprimer manuellement du magasin de codes. Il y avait de la place pour la corruption en faisant cela depuis votre rm les fichiers de verrouillage. 5) Prise en charge SSL et gestion des utilisateurs / mots de passe

Subversion résout fondamentalement tous ces problèmes sont probablement beaucoup d'autres. Il a également beaucoup de fonctionnalités avancées comme les externes (que j'utilise en fait). Et il est possible de lier les utilisateurs / groupes dans un répertoire actif que vous pourriez trouver utile. À l'époque, j'utilisais CVS qui n'était pas disponible. C'est peut-être maintenant, je n'ai pas vérifié.

La plus grande différence pour comprendre SVN dans son utilisation est probablement que vous ne créez pas de balises. Au lieu de cela, vous créez ce qui semble être des copies où le répertoire du projet est copié dans le dossier Tags et donné un nom. Jetez un oeil dans la documentation et vous verrez ce que je veux dire. Je sais que ça a l'air bizarre mais on s'y habitue.

Ce site Web pourrait être d'un certain avantage (bien que je ne puisse pas en témoigner): Configuration d'un référentiel svn modulaire pour les sites Web php http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-sites web

Avec beaucoup de respect pour une grande partie de la sagesse qui apparaît ci-dessus - et il est sage - le déploiement du contrôle de version est comme le déploiement de systèmes de surveillance. Mes clients disent "que dois-je surveiller", et la réponse évidente est "tout surveiller". Mais ce n'est pas une bonne nouvelle: ils ont 350 systèmes, dont chacun a 20-30 variables système plus un tas de variables spécifiques à l'utilisation, et ils pourraient tous être utilement surveillés; mais il n'y a qu'un seul de moi, et ils aimeraient voir des résultats d'ici quinze jours.

Donc, bien que je convienne que la meilleure pratique consiste à tout contrôler par version, si cela n'est pas pratique dans un premier temps, commencez par contrôler les choses dont le manque de contrôle vous a causé le plus de problèmes jusqu'à présent .

Si la plupart des pannes sont causées par le code d'application, commencez par contrôler cela; si la plupart par des correctifs CSS non planifiés, contrôlez cela; etc.

Non seulement cela vous donnera le meilleur retour sur investissement en temps, mais cela vous donnera à son tour de bonnes raisons d'étendre l'utilisation du contrôle de version à l'avenir: "Depuis que nous avons ajouté le contrôle de version au code d'application, des interruptions imprévues de plus de 30 minutes sont passés de 11 par mois à 2. Ces deux ont été provoqués par des modifications HTML statiques, nous avons donc l'intention de contrôler les versions par la suite. ".

Un déploiement progressif vous offre également des utilisateurs qualifiés au sein de l'organisation. Oui, vous avez dû enseigner aux six développeurs d'applications comment utiliser le système, mais ils ont appris et ils sont d'accord avec cela; maintenant qu'il est temps de déployer le système à l'équipe CSS, vous avez six experts internes de plus qu'il y a trois mois. Vous pouvez même avoir des convertis à ce moment-là; un développeur dont le cul a été sauvé par la possibilité d'annuler rapidement un changement dommageable pourrait bien être votre meilleur évangéliste de l'équipe CSS.

Édition 1: si vous décidez de suivre cette voie, un filet de sécurité bon marché consiste à ajouter un fil de déclenchement sur le dessus, au moins sur une boîte de production. De cette façon, si Things Break mais que le VCS dit que ce n'est pas de sa responsabilité, vous pouvez rapidement identifier ce qui a changé, ce qui accélère le correctif et suggère votre prochain candidat pour le contrôle de version.

La version contrôle tout. Cela ne sert à rien d'avoir des fichiers HTML sous contrôle de version et d'avoir un site complètement vissé à cause d'un changement de CSS qui n'est pas contrôlé et ne peut donc pas être facilement inversé.

Pièges: personnellement, je n'en ai rencontré aucun lors de mon utilisation certes assez limitée du contrôle de version.

Déploiement: J'utilise actuellement la subversion hébergée sur des box Windows, au travail comme à la maison. Windows uniquement parce que c'est ce qui est disponible. Sinon, il aurait tout aussi bien pu être un autre OS. La clé pour les utilisateurs non techniques i est de leur donner un outil simple basé sur une interface graphique pour gérer les importations, les exportations, les validations, les différences, etc. L'outil à utiliser dépendra un peu du système d'exploitation et du système VCS utilisés.

Utilisation: lorsque je fais des changements de code, je teste et j'engage souvent. Cela me permet de remonter aussi loin que nécessaire lorsque je bousille. De plus, en comparant diverses révisions et en copiant des parties du code, je n'ai pas à perdre toutes les modifications simplement parce que je dois revenir à une version précédente pour corriger certaines choses dans une autre partie du code.

Avantage supplémentaire: vous pouvez donner accès au référentiel source via un VPN ou une connexion sécurisée, permettant aux utilisateurs de travailler depuis leur domicile ou ailleurs. par exemple, je pourrais avoir une idée à la maison et éditer mon code de travail là-bas et puis, avant de perdre la pensée.

Version tout.

Le déploiement dépend du montant que vous devez "personnaliser" pour chacun de ces sites. S'ils sont identiques, à l'exception d'un fichier de configuration ou deux, vous pouvez simplement consulter une copie du code et y apporter des modifications mineures. Au besoin, exécutez la commande de mise à jour de votre contrôle de version pour chacun des clients.

Si vous optez pour le modèle de distribution "Commander directement dans le site du client", vous devez vous assurer que votre serveur exclut l'accès aux répertoires de contrôle de version afin que les utilisateurs ne puissent pas naviguer sur http://example.com/. git / et jetez un œil à vos internes. De plus, j'aurais certainement un hôte virtuel de test et de production pour chaque client afin de m'assurer qu'une mise à jour du site ne se détraque pas. Surtout si vous apportez des modifications personnalisées aux fichiers de chaque client, vous devrez gérer les conflits avant que les modifications ne soient mises en ligne. Dans ce cas, vous devez extraire / mettre à jour l'hôte virtuel de test et, lorsque tout fonctionne correctement, vous copiez l'hôte virtuel de test sur l'hôte virtuel de production.

Tout ce que les gens disent de la version est bon.

Si vous décidez d'utiliser la subversion, je vous recommande d'essayer la pile Bitnami Trac; http://bitnami.org/stack/trac

Il simplifie la configuration de subversion pour vous, est livré avec un système de ticket (que vous pouvez choisir d'utiliser à ce stade ou non) pour garder une trace des changements et des bugs, et un wiki que vous pouvez utiliser pour documenter comment vous souhaitez que vos développeurs utilisent le système.

Donnez à tous vos développeurs Windows TortoiseSVN. Apprenez à tout le monde quelques notions de base de la ligne de commande svn.

En fin de compte, l'outil est moins important que l'état d'esprit que vous devez inculquer à vos développeurs. Espérons qu'ils verront bientôt que le contrôle de version est une bonne chose car cela les empêche de perdre du travail et leur permet de revenir dans des impasses qui ne les ramènent nulle part vers de bons états connus. Les avantages l'emportent sur les (légers) frais généraux.