Concept plugin Projets de sites

Teddy Payet — 2013-11-25T13:18:46Z

Il existe sur la zone un plugin "Projets" créés par Eric et repris par Cyril. Comme son nom l'indique, ce plugin permet de gérer des projets. On y trouve l'essentiel dans ce cadre. Dans un contexte "agence web", j'ai créé le plugin "Projets - Sites Internet".

Présentation

Forcément, quand on est dans une agence web, on réalise... Des sites internet. La bonne méthode dans le monde du web, est de créer 3 types/statuts de site : en production, en recettes, en développement.
Vous pouvez comprendre facilement le concept de ces statuts :
– en développement : et bien, c'est là où l'équipe de développeurs et d'intégrateurs vont ajouter des nouvelles fonctions, tester le nouveau design, etc.
– en recettes : c'est le site sur lequel le client va tester les développements qui ont été réalisé par l'agence. Et après son aval, on migre les fichiers modifiés vers le site en production ;
– en production : le site final auquel les visiteurs ont accès.

Entre autres de ces statuts, pour certaines agences, on pourrait avoir un 4ème statut : pre-prod. C'est la copie conforme du site de production (base de données, contenu éditorial, configuration du serveur, etc.) où on va tester que les fonctions développées sur le site de recette/développement passent correctement dans l'environnement final.

Non non, je ne suis pas parano. Il arrive parfois que les serveurs de dév, de recettes et de prod ne sont pas du tout configurés de la même façon. Cela pour des questions de sécurité de l'infrastructure. Pour schématiser, plus on va vers la version de production, moins de "port" sont ouverts ou moins d'extensions sont activées. Performance et sécurité donc.

Ce qu'on peut renseigner

Pour chaque fiche de site, grâce à ce plugin, nous pouvons renseigner les éléments suivants :

Le nom du logiciel/CMS utilisé (malheureusement tous les sites ne sont pas fait sous SPIP) ;
La version de ce logiciel ;
Le type de site : c'est le statut. J'ai choisi "type" à la place de statut pour ne pas faire doublon avec le statut classique de SPIP ;
date de création ;
Le front office :
- L'URL du front ;
- Le login ;
- Le mot de passe ;
Le back office (le même type d'info que le FO) :
- L'URL ;
- Le login ;
- Le mot de passe ;
  -* Le nom serveur applicatif : le nom du serveur ;
L'URL du site sur ce serveur ;
Surveillance applicative : en gros le logiciel de Monitoring de votre site ;
SVN (Subversion) :
- L'URL pour récupérer les fichiers. Exemple : svn://zone.spip.org/spip-zone/_plugins_/projets_sites/trunk ;
- L'URL pour voir les révisions de vos fichiers. Exemple : http://zone.spip.org/trac/spip-zone/browser/_plugins_/projets_sites/trunk/ ;
SAS DPI : parfois, on a un service DPI (Direction de la production informatique) à qui l'on doit remettre les fichiers à déposer sur le serveur de production.
S.G.B.D. :
- Le type de base de données : MySQL, MongoDB, etc.
- Le nom du serveur ;
- L'URL du serveur ;
- Le login ;
- Le mot de passe ;
SSO : la méthode d'identification ;
Le périmètre d'accès : internet ? Intranet ? Extranet ? etc.
Le logiciel de statistiques : Webtrend, Google Analytics, etc.
Le moteur de recherche : Moteur interne au logiciel ou solution tierce ;
Autres outils ;
Des remarques ;
et enfin la date de création de ce site.

Comem vous pouvez le voir, il y a pas mal d'éléments que nous pouvons renseigner sur une fiche. On n'est pas obligé de renseigner tout pour chaque type de site.

"Oui... Mais"

Vous pourriez me dire, à quoi bon avoir cela lorsqu'on peut le faire dans un fichier word ou excel. Et bien, c'est plus simple d'avoir sur un site de gestion de ressources du service ce genre d'informations pour que les nouveaux membres d'une équipe puisse les retrouver aisément au lieu de chercher une aiguille dans une botte de foin sur le réseau.

Aller plus loin

Cette fois-ci, c'est moi qui dirait "Oui, mais" on peut aller plus loin avec cela.
En effet, il est arrivé à bon nombre de développeurs de faire une fausse manip sur un des serveurs en pensant être sur le site de développement et en fait être sur le site de recettes...
On peut imaginer un service tout simple qui identifiera le type de serveur sur lequel nous nous trouvons. On aura une belle pastille "Site de recettes", "Site de dév".
Il suffirait d'interroger le site référent (où est installé le plugin Projets Sites) pour savoir sur quelle type de site on se trouve. Exemple : http://gestion.example.com/?page=type_site&url=http://dev.example.org et cela nous retourne un json avec le statut.
On peut aussi avoir toutes les infos dudit site qui ont été renseigné.

Sur une page accessible qu'au webmestre du site, on pourrait avoir un comparatif des valeurs de la fiche et ce qui est en fonction des GLOBALS du site : le nom de la BDD, le nom du serveur, etc.

C'est un outil simple de "monitoring" de votre site.