Comment ajouter le contrôle de version et le serveur de développement séparé à l'environnement de développement php / web?
Je suis le chef d'équipe d'un petit groupe de développeurs. Mon expérience est principalement dans le développement d'applications et j'ai travaillé dans de grands groupes où le contrôle de version (SVN, Git, etc.) a été utilisé et s'est avéré très utile. Je commence à superviser notre développement Web, qui est actuellement un développeur php solitaire, cependant, nous allons bientôt ajouter un deuxième développeur php/web. Actuellement, nos programmes de développeurs php solitaires vivent (par exemple, il modifie un fichier php, télécharge le nouveau code et voit ce qui se passe). J'aimerais changer cela car il s'agit simplement de demander qu'un désastre se produise. Je pense aussi à ajouter une sorte de contrôle de version à son processus. Nous avons déjà un serveur SVN utilisé pour le développement d'applications, j'aimerais donc en tirer parti. Je cherche des conseils sur la meilleure façon d’aborder cette question et sur le type de changements à apporter.
Devrions-nous utiliser notre serveur Web existant pour le développement? Nous pourrions créer une copie complète des sites Web existants et les placer sur des sous-domaines. Nous apportons ensuite des modifications à ces copies et si tout se passe bien, nous synchronisons les sous-domaines avec les sites principaux. S'il s'agit d'une bonne approche, quel ensemble d'outils (par exemple, un logiciel) serait le mieux à utiliser pour la synchronisation? Existe-t-il un logiciel capable de valider ces modifications sur le serveur SVN lors de la synchronisation d'éléments sur le serveur Web? Moins il y a d'étapes dans ces changements, mieux c'est.
Ou serait-il préférable d'avoir un serveur complètement séparé pour le développement? L'inconvénient de ceci est la maintenance ... nous sommes à court de personnel.
Tous les conseils sont très appréciés. Le développement Web/PHP est un peu différent du développement de votre application standard (Java, C++, etc.) auquel je suis habitué. Je suis donc ouvert à toute idée de la meilleure façon de gérer ce service.
Merci Harry
Ne travaillez JAMAIS sur le serveur de production et "voyez ce qui se passe".
Familiarisez votre équipe avec:
et distribuez à chacun une copie de ce livre que je recommande vivement: Livraison continue: versions logicielles fiables via l'automatisation de la construction, du test et du déploiement
Automatiser autant que possible. Des tests de déclenchement, des linters, se construisent sans effort. Créez des environnements virtuels pour le développement, la mise en scène et la production. Avec les environnements virtuels, vous pouvez tester de nouveaux scénarios et imiter votre serveur de production (Recherchez, par exemple, "virtualbox headless", lisez des articles comme celui-ci ). Une fois mis en place, cela n’a vraiment aucune complexité puisque vous orchestrez chaque étape d’un clic de souris ou du prochain commit.
Dans le contexte de Delivery, il existe de nombreux outils permettant d’automatiser les tâches, que ce soit Capistrano ou Fabric (Python) ou bien sûr Jenkins (Java).
Il n’existe pas d’approche unique (lisez le livre), mais votre équipe perfectionnera le processus étape par étape.
Mon équipe est dans le même bateau et notre solution consistait à créer un serveur de développement local avec exactement la même configuration (Apache conf/php.ini/versions) que notre serveur de déploiement et à utiliser SVN pour le contrôle de version comme pour les applications traditionnelles. développement. Notre serveur de développement gère également les systèmes SVN + Bugtracking. Il est donc beaucoup plus facile de gérer les requêtes de bogues/fonctionnalités. Étant donné que les serveurs de développement et de déploiement ont une configuration identique, nous ne rencontrons que des erreurs de transfert lors du déploiement.
Vous devez décider vous-même s'il est utile de disposer d'un serveur de test/test séparé pour le développement.
En ce qui concerne les outils que vous pouvez utiliser, de nombreux outils de CI et d’automatisation du déploiement fonctionnent avec SVN. Capistrano est un outil très léger qui nécessite Ruby des connaissances, mais son utilisation vous permet de déployer/configurer des applications sur plusieurs serveurs assez facilement. Il est également possible d'écrire une recette Capistrano à déployer automatiquement sur le serveur de transfert lorsqu'une nouvelle validation est effectuée (avec un crochet de validation SVN), puis d'exécuter automatiquement des tests fonctionnels sur le site de stockage après, puis, si les tests aboutissent, de déployer automatiquement vers le serveur de production.
Avec Capistrano, vous pouvez également facilement restaurer votre serveur de transfert ou de production à n’importe quelle version précédente, ainsi que pour automatiser d’autres tâches (par exemple, la sauvegarde du site ou d’autres tâches de maintenance).
Cependant, certains problèmes que j'ai rencontrés avec ce type d'installation sont que, pour simplifier les choses, j'ai dû utiliser un lien symbolique pour la racine Web du site en raison de la manière dont Capistrano stocke les révisions et conserve la trace de la révision active. Malheureusement, Apache met parfois les liens symboliques en mémoire cache. Vous devez donc procéder à des hacks laids (comme supprimer le lien symbolique, utilisez wget pour déclencher une erreur de serveur, puis recréez le lien symbolique) pour que les modifications soient immédiatement reflétées.
Si vous parvenez à remplacer le chemin de la version actuelle par la racine Web, le problème pourrait être résolu, mais vous devrez redémarrer le serveur Web à chaque fois (si vous en avez le droit accès). L'alternative consiste à utiliser .htaccess et mod_rewrite, ce qui pourrait être moins de travail.
- Je n'utiliserais jamais un serveur de développement séparé. De mon point de vue, cela ajoutera une complexité supplémentaire au déploiement sur serveur en direct. De plus, comme il s’agit de serveurs différents, le comportement peut changer après le déploiement en direct, créant un nouveau désastre.
- Bien sûr, je recommanderai fortement d'utiliser un système de contrôle de version. Ma préférence est "GIT", indépendamment de tout langage de programmation.
- J'imagine que vous utilisez un serveur VPS/dédié, de sorte que vous puissiez configurer vous-même le serveur de contrôle de version.
- J'ai de l'expérience dans l'utilisation du serveur de développement et la synchronisation avec les applications en ligne, c'est très simple et efficace. vous travaillerez toujours sur votre environnement local. Après son fonctionnement, engagez/envoyez à la branche de développement. testez-le sur un sous-domaine (comme dev.votredomaine.com, avec une authentification htaccess de base pour que Google ne l'explore pas). après avoir été testé correctement, il vous suffit de fusionner la branche de développement avec la branche principale (en direct) et Push, puis avec DONE!