Arriver au stade de "lancement" d'un projet peut être un énorme soulagement. Vous avez enfin terminé votre travail de développement en créant un site en fonction du mandat de votre client ou de vos propres besoins. Vous pouvez maintenant appuyer sur ce bouton métaphorique et lancer le site à la vue du monde entier..
Mais attendez.
Avant de lancer l'application, vous devez effectuer quelques vérifications pour vous assurer qu'elle est robuste et à l'épreuve du temps. En effectuant ces vérifications avant de lancer chaque nouveau site, vous éviterez des problèmes ultérieurement. Vous pouvez notamment éviter les maux de tête, la gêne et la dégradation de votre réputation causés par le fait que des clients ou des utilisateurs détectent des problèmes une fois le site mis en ligne..
Dans cet article, je vais partager la liste de contrôle que j'utilise avant de migrer un site pour vivre. Je ne prétends pas que c'est le Saint Graal des listes - vous aurez certaines choses que vous ne faites pas, que vous faites différemment ou que vous faites en plus de cela..
Il convient de noter que les vérifications préalables au lancement ne sont pas simplement pertinentes juste avant le lancement d'un site. En fonction de la complexité de votre projet, vous devrez en tenir compte au fur et à mesure. Cela vous permettra d'économiser du temps et des retouches lorsque le site sera prêt à être mis en ligne, et contribuera à la signature et à la crédibilité aux étapes du développement où votre client examine les travaux sur le site..
Cela dit, je pense que cela vaut la peine de donner une dernière analyse à cette liste avant le lancement, juste pour être sûr.
Ma liste est divisée en quatre catégories:
Contrôles spécifiques au projet ou au brief
La robustesse
Résistance future
Actions finales
Ci-dessous, je vais expliquer en quoi consiste chacune de ces choses et fournir une liste d’articles pour chaque catégorie..
1. Vérifications spécifiques au projet ou au brief
Assurez-vous que le site respecte le mandat convenu, vous devriez le faire depuis le début, mais cela vaut la peine de faire une dernière vérification avant le lancement..
Cette liste de contrôle sera différente pour chaque projet, je ne peux donc pas vous en donner une liste standard, mais vous pouvez utiliser certains indicateurs clés. Vous devez parcourir cette liste avant de migrer le site vers le serveur live:
Vérifiez le brief. Si le brief que vous avez convenu avec le client contient une liste de contrôle des caractéristiques ou des éléments du site, vérifiez que ceux-ci sont tous couverts et sinon, que vous en avez convenu avec le client..
Vérifier les problèmes ou les tâches. Si vous utilisez un système de suivi des problèmes ou des tâches (par exemple, des problèmes dans GitHub), vérifiez que tous les problèmes ont été résolus ou que les tâches ont été exécutées et qu'aucun problème ni bogue n'est en suspens..
Vérifier les modifications demandées. Vérifiez que toutes les modifications demandées au cours du développement (qui peuvent ne pas figurer dans le brief initial) ont bien été effectuées, à moins que celles-ci ne soient enregistrées pour le post-lancement.
Tester les processus sur site. Si le site comprend des processus ou des interactions que les utilisateurs devront exécuter, exécutez ces processus sur plusieurs navigateurs et périphériques pour vous assurer qu'ils fonctionnent conformément au résumé..
Ranger les utilisateurs. Si vous avez créé des connexions factices ou, par exemple, lié le site à une configuration PayPal du bac à sable, remplacez-les par les versions en direct (vous devrez peut-être vérifier à nouveau après la migration)..
Vérifiez les droits d'auteur et / ou crédits tels que les crédits photo.
Texte bien rangé. Si vous avez utilisé du texte de remplissage (tel que lorem ipsum), assurez-vous qu'il a été remplacé par un contenu plus approprié. Même une note informant les visiteurs que le contenu d'une page est en cours de développement est beaucoup plus utile et plus professionnelle que le texte lorem ipsum.
Tester les personnalisations de l'administrateur. Si vous avez personnalisé l'administrateur WordPress, vérifiez que cela fonctionne pour tous les rôles d'utilisateur que votre client utilisera..
Tester des services tiers. Si le site est intégré à des services tiers, vérifiez que tout fonctionne correctement et que le logiciel est à jour (vous devrez peut-être vérifier ceci à nouveau après la migration)..
Cette liste n’est pas exhaustive car votre projet peut comporter des éléments supplémentaires dont vous devez tenir compte, mais il vous fournira une base de travail..
2. Robustesse
La plupart des éléments de cette liste de contrôle s'appliqueront à tous les sites, mais il peut y avoir des variations pour différents projets, par exemple si un client vous demande de prendre en charge des périphériques spécifiques (bien que je préconise toujours une approche de développement indépendante du périphérique).
Parcourez la première partie de cette liste avant de migrer le site vers le serveur live:
Test du navigateur. Testez votre site dans tous les navigateurs que vous prenez en charge (ce que vous auriez dû convenir avec votre client). Vous devriez le faire au fur et à mesure et, idéalement, utiliser l’amélioration progressive, mais vous devez effectuer les dernières vérifications avant de commencer. Testez le contenu en utilisant chaque modèle de votre thème: publications uniques, pages, archives et types d'articles personnalisés..
Compatibilité des appareils. Testez votre site sur tous les appareils que vous prenez en charge. Encore une fois, vous auriez dû le faire pendant que vous travailliez sur le site et utilisiez un design réactif pour s'adapter à différentes tailles d'écran. Si votre site utilise des plug-ins ou des améliorations avec différents niveaux de support sur les appareils, vérifiez ce que les utilisateurs verront lorsqu'ils le verront sur ces appareils et mettre en place une alternative ou un lien vers un site auquel ils peuvent accéder, sinon indisponible..
Validez votre code en utilisant le validateur du W3C - encore une fois, vous devriez vraiment le faire au fur et à mesure. Si votre code ne valide pas, vous pouvez parfois décider de ne pas le modifier, par exemple si vous utilisez des fonctionnalités HTML5 qui ne valident pas. Si tel est le cas, assurez-vous que cela ne posera pas de problème pour les navigateurs qui ne prennent pas en charge les nouvelles fonctionnalités (en utilisant l'approche d'amélioration progressive déjà mentionnée)..
Vérifiez que votre site est accessible. Pour des conseils sur l'accessibilité dans WordPress, voir l'excellent guide d'accessibilité Web de Graham Armfield et les instructions du codex WordPress..
Après la migration de votre site sur le serveur live, vous devrez peut-être effectuer d'autres tests de robustesse:
Testez votre navigation et vos liens, en particulier les redirections.
Vérifier que la base de données est lue correctement et à partir du bon endroit - si votre site actif lit le contenu de votre base de développement, cela ne sera pas immédiatement visible si vous avez copié le contenu de la base de données, car les deux seront identiques. Vérifiez en particulier les liens dans les widgets de texte et les images.
Vérifiez l’intégration avec des logiciels et services tiers. Ceux-ci devraient tous communiquer avec votre site en direct, pas avec votre site de développement..
Vérifiez que les paramètres du site se réfèrent à l'URL en direct (par exemple l'URL du site et l'URL de WordPress).
Assurez-vous que les permaliens fonctionnent correctement pour tous les types de contenu. - vous devrez peut-être les configurer ou visiter l'écran des paramètres de Permalink pour les vider..
Utilisateurs. Testez votre site (front-end et admin) en utilisant tous les rôles d'utilisateur WordPress utilisés par votre client. Configurez tous les utilisateurs dont vous avez besoin.
3. Prévoir l'avenir du site
La troisième liste consiste à s'assurer que le site est prêt pour des développements et des ajouts futurs. Cela sera particulièrement important si vous remettez le site à votre client pour qu'il le gère et le mette à jour..
S'assurer que le référencement de base a été configuré. Les titres et les méta-descriptions doivent être intégrés à votre thème ou ajoutés à l'aide d'un plugin SEO. En fonction des besoins du projet, vous devrez peut-être passer du temps à configurer le plug-in pour répondre aux besoins de votre client. Autre vérification importante, mais facilement oubliée: si vous avez bloqué l’accès aux moteurs de recherche pendant le développement, supprimez le blocage au lancement, soit à l’aide des paramètres WordPress, soit avec un robots.txt fichier.
Faites une sauvegarde des fichiers et de la base de données au lancement.
Mettre en place un système de sauvegarde automatisé pour les fichiers de thème et de plugin et la base de données. La façon dont cela est géré et qui en est responsable dépendra de ce que vous avez convenu avec votre client et de la configuration de son hébergement. Il existe toute une gamme de plugins WordPress pour cela, y compris des plugins premium comme Backup Buddy ou des plugins gratuits comme WordPress Backup to Dropbox..
Configurer le site pour Google Analytics, soit en utilisant un plugin ou en ajoutant le code de suivi à votre thème.
Mettre en place un système de mise à jour du site. Cela n'inclut pas seulement WordPress, mais aussi des thèmes et des plugins. Que vous le fassiez, le client ou son hébergeur s'en charge, cela dépendra de ce que vous avez convenu avec votre client. Vous devrez peut-être accepter un contrat de maintenance de site spécifique pour cette opération..
Convenez d'un calendrier pour les revues de site. Une fois lancé, un site Web ne devrait pas être laissé seul. Décidez avec votre client de la fréquence à laquelle vous examinerez la performance et l'efficacité du site et assurez-vous de rester en contact avec votre client pour qu'il vienne vous voir quand il a besoin de travail de développement supplémentaire..
4. Actions finales
La quatrième et dernière partie de ma liste de contrôle est très courte et complète le processus de lancement..
Revisitez les contrôles ci-dessus si nécessaire. Si vous avez apporté des modifications après l'une de vos vérifications (par exemple, si vous avez modifié le thème après avoir trouvé du code qui n'a pas été validé), recommencez la vérification qui a demandé la modification et toutes les vérifications que vous avez effectuées auparavant et dont les résultats peuvent avoir été affectés. . Par exemple, votre nouveau code validé fonctionne-t-il sur tous les appareils ou tous les navigateurs??
Approbation. S'il y a des changements importants à la suite de vos vérifications, vous devrez peut-être obtenir à nouveau l'approbation du client..
Communiquer. Assurez-vous que votre client et les autres parties prenantes sachent que le site est en ligne. S'il s'agit de votre propre site ou si votre client vous a demandé de le publier, utilisez des médias sociaux, des blogs ou d'autres canaux. Ajoutez-le à votre portefeuille si vous en êtes fier!
Être payé. N'oubliez pas d'envoyer une facture à votre client pour la phase de lancement du projet.
Résumé
Comme je l'ai mentionné plus tôt dans cet article, cette liste ne vise pas à être la liste définitive pour tous les développeurs WordPress, mais elle est utile à quiconque cherche à introduire une certaine cohérence dans son processus de migration de site..
Prenez cette liste et modifiez-la pour qu'elle fonctionne bien pour votre façon de travailler et vos projets, ajoutez-la, changez-la et supprimez tout ce qui ne vous concerne pas. Mais si vous utilisez ceci pour développer votre propre liste de contrôle à laquelle vous vous référez à chaque fois, vous pouvez être sûr que vous ne manquerez rien d’important et que tous les problèmes seront repérés par vous avant la mise en ligne du site, et non par vos clients. les utilisateurs après.
Share
Accentsconagua
