Développement, test et publication

Comment développez-vous, testez-vous et déployez-vous pour vivre vos sites Wordpress?

C'est toujours un peu un problème que je trouve, surtout en ce qui concerne les bases de données - principalement parce que le fait d'avoir un site de test nécessite le déploiement d'une toute nouvelle base de données qui peut parfois être exactement la même, sauf que tous les liens sont modifiés en tester l'URL du site, au lieu du site en direct.

De même, tous les téléchargements que les utilisateurs ont téléchargés depuis la dernière fois que vous avez eu besoin de corriger un bogue ou de développer quelque chose de nouveau devront être copiés sur le site de test.

Comment font les autres? Vous venez de supporter le faff? Utilisez-vous des systèmes de contrôle de version intelligents qui vous aident?

Merci

testing

— Thomas Clayson
source

Si vous faites en sorte qu'un système tourne autour de la modification de votre fichier d'hôtes , vous n'avez jamais besoin de foutre en revue votre base de données de test. ( wordpress.stackexchange.com/a/10943/9142 )

— Alexander Bird

Il y a un peu de philosophie personnelle qui entre dans un flux de travail de déploiement. Ce n'est pas une question facile de répondre sans connaître votre expérience avec les serveurs et le contrôle de version, votre système d'exploitation, l'hébergement, l'expérience client et la culture technique, etc ...

Voici une question similaire qui a beaucoup d'explications.
Pour le déploiement de contenu, vous pouvez consulter le plug-in RAMP de Crowd Favorite .
WP Hackers est un excellent sujet pour trouver de bonnes informations sur les déploiements.

Personnellement, je m'assure de ne jamais coder en dur des URL absolues dans mes thèmes. Utilisez bloginfo () ou codez des URL relatives. J'utilise beaucoup de conditions dans mon fichier wp-config.php. Voici une version vanille de mes modifications wp-config.

switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

Je travaille sur de nombreux sites qui suivent

local (piratage personnel :) sur le serveur Web de mon ordinateur portable)>
dev (test sur serveur client)>
étape (source stable pour QA - édition de contenu)>
production (site en direct)

Enfin, je vous suggère d'utiliser un outil de versioning pour vous aider dans vos déploiements tels que GIT ou SVN. Il facilite considérablement le processus et maintient l'intégrité de la source entre les environnements. S'engager dans votre section locale est facilement mis à jour via la ligne de commande sur scène et en production. Lors de la découverte, il est préférable de définir le contrôle de version que vous et le client utiliserez dès le départ si des développeurs travaillent sur le projet. J'utilise personnellement GIT pour mon contrôle de version. Cependant, si un client utilise SVN, je fais un mélange des deux sur mon local donc je maintiens un repo pour moi tout en m'engageant à leur repo.

Nous avons rarement des problèmes de migration d'un environnement à un autre. Nous faisons une recherche / remplacement dans la base de données pour changer l'URL en conséquence pour les médias intégrés, etc ...

— Brian Fegter
source

C'est très utile! :) Merci beaucoup. Donc, chaque fois que vous déployez sur chacun des différents serveurs, dupliquez-vous la base de données du site en ligne? Vous dites que vous déployez sur un serveur intermédiaire (stage.domain.com) pour le contrôle qualité et l'édition de contenu. Que se passe-t-il si la base de données change pendant que vous exécutez le serveur de scène sur le site en ligne? c'est-à-dire que vous ou votre client vous connectez à l'étape et mettez à jour du contenu, mais en même temps, un contributeur publie un nouvel article sur le site en direct? Effectuez-vous à nouveau les modifications de contenu sur le site en ligne? Comment abordez-vous les changements de structure de base de données?

— Thomas Clayson

Désolé pour toutes les questions! : p Je vous suis très reconnaissant de votre temps et de votre aide.

— Thomas Clayson

Sur un nouvel ensemble de fonctionnalités, vous pouvez tirer de prod> stage. Ajoutez le contenu de la nouvelle fonctionnalité, puis repoussez l'étape> prod. À partir de là, stage est une copie haute fidélité de prod et vous pouvez tirer stage> dev. Ce n'est pas souvent que nous retirons la DB de la scène. La majorité des échanges avec la base de données ont lieu de l'étape au prod, à moins qu'une fonctionnalité ne modifie l'architecture de la base de données.

— Brian Fegter

Si vous souhaitez utiliser l'étape pour le déploiement de contenu et ne jamais toucher à la prod, vous pouvez consulter le plug-in RAMP que j'ai publié plus tôt.

— Brian Fegter

+1 à tout ce qui précède, à condition que certains plugins irritants insistent pour stocker des URL dans des tableaux sérialisés, ce qui peut perturber le déplacement des choses d'une base de données d'env à une autre. Le problème est que les tableaux sérialisés stockent des longueurs de chaîne et sont borken lorsque la longueur change. Ainsi, je recommanderais de garder les noms de domaine de l'env les mêmes si possible, par exemple dev.example.com, tst.example.com, www.example.com etc.

— Webaware