Version imprimable
Bonjour à tous,
Je me pose la question de savoir comment vous mettez à jour la base de données d'un projet déjà en production ?
- Dans un process à part que vous lancez avant / en même temps que le changement de code ?
- Dans votre PHP mais dans ce cas, comment faites vous pour savoir si la BD a déjà été mise à jour ou pas ?
- Autrement ?
Merci d'avance pour vos réponses.
Laurent
Bonjour...
Je ne suis pas sûre de bien comprendre ta question, mais je vais te raconter ce que j'ai déjà fait... avec 2 grands cas de figure pour schématiser.
1) Reprise de données définitive
Il existe une vieille appli avec une vieille base dédiée...
Je dois tout refondre...
Je commence par faire la reprise de données en db, donc tout SQL, puis je développe l'appli, puis quand j'ai fini l'appli, je fais la reprise de données une dernière fois, et hop, on lance en prod, on fait la bascule... et on oublie appli et base ancienne.
2) Cas du réplicat partiel :
J'ai des bases mères (énormes) qui restent en prod, et j'ai une appli et une base dédiée qui reprend les données partielles pour alimenter mon appli. Dans ce cas, très très souvent, la MOA est contente si les données ont moins de 24H de fraîcheur. Alors je fais un cron la nuit, cron qui lance une page PHP, et qui reprend toutes les données qui m'intéressent et alimente ma base locale, un cron bavard qui me raconte ce qu'il fait dans les logs. Et quand il a terminé, il vient enfin inscrire dans une dernière table (maj_db) toutes les tables qu'il a mises à jour, et l'heure... Ce qui me permet dans l'appli d'afficher sur toutes les pages un truc dans ce goût : Dernière mise à jour 16/07/2018 02:11:56. Enfin, le cron m'envoie un mail (à moi ou à l'administrateur) pour dire "16/07/2018 02:11:56 Cron nom_de_mon_appli s'est bien déroulé".
Ainsi ma base locale ne pèse pas sur les grosses bases pendant toute la journée.
Tout doit se faire en même temps, sinon l'appli tombe.
Il faut un process minimum :
Dev -> staging -> Prod
Tu développes tes modifcations, tu passes en staging et quand tout est ok tu mets en prod.
Je propose un 3e cas à ceux présentés par Dendrite : celui de l'évolution de l'application.
En production on a la version 1. Des développements ont été faits, avec notamment des modifications de la structure de la base, et on doit mettre en production la version 2, sans perdre les données déjà en base bien sûr.
La procédure idéale serait :
- Arrêter l'application.
- Passer le script de modification de la base de données, qui contient toutes les modifications entre la version 1 et la version 2
- Déployer la nouvelle version du code PHP.
- Relancer l'application.
Évidemment, on a d'abord fait une copie de sauvegarde de la base de données et du code de la version 1, au cas où il faudrait faire un retour arrière en urgence, et idéalement, on a fait une répétition générale sur une copie du serveur de production, histoire d'éliminer les éventuels bugs.
Une façon de savoir si le code et la base sont en phases, c'est d'avoir quelque part de chaque côté un numéro de version de façon à pouvoir les comparer pour vérifier que les deux moitiés sont à la même version. ;)
Merci à vous 3.
Le cas que j'évoquais était celui de Celira.
Mais donc si je comprends bien, vous n'incluez pas la mise à jour de la base de données dans votre PHP (par exemple dans un constructeur de classe) ?
Euh... non ? Les scripts PHP utilisent la base, ils ne la créent pas. (*) Donc on construit/modifie la base avant de lancer la nouvelle version des scripts. Il peut aussi y avoir une initialisation de tables, par exemple pour une table de paramétrage à initialiser avec des données par défaut.
Sans compter les cas alakon (également connus sous le nom d'applications de la Loi de Murphy). Exemples :
"on s'est rendu compte en cours de route qu'on avait des données redondantes, donc on a déplacé la colonne d'une table à l'autre, mais il faut agréger les données de l'ancienne colonne dans la nouvelle colonne pour ne pas perdre d'informations"
"avant cet identifiant était un nombre, mais là on dépasse les valeurs prévues et plutôt que d'incrémenter, on a décidé de mettre une lettre en préfixe, il faut passer la colonne de Integer à Varchar"
"le statut était un nombre entre 1 et 20, mais là il faut un statut supplémentaire à mettre entre 15 et 16, du coup il faut tout décaler"
(*) Sauf éventuellement si on utilise un ORM type Doctrine avec une configuration qui construit les tables à partir des entités. Et même dans ce cas, lorsqu'on a une base existante et des modifications à effectuer, je ne suis pas sûre du fonctionnement en cas de base existante.
D'après mon expérience sur Hibernate en Java, il vaut mieux écrire les scripts SQL (quitte à les exporter à partir des tables générées par l'ORM) et les passer à la main.
En fait cela dépend du contexte et des outils utilisé, si tu utilises Laravel, alors il y a un mécanismse de création, modifcation de table, avec rollback et remplissage de la db.Citation:
Envoyé par LauBelette
Cela permet de travailler en équipe, de versionner le tout.
Mais même avec un système pareil, tu n’échapperas aux tests de régression.
Le cas de @Celira cité ci-dessus, sera réalisable via des scripts, mais au prix d'un certain effort, donc à toi de voir la meilleur façon de travailler.
Maintenant si tu dois multiplier l'installation de ton application, comme par exemple si tu crées le nouveau WordPress ou Drupal, alors là tout en script a vraiment son intérêt.