Développer sur un serveur de production

35

Aujourd'hui, je me suis fait engueuler pour avoir développé une application sur un serveur de production. Citer, " développer sur un serveur de production n'est pas acceptable - jamais! "

Voici la situation.

  1. J'ai mis en place une instance de développement: http://example.com:3000
  2. L'instance de production est: http://example.com
  3. Je termine tous mes travaux de développement http://example.com:3000et lorsque le client est satisfait des modifications, je les déplace http://example.com.

L'application sur laquelle je travaille est une vieille application Ruby on Rails , et je dois dire qu'au départ, j'ai essayé de configurer un environnement de développement localement, mais je ne pouvais jamais le faire fonctionner. Après avoir essayé pendant un moment, j'ai abandonné et décidé de développer sur le serveur de production.

Encore une fois, suis-je un idiot? Probablement que oui, mais je fais du développement web depuis quelques années maintenant et je n'ai jamais rencontré une telle situation. Qui a raison et pourquoi?

luk3thomas
la source
46
La seule réponse valable serait "avoir un serveur de production qui ne peut pas être reproduit en développement n'est pas acceptable - jamais."
Blrfl
49
Pour moi, le vrai problème ici est que vous avez un système de production où vous n'avez aucune idée de ce qui se passe ou de sa configuration. Que feriez-vous si votre machine de production tombait en panne en perdant toutes ses données? Si vous ne pouvez pas configurer un environnement de développement approprié maintenant, que ferez-vous lorsque ce sera votre seule option?
Greg Hewgill
@GregHewgill, oui c'est un bon point
luk3thomas
25
Greg a raison. Si vous ne maîtrisez pas suffisamment l'application pour reproduire l'environnement sur une machine de développement, non seulement vous ne devez ni développer ni tester la machine de production, mais vous ne devriez même pas être autorisé à le déployer sur cette machine. Vous aviez clairement tort, mais j'aurais crié à votre patron de vous donner l'accès avant de comprendre parfaitement ce que vous faisiez.
maple_shaft
3
Si vous ne pouvez pas configurer l'environnement de développement local, vous ne devriez pas du tout développer.
Jas

Réponses:

58

Je développais sur le serveur de production. Cela peut fonctionner correctement, mais il est déconseillé pour au moins deux raisons:

  1. Le code de développement peut provoquer des boucles infinies, des fuites de mémoire ou d’autres problèmes qui bloquent le processeur, consomment toute la mémoire ou affectent le serveur d’une manière pouvant affecter le code de production.
  2. Si vous devez apporter des modifications aux composants de l'environnement du serveur dans le cadre de votre travail de développement, comme la version de Ruby ou de MySQL ou autre, vous serez dans une impasse.
Jacob Terry
la source
1
Oui, c'est un bon point. Plus j'y pense, vous avez tout à fait raison.
luk3thomas
6
Il y a un troisième problème: la sécurité. Que se passe-t-il si quelqu'un scanne le serveur de production et découvre votre application (de développement), ce qui compromet l'application de production? Encore une fois, même s’il n’est pas vraisemblable que ce soit le cas, c’est à peu près ce que tout le monde dit après la compromission d’un serveur ou d’un système.
Marco
Le fameux problème de boucle infinie ...
Mansuro
3
@Marco En fait, c'est très probable si le serveur est accessible au public. Les serveurs de développement ont généralement une très mauvaise sécurité (car des commodités telles que les débogueurs et les traces de pile sont des responsabilités en matière de sécurité). Si un attaquant peut élever ses privilèges en exploitant le serveur dev, il / elle peut détenir complètement l'application de production.
Mark E. Haase
29

Comme d'autres l'ont indiqué, le codage dans l'environnement de production expose vos utilisateurs à vos problèmes. Même si vous avez démarré une instance différente, vous disposez toujours de ressources matérielles partagées et pouvez toujours accéder aux fichiers de production et aux bases de données. Et comme le soulignent certains commentaires, si votre instance Dev est piratée (par exemple, parce que vous oubliez de la nettoyer et que quelqu'un découvre alors un énorme exploit de sécurité dans Rails), vous disposez désormais d'un ordinateur accessible au public avec votre application. comme une porte d'entrée. Ce qui serait ... malheureux.

Différentes entreprises ont des réponses différentes à cela, mais elles peuvent généralement être décomposées comme suit:

  • Est-ce qu'une erreur s'est produite?
  • Combien de temps faudrait-il pour revenir sur une modification (je travaille principalement en C ++, donc la restauration d'un fichier binaire peut prendre beaucoup plus de temps que celle en Ruby, en particulier lorsque vous avez "perdu" l'ancien fichier binaire et devez le recompiler)
  • Ce que l'effet du changement (guide rugueux: vissage des données stockées est donc bien pire que de ne pas stocker ou d' afficher des données, ce qui est pire que de ne pas montrer la page du tout)
  • Si vous foutiez puis sortiez par la porte, quelqu'un saurait-il ce que vous avez fait?
  • Y avait-il une autre option de déploiement qui aurait empêché / minimisé / détecté le bousillage avant l'impact?

