stratégies de déploiement, PHP + SVN

Question

Je veux juste discuter de notre stratégie de déploiement et y trouver des divergences. le processus va comme ceci

-> Développement se termine pour une version particulière

-> Tous les développeurs engagent leurs fichiers au tronc

-> Comparer les schémas de base de données à l'aide de TOAD et migrez les changements

- > Créer une nouvelle branche sur SVN

-> Exporter à l'aide SVN (pour supprimer le dossier svn, etc.)

-> mi nify JS, CSS

-> télécharger vers le serveur de mise en scène

-> effectuer le cycle de test

-> corriger les bugs sur la branche et les vérifier

-> re-rapetisser la JS, CSS [si nécessaire]

-> télécharger vers le serveur de production

-> quand je dis le téléchargement, cela signifie que le téléchargement de fichiers par SSH pour /var/www/html dossier

-> première js upload, css, images

-> puis télécharger les fichiers php

-> pendant le téléchargement exclure des répertoires comme utilisateur téléchargés images, etc.

-> effectuer le cycle de test

-> corriger les bugs et télécharger à nouveau (peut avoir besoin re-rapetisser - quelques fichiers)

-> garantissez bogues

-> vérification complète

-> commit branche svn

-> fusionner les modifications dans le tronc

-> commit tronc [au cours de ce cycle de déploiement, personne n'engage tous les fichiers à le tronc]

le processus est vraiment compliqué et nécessite beaucoup d'attention.

des suggestions sur la façon dont nous pouvons l'améliorer?

Answer 1

J'ai utilisé le chemin de déploiement suivant. Il supprime beaucoup de vos besoins pour re-télécharger des fichiers dans différents répertoires. Après la configuration initiale, le travail le plus compliqué que vous aurez à faire est de lancer des commandes "svn update" dans chacun de vos emplacements de test. Cette configuration suppose que vous utilisez des fichiers de configuration pour pointer vers des répertoires tels que les ressources, les images et le CSS.

1. Init le référentiel. Ayez toujours un utilisateur unique pour les vérifications de production et de test. Cela permet des commits uniques du serveur de retour au tronc en cas d'urgence.
2. Les développeurs développent et s'engagent. Les builds sont marqués avec le numéro de build, ainsi qu'un tag pour LIVE lorsqu'ils sont supposés être prêts pour le projet.
3. La vérification est effectuée sur le serveur de test. Si tout va bien. # dev.example.com/~ test/project/
4. svn mise à jour vers un répertoire de test sur le serveur de production. # example.com/~ test/project
5. svn mettez à jour votre répertoire de projet principal sur le serveur de production vers le tag LIVE. # Example.com
6. Si vous avez des exceptions dans les étapes 3 à 5, revenez à l'étape 2.

Tous les projets ont un fichier de configuration, qui permet de définir les chemins aux bases de données de développement, des images partagées, etc. .config.dist.php fonctionne bien comme un schéma de nommage. Chaque extraction copie ensuite config.dist.php à config.php. Cela permet de nombreuses configs sans collisions SVN.

Chaque fichier de configuration a généralement un certain code tel que

<?php 
    #hopefully, your project can leave these first two constants set to '', because relative paths work for everything 
     define('localPath', '/home/www/projectName'); 
     define('baseURL', 'http://example.com/~projectName'); 

    #if you want to write everything over a shared filesystem for instance, uploads. 
     define('localAssetsDirectory', '/sharedFileSystem/localPath'); 

    #if you want to include a shared assets directory 
     define('assetsURL', 'assets/images'); 

    #OR if you want to host assets in one location. 
     define('assetsURL', 'http://assets.example.com/images/'  
?> 

Toutes les versions de test sur la production et le serveur de dev ne sont accessibles par ips restreints, ainsi que de mettre derrière un fichier .htaccess. Apache est configuré pour ne pas utiliser les répertoires .svn.

Answer 2

si vous utilisez des tests unitaires (par exemple, Sélénium), vous pouvez utiliser un outil de construction de scénario tout cela

sinon, je voudrais juste scénario les étapes suivantes:

• Exporter à l'aide SVN (retirer .dossier svn, etc.)
• rapetisser la JS, CSS
• téléchargement vers le serveur mettant en scène

et

• re-rapetisser la JS, CSS [si nécessaire]
• télécharger à la production serveur
• lorsque je dis que le téléchargement, cela signifie le téléchargement de fichiers via SSH dans le dossier/var/www/html
• d'abord uploa d js, css, images
• puis télécharger les fichiers php
• pendant le téléchargement ne comprennent pas les répertoires comme utilisateur téléchargés images, etc.

puisque vous déjà branchement et la fusion, vous devez garder votre coffre devrait toujours être une construction stable avec les dernières fonctionnalités. enfin, TAG vos communiqués