Développer sur un serveur de production

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?

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.

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.

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.

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.

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 .

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.

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.

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.

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.