Cela vous donne le calcul final:

  • Combien cette erreur complètement évitable aurait-elle coûtée à l'entreprise?

C’est maintenant à quel point toute votre structure de gestion vaut moins pour le responsable qui prend les décisions budgétaires. Donc criant.

Si vous travaillez sur la page interne "À propos de nous" de la société et que vous tapez votre propre nom comme étant "un Dieu", Thomas, un problème de surnom embarrassant; Si vous travaillez sur l'application d'achat stratégique, elle finit par déboguer du texte brut sur les détails de carte de crédit vers la page d'accueil ... problème de poursuite. Entre ces deux extrêmes, il y a tout, de la charge insuffisante à la productivité paralysante, en passant par tout ce qui peut faire fuir les clients.

La raison pour ne pas le permettre même pour la page "À propos de nous" est parce que le codage directement en production crée une dépendance . Vous commencez par ne le faire que pour les mineurs, mais avec le temps, il est tellement plus rapide de ne pas avoir à mettre l'environnement à niveau.

Au-delà, la taille de l'entreprise peut avoir un impact considérable. Dans une équipe de deux hommes, quand quelque chose se passe mal, vous vous penchez sur votre épaule et vous dites "Oi, crétin, remets-le en arrière". Dans une entreprise de 300 personnes, vous devez commencer à vous inquiéter de savoir s'il s'agit d'une incompétence ou d'une malveillance, les gestionnaires peuvent être tenus responsables des actes sur lesquels ils n'avaient aucun contrôle, etc.

À la fin de la journée, si vous suivez la procédure et bousillez, ils vérifient ce qui ne va pas avec la procédure. Si vous échappez à la procédure et que vous vous trompez, c'est désormais votre seule responsabilité, même si le blâme se répand un peu. Que vous souhaitiez lancer les dés là-dessus dépend de vous.

deworde
la source
Ceci est un bon résumé des pièges rencontrés lors du développement dans un environnement de production , mais la question portait sur le développement dans un environnement séparé sur le matériel de production .
Carson63000
@ Carson63000 D'accord, et la réponse de Jacob est certainement la meilleure de ce côté. J'ai légèrement modifié le mien.
deworde
13

J'ai essayé de configurer un environnement de développement localement, mais je ne pouvais jamais le faire fonctionner. Après avoir essayé pendant un moment, j'ai abandonné et j'ai décidé de développer sur le serveur de production.

Je soutiens les déclarations à éviter le développement sur un serveur de production. Vous ne pouvez être justifié de le faire avec le GUN que s’il s’agit d’une correction de frappe dans un fichier de configuration et que votre responsable l’impose.

WHY NOT?- Parce que c’est très risqué et difficile de devenir une habitude qui vous rattraperait mal plus tard. Parce que des erreurs / échecs de production fatals peuvent vous faire perdre votre travail.

Permettez-moi de le répéter, même si, si vous avez demandé de corriger les fautes de frappe sur le productionserveur, commencez par le faire Staging. ou en d'autres termes, testez vos modifications, testez-les et testez-les à nouveau avant de les mettre en production.

C’est quelque chose qui arrive souvent dans des endroits où la culture du "faites-le vite et mal " semble être une norme.

Edit: Développer sur le serveur de production, en tant qu’environnement séparé, n’est PAS non plus acceptable . Tout problème lié à votre travail peut simplement entraîner la panne du serveur de production et affecter les performances de l'application de production . À titre d'exemple, je me souviens d'un cas où il y avait une faille de sécurité lorsque mon ancien collègue a tenté d'utiliser le serveur de production WinServer 2003 à des fins de développement.

EL Yusubov
la source
Ceci est un bon résumé des pièges rencontrés lors du développement dans un environnement de production , mais la question portait sur le développement dans un environnement séparé sur le matériel de production .
Carson63000
Merci, j'ai ajouté une modification qui répond aux préoccupations de le faire.
EL Yusubov
10

C'est vraiment un problème de protocole. Généralement, ce n'est pas quelque chose que vous voudriez faire. Vous voulez laisser les machines de production seules. Ils peuvent contenir des données sensibles et vous ne voulez pas compromettre les performances ou la stabilité des sites de production avec un code prêt à la production.

Cela dit, il y a des moments où cela se fait couramment. Si vous êtes en train de pomper des brouchures ou de simples sites de gestion de la circulation, ce sera probablement moins un problème. Mais si vous travaillez sur des données sensibles ou sur des processus "critiques", vous ne devriez vraiment pas risquer d'avoir du code de développement sur le même ordinateur.

