Est-il mauvais de développer contre les données de production?

J'ai toujours entendu dire que c'est une mauvaise pratique de développer contre les données de production et je suis actuellement en train de passer à un modèle Dev> Stage> Production , principalement parce que j'ai un nouvel employé avec des compétences minimales et je préfère ne pas l'avoir travailler directement avec les données de production pour le moment.

Mais depuis longtemps, je travaille directement avec des données de production avec un minimum de maux de tête, à l'exception peut-être de quelques erreurs qui se glissent ici ou là, des choses comme des problèmes d'orthographe, du mauvais texte alternatif, des liens pointant vers le mauvais emplacement. Cela semble être dû à un manque d'examen par les pairs de ma part, pas à cause du travail avec des données en direct.

Alors pourquoi développer sur le site en direct une si mauvaise pratique?

Si, pendant le développement, vous exécutez des commandes SQL qui incluent INSERTou UPDATEsur des tables de base de données existantes, vous courez un risque dans la mesure où ces tables de base de données sont essentielles à la mission.

Certains endroits synchronisent les données de production dans la base de données de développement à un certain intervalle, disons une fois par semaine ou à la demande du développeur, afin que vous ayez de nouvelles données à développer.

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 un gros problème. Maintenant, si vous exécutez des rapports qui effectuent des analyses de table, vous avez la possibilité de verrouiller une table, puis vos utilisateurs existants sont affectés.

Je m'en remettrais à mon administrateur de base de données dans des cas comme celui-ci, s'il n'y a pas de DBA "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. Au sein d'une équipe, c'est vital. À défaut, si vous insistez pour ne créer qu'une seule base de données, vous pouvez préfixer vos tables de base de données de développement DEV_et vous sentir un peu mieux. Oui, cela nécessite quelques modifications de code, mais en développement, l'ajout de variables pendant le 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 voulez PAS développer les données de production sur votre serveur de production. Il y a deux ou trois raisons énormes.

1. Le développement ralentit votre box de production et crée des vulnérabilités. Que se passe-t-il si vous laissez votre ordinateur déverrouillé et que vous vous éloignez?
2. Si vous faites une erreur, les personnes qui visitent votre site peuvent le voir.
3. Si vous effectuez un type de mise à jour des données à l'intérieur d'une transaction dans votre base de données et que vous ne la validez pas immédiatement ou que la transaction prend du temps pour terminer, vous mettrez un verrou sur toutes les tables impliquées et vous pourriez provoquer un dépassement de délai. .
4. Certains systèmes de base de données, en particulier SQL Server, verrouillent parfois les tables uniquement sur les instructions SELECT! Ce qui signifie que vous pouvez involontairement donner aux utilisateurs des délais d'expiration ou des pages d'erreur sur votre site.

Je ne ferais jamais de développement sur une live box si possible. Le mieux est de faire une sauvegarde de la base de données et des pages et de travailler avec la copie, puis de pousser 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 à corriger.

Si vous ne conduisez pas sans ceinture de sécurité, ne développez pas sur les données de production. Juste un problème de sécurité.

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 test distincte 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 développer sur une production en direct des données - rappelez-vous les lois de Murphy "Tout ce qui peut aller mal ira mal.", Et il est si facile de faire une petite erreur avec de grosses conséquences graves.