Est-ce mauvais de développer contre des données de production?
J'ai toujours entendu dire que le développement des données par rapport à la production est une mauvaise pratique et que je suis en train de passer à un modèle Développement> Production , principalement parce que j'ai un nouvel employé ayant des compétences minimales et Je préférerais qu'il ne travaille pas encore directement avec les données de production.
Mais pendant longtemps, j'ai travaillé directement avec les données de production avec un minimum de maux de tête, à l'exception peut-être de quelques erreurs qui se glissaient ici ou là, telles que des problèmes d'orthographe, un mauvais texte alternatif, des liens pointant vers le mauvais emplacement. Cela semble être dû à un manque de contrôle par les pairs de ma part, et non à un travail avec des données en direct.
Alors, pourquoi le développement sur le site live est-il une si mauvaise pratique?
Si, au cours du développement, vous exécutez des commandes SQL incluant INSERT ou UPDATE sur des tables de base de données existantes, vous courez un risque dans la mesure où ces tables sont critiques.
Certains emplacements synchronisent les données de production dans la base de développement à intervalles réguliers, par exemple une fois par semaine ou à la demande du développeur, afin de vous permettre de développer de nouvelles données.
Mais si vos données de production ne sont pas menacées par ce que vous faites, par exemple, si vous développiez simplement une vue de certaines données, ce n'est généralement pas grave. Maintenant, si vous exécutez des rapports qui effectuent des analyses de table, vous avez le potentiel de verrouiller une table, vos utilisateurs existants sont alors affectés.
Dans de tels cas, je m'en remettrais à mon administrateur de base de données. S'il n'y avait pas d'administrateur de base de données "officiel", je ferais preuve de prudence. C'est assez simple pour créer une base de données de développement, même pour moi. En équipe, c'est vital. À défaut, si vous insistez pour ne posséder qu'une base de données, vous pouvez préfixer vos tables de base de développement avec DEV_ et vous sentir un peu mieux. Oui, cela nécessite quelques modifications de code, mais en développement, l'ajout de variables au cours du développement $debug = true, etc. en vaut généralement la peine.
Beaucoup de façons d'aborder cela. Cela dépend beaucoup de votre situation.
Vous ne souhaitez PAS développer les données de production sur votre serveur de production. Il y a deux ou trois raisons majeures.
- Le développement ralentit votre production et crée des vulnérabilités. Que se passe-t-il si vous laissez votre ordinateur déverrouillé et vous éloignez?
- Si vous faites une erreur, les personnes qui visitent votre site peuvent la voir.
- Si vous effectuez tout type de mise à jour de données dans une transaction de votre base de données sans la valider immédiatement ou si la transaction prend un certain temps, vous verrouillez toutes les tables concernées et vous risquez de provoquer un dépassement du délai d'attente. .
- Certains systèmes de base de données, en particulier SQL Server, effectuent parfois des verrous de table uniquement sur les instructions SELECT! Cela signifie que vous pouvez involontairement donner aux utilisateurs des délais ou des pages d'erreur sur votre site.
Je ne ferais jamais de travail de développement sur un live box si possible. Votre meilleur choix est de faire une sauvegarde de la base de données et des pages et de travailler avec la copie, puis d'envoyer vos mises à jour. Un outil qui m'a beaucoup aidé est le SyncToy de Msft.
Eh bien, vous pouvez vraiment gâcher les données. Imaginez laisser une clause where. Même si vous avez des sauvegardes toutes les heures, ce serait difficile à réparer.
Si vous disposez de données de production, il est raisonnable de les utiliser pour les tests, mais utilisez une base de données de tests séparée avec une copie de ces données. Sinon, beaucoup de choses fonctionneront pour vos quelques enregistrements de test "blabla" mais pas pour un scénario réel.
Et pour avoir développé des données de production réelles - rappelez-vous les lois de Murphy "Tout ce qui peut mal tourner ira mal.", Et il est si facile de faire une petite erreur avec des conséquences graves et néfastes.
Si vous ne conduisez pas sans ceinture de sécurité, ne développez pas vos données de production. Juste un problème de sécurité.