bunglestink
la source
OK merci. Le code de développement peut-il rendre une machine instable? Je travaille sur une ancienne application de rails. Il me semble (personne naïve) que le code de développement http://example.com:3000n’affecterait pas http://example.com.
luk3thomas
2
@ luk3thomas: eh bien, bien sûr, ça ne devrait pas. Que se passe-t-il si un bogue du serveur Web ou de la structure Rails bloque le serveur? Et si, comme le suggérait Jacob Terry dans sa réponse, une boucle infinie ou une fuite de mémoire dans votre code de développement absorbait toutes les ressources du serveur de production et compromettait les performances du site actif?
Carson63000
1
Parfois, c'est une exigence. Tels que les magasins qui achètent des licences de logiciels coûteux et n’ont pas le budget pour une seconde copie juste pour le développement.
Brian Knoblauch
8

Une autre raison importante de ne pas développer directement en production est le fait qu’une instance de développement produira et affichera généralement des erreurs verbeuses et des traces de pile. Vous ne voulez jamais exposer cela à l'utilisateur.

Oui, vous pouvez les enregistrer au lieu de les montrer au client, mais cela rend le débogage bien moins amusant qu’il ne l’est déjà.

Ajout du traitement de votre problème secondaire de problème avec votre instance de développement: le déploiement d'une machine virtuelle basée sur VirtualBox qui duplique notre environnement de production (matériel exclusif, bien sûr) avec un serveur Ubuntu a été un franc succès .

msanford
la source
3
noté, merci pour le conseil w / VirtualBox
luk3thomas
1
@ luk3thomas C'est aussi gratuit! Il existe des tonnes de tutoriels en ligne pour VirtualBox + Ubuntu (probablement l'une des combinaisons de virtualisation les plus courantes).
msanford
8

Je suis assez étonné que personne n'ait mentionné la raison la plus importante à ce jour, pourquoi il est absolument interdit de développer sur des serveurs de production:

Ne jouez pas avec les données de production, ce qui peut arriver si facilement!

Une petite erreur à un endroit entraîne des problèmes gigantesques dans d'autres calculs, puis, le lendemain, toutes les données sont erronées et le client est énervé. C’est bien pire qu’un bug dans l’interface utilisateur ou un petit crash ici ou là.

Pour la plupart des applications, la valeur réside dans les données et non dans les routines.

Faucon
la source
1
Vous apprenez cela assez rapidement après avoir bousillé les données de production. Je suppose qu'il n'a pas de DB.
Rocklan
8

J'essaie toujours de demander aux autres développeurs quelles sont les procédures pour l'entreprise en question. En général oui, vous devriez toujours:

  1. Construire localement.
  2. Poussez-le vers un type de boîte qui imite autant que possible la production pour voir si elle joue bien là-bas.
  3. Peut-être pousser le contrôle sur une instance de certification ou de contrôle de la qualité à transmettre au client / à l'équipe de contrôle de la qualité pour examiner les modifications.
  4. Pousser à la production.

Vous pouvez utiliser les recettes Capistrano associées à GitHub pour gérer tout cela pour vous. Si vous devez le faire à la main à chaque fois, cela peut vieillir rapidement.

lscott3
la source
rails 2.3.11, je vais probablement finir par faire quelque chose comme ça
luk3thomas
1

Un autre problème lié au développement de prod est que, parfois, ces éléments sont oubliés dans le contrôle de source et qu'une future version peut annuler votre modification rapide.

Si vous êtes dans une société cotée en bourse aux États-Unis, vous ne devriez même pas avoir accès à Prod pour des raisons de réglementation. En règle générale, dans aucune entreprise, un développeur ne doit avoir un accès prod (pour les raisons indiquées dans toutes les réponses et pour des raisons juridiques éventuelles), de sorte que votre responsable a également tort de vous accorder les droits sur ce serveur.

HLGEM
la source
0

Les règles qui utilisent "toujours" ou "jamais" sont généralement mal définies. Il y aura des cas extrêmes où le dépassement d'une meilleure pratique sera justifié. Le meilleur conseil sera "Ne touchez pas aux serveurs de production à moins d’avoir de très bonnes raisons"

Au cours de ma carrière, je n'ai trouvé que deux raisons de changer de code sur les serveurs de production:

  1. Bugs ou comportements qui ne se produisent qu’ici et ne sont pas reproductibles sur l’environnement de développement. Celles-ci sont rares mais peuvent être très ennuyeuses et difficiles à trouver.

  2. Résoudre directement le bogue critique que vous ne pouvez pas vous permettre d’attendre pour passer à travers le processus de déploiement normal si cela prend plus de quelques minutes. Après cela a été effacé avec la direction. Si vous êtes chanceux, vous ne devriez en avoir que quelques-uns pour toute votre carrière.

Il vaut mieux laisser les deux développeurs plus expérimentés, qui connaissent très bien les systèmes.

Daniel Iankov
la source
Si des bogues surviennent uniquement dans l'environnement de production, votre environnement de développement n'est pas suffisamment proche de celui-ci. Vous devriez AU MOINS AVOIR un environnement de stockage intermédiaire avec la même configuration que l'environnement de production, avec les paramètres exacts du système d'exploitation, le matériel de traitement et les logiciels installés.
Nzall