Gestion d'un environnement de développement par opposition à une application Web?

Question

J'ai fini de développer le noyau d'une application web sur laquelle j'ai travaillé. Depuis que j'étais le seul développeur que je viens de développer localement (pile de lampe) sans utiliser le contrôle de version (probablement stupide mais de toute façon ..). Maintenant que la production approche, j'ai quelques autres développeurs qui travaillent avec moi, donc j'ai mis en place un référentiel pour mon code.

Voici ma question: je veux tout d'abord pouvoir tester les modifications localement avant de les mettre en production. Comment gérer cela avec un dépôt sans avoir à gérer 2 versions de mon code (que je dois synchroniser manuellement)? Pour un, le code de production a quelques différences ici (telles que les constantes de base de données, etc.). J'aimerais pouvoir changer mon code dans mon dépôt local, le tester sur mon serveur apache local, puis vérifier directement le code dans la production (est-ce même possible en utilisant eclipse)? J'utilise eclipse et subversion (code php). Je sais que j'ai posé beaucoup de questions mais j'espère que vous aurez l'idée de ce que j'essaie de faire ... et je suppose que c'est plutôt commun. Merci.

Answer 1

je suggère quelques choses

1. Utiliser les tags/branches dans SVN. Lorsque le code est prêt pour la production, attribuez-lui un nom unique.
2. Configurer une zone de transit pour les tests d'intégration. Une fois qu'une version est étiquetée pour la mise en scène, arrachez-la de vos ordinateurs et copiez-la dans la zone de transit. Cela peut être aussi simple qu'une arborescence de répertoires différente ou une deuxième installation de votre serveur.
3. Mettez les constantes dans des fichiers distincts qui peuvent être copiés/fusionnés dans les répertoires de transfert et de transfert
4. Testez la version intermédiaire par rapport à dev pour vous assurer que tout fonctionne comme dans votre environnement de développement. Je signalerais la mise en scène aux bases de données de production quand je suis sûr que cela fonctionne et prêt à être promu. Test que cela fonctionne aussi contre prod.
5. Une fois que tout fonctionne dans le transfert, mettez à jour la copie de production. Je vous suggère de créer un répertoire de déploiement propre, puis de copier l'ensemble du déploiement sur le serveur de production après avoir copié/fusionné les paramètres de configuration.

C'était mon approche traite avec perl/cgi il y a plusieurs années et cela a plutôt bien fonctionné. SVN gère beaucoup mieux les tags/embranchements, donc il devrait être plus facile à gérer. Nous avons eu très peu de problèmes de production une fois que nous avons commencé à mettre en scène les fichiers avant de pousser à produire.

Answer 2

Il semblerait que vous n'ayez pas créé de branches ou de balises et que vous ayez probablement une «ligne réseau» qui n'est pas étiquetée comme telle. Les bonnes pratiques exigent que vous disposiez d'une jonction pour le code stable actuel, les branches que vous développez et les balises réellement utilisées sur le site de production. Il y a un short description and diagram on Wikipedia.

Bien sûr, c'est juste la meilleure pratique. Votre projet semble assez petit pour que vous puissiez vous en séparer en divisant votre code en un répertoire développement/et un répertoire production/dans votre référentiel de code. Checkin code dans le répertoire de développement, et une fois qu'une modification est entièrement testée, fusionnez-la dans le répertoire de production.

Que vous le fassiez de la bonne façon ou de la manière la plus simple, il est important de faire quelque chose pour séparer votre code de développement de votre code de production. Au fur et à mesure que vous ajoutez d'autres développeurs, il est de plus en plus improbable que la base du code de développement soit stable car les utilisateurs vérifient le code qui n'a pas été entièrement testé, n'est pas complet, ou autre. Passer un peu de temps sur la gestion de deux branches de code vous permettra d'économiser beaucoup de maux de tête plus tard.

Answer 3

En plus des excellentes réponses que vous avez déjà obtenues, je voudrais souligner que s'il y a des différences entre votre code de développement et de production , vous ajoutez le risque. Vous devriez utiliser le même code bien testé dans les deux endroits; Toute différence entre les environnements doit être exprimée dans les fichiers de configuration. Tous les fichiers de configuration dans le contrôle de source doivent être uniquement des exemples; votre script de déploiement ne doit pas envoyer de nouveaux fichiers de configuration en production. Ceci, en combinaison avec les versions balisées et un environnement intermédiaire imitant la production, devrait vous aider à promouvoir votre code en douceur dans l'environnement de production.