Vous avez besoin d’ajouter une page ou d’ajouter un article sur votre site, pas de soucis, vous pouvez le faire en direct sur le site que vous affichez aux internautes (site de production). Vous allez pouvoir créer votre page ou votre article tranquillement , en prenant le temps nécessaire , sur plusieurs jours éventuellement , le prévisualiser avant de le mettre en production , le corriger , et une fois que l’article ou la page vous convient , vous cliquez sur « Publier« . Vous pourrez facilement le corriger si un défaut survient après publication.
Mais quand il s’agit d’ajouter une nouvelle fonctionnalité sur votre site, par exemple l’affichage d’un planning de réservations, la gestion d’offres d’emploi, modifier le workflow de plusieurs formulaires, un portefeuille de produits … alors NE LE FAÎTES PAS DIRECTEMENT sur le site de production !
Utiliser un site de tests
Il faut effectivement utiliser un site de tests, sur lequel vous allez pouvoir faire tout ce que vous voulez, sans craindre de décevoir les internautes qui utilisent votre site de production par un fonctionnement « intermédiaire » avant finalisation, sans risquer de « planter » votre site de production, sans être certain que la nouvelle fonctionnalité répond bien à votre cahier des charges et aux exigences de vos clients.
Une architecture à "3 têtes"
Dans le début de cet article, j’ai abordé les termes « site de production », ‘site de tests ». Il faut parler d’un autre site nécessaire et souvent négligé : le site de développement. Pour ma part, c’est ce que j’utilise dans mon environnement et l’environnement que je propose à mes clients. Un schéma vaut mieux qu’un long discours !
Serveur de production
Le serveur sur lequel vous placez votre site de production , consulté par les internautes, votre client … Ce site de production est mis à jour depuis le site de développement. Aucune modification de structure, de fonctionnalités n’y sont effectuées directement.
Serveur de tests
Le serveur sur lequel vous (en tant que client) testez de nouvelles fonctionnalités que vous voulez mettre en place, qui sont réalises par vos soins ou par notre agence web. Les internautes n’y ont pas accès, ce site n’est pas indexé par Google (et autres moteurs), et est accessible par identifiant/mot de passe.
Lorsque vous avec validé une évolution, celle ci est répliquée sur le serveur de production.
Serveur de développement
Le serveur sur lequel nous développons les sites web, testons en première version les mises à jour, les évolutions mineures et majeures de votre site.
Nous mettons à jour le site de tests à partir de ce serveur de développement, ainsi que le serveur de production après validation d’une évolution sur le serveur de tests.
Les mises à jour de ces "3 têtes"
Nous avons créé des scripts linux qui permettent de mettre à jour les données (fichiers et base de données) entre ces 3 serveurs.
Lors d’une évolution à étudier, d’une mise à jour à réaliser, nous mettons à jour le(s) serveur(s) de développement (il peut il y avoir plusieurs postes de développement), avec les données du serveur de production pour nous placer à l’identique de la production avant d’entamer une évolution.
Nous pouvons ensuite développer l’évolution du site internet, la tester en local sans perturber les serveurs de tests et de production.
pascal@developpement1:/home/apache/www.aim82.fr$ ./miseajour.sh
Quel système voulez-vous mettre à jour:
- DEV depuis la PRODUCTION: 1
- DEV depuis le TEST: 2
- le TEST: 3
- la PRODUCTION: 4 ? 1
Quel traitement voulez-vous faire sur DEV:
- Mettre à jour les fichiers: 1
- Mettre à jour la Base de données: 2
- Mettre à jour les fichiers et la bdd: 3
- Visualiser les fichiers fifférents: [4] ? 3
... début du traitement avec les paramètres --go ...
Debut de traitement:
------------------------------
Récupération des éléments du serveur:
(les paramètres d'accès au serveur sont affichés ici)
...
------------------------------
(les paramètres du serveur de développement sont affichés ici)
...
------------------------------
Paramètres:
CMS=WORDPRESS
WITHDELETE=OUI
WITHSVN=
WITHEVENT=NON
UPDATEOPTIONS=NON
ALLTABLES=OUI
ReplaceDomain=OUI
confirmer ce traitement [o/n] ?
Nous pouvons ensuite développer l’évolution du site internet, la tester en local sans perturber les serveurs de tests et de production.
Lorsque l’évolution a été développée sur le serveur de développement, nous mettons à jour le serveur de tests avec les fichiers modifiés ainsi que la base de données si elle a été touchée par l’évolution.
pascal@developpement1:/home/apache/www.aim82.fr$ ./miseajour.sh
Quel système voulez-vous mettre à jour:
- DEV depuis la PRODUCTION: 1
- DEV depuis le TEST: 2
- le TEST: 3
- la PRODUCTION: 4 ? 3
Quel traitement voulez-vous faire sur DEV:
- Mettre à jour les fichiers: 1
- Mettre à jour la Base de données: 2
- Mettre à jour les fichiers et la bdd: 3
- Visualiser les fichiers fifférents: [4] ? 3
... début du traitement avec les paramètres --go ...
Les tests peuvent alors être effectués par le Client sur le serveur de tests.
Lorsque l’évolution a été testée et validée sur le serveur de tests, nous mettons à jour le serveur de production après accord du client.
pascal@developpement1:/home/apache/www.aim82.fr$ ./miseajour.sh
Quel système voulez-vous mettre à jour:
- DEV depuis la PRODUCTION: 1
- DEV depuis le TEST: 2
- le TEST: 3
- la PRODUCTION: 4 ? 4
Quel traitement voulez-vous faire sur DEV:
- Mettre à jour les fichiers: 1
- Mettre à jour la Base de données: 2
- Mettre à jour les fichiers et la bdd: 3
- Visualiser les fichiers fifférents: [4] ? 3
... début du traitement avec les paramètres --go ...
Il peut il y avoir des variations à ce workflow : par exemple si le Client souhaite mettre à jour les données relatives à l’évolution ajoutée, nous lui laissons mettre à jour les données sur le serveur de tests, puis nous récupérons toutes les données saisies en local sur notre serveur de développement, et nous mettons à jour ensuite les fichiers et la base de données du site de production.
Le Client n’a pas à se préoccuper de toutes ces mises à jour, la sécurité du système est assurée, et c’est ce qui compte pour lui au final. Il sait qu’il peut faire ce qu’il veut sur le site de tests, et ensuite nous demander de mettre à jour le site de production avec les tests qu’il a effectué.
