Développer sur un serveur de production
Aujourd'hui, j'ai été crié pour avoir développé une application sur un serveur de production. Citation, " le développement sur un serveur de production n'est pas acceptable - jamais! "
Voici la situation.
- J'ai configuré une instance de développement:
http://example.com:3000 - L'instance de production est:
http://example.com - Je termine tout mon travail de développement sur
http://example.com:3000et lorsque le client est satisfait des modifications, je les déplace vershttp://example.com.
L'application avec laquelle je travaille est une ancienne 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 n'ai jamais pu 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.
Encore une fois, suis-je un idiot? Probablement, 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?
J'avais l'habitude de développer sur le serveur de production. Cela peut fonctionner correctement, mais il est déconseillé pour au moins deux raisons:
- 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 qui aura un impact sur votre code de production.
- 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 MySQL ou autre, vous serez dans une liaison .
Comme d'autres l'ont dit, le codage sur l'environnement PROD expose vos utilisateurs à vos bugs. Même si vous avez démarré une autre instance, vous disposez toujours de ressources matérielles partagées et vous pouvez toujours accéder aux fichiers de production et aux bases de données. Et comme le soulignent certains commentaires, si votre instance de Dev est piratée (par exemple, parce que vous oubliez de l'effacer et que quelqu'un découvre ensuite un énorme exploit de sécurité dans Rails), vous avez maintenant une machine accessible au public avec votre application faisant office de passerelle. Ce qui serait ... malheureux.
Différentes entreprises ont des réponses différentes à cela, mais elles peuvent généralement être réparties comme suit:
- Une erreur a-t-elle eu lieu?
- Combien de temps faudrait-il pour annuler une modification (je travaille principalement en C++, donc faire reculer un binaire peut prendre de manière significative plus long qu'en Ruby, surtout quand vous avez "perdu" l'ancien binaire et doivent recompiler)
- Quel est l'effet du changement (guide approximatif: visser les données stockées est donc bien pire que de ne pas stocker ou afficher des données, ce qui est pire que de ne pas afficher la page du tout)
- Si vous avez foiré puis êtes sorti, est-ce que quelqu'un saurait ce que vous avez fait?
- Y avait-il une autre option de déploiement qui aurait empêché/minimisé/détecté le vissage avant l'impact?
Cela vous donne le calcul final:
- Combien cette erreur complètement évitable aurait-elle coûté à l'entreprise?
C'est maintenant combien moins toute votre structure de gestion vaut pour le gars qui prend les décisions budgétaires. D'où criant.
Si vous travaillez sur la page interne "À propos de nous" de la société et saisissez votre propre nom pour être "Thomas, un Dieu", problème de surnom embarrassant; si vous travaillez sur l'application d'achat critique pour l'entreprise, et qu'elle finit par déboguer accidentellement en texte brut les détails de la carte de crédit sur la page d'accueil ... problème de poursuite. Entre ces extrêmes, il y a tout, de la mauvaise facturation, de la productivité paralysante et de toutes les autres choses qui peuvent éloigner les clients.
La raison pour ne pas l'autoriser même pour la page "A propos de nous" est que le codage directement en production crée une dépendance . Vous commencez par le faire uniquement pour les mineurs, mais avec le temps, c'est tellement plus rapide de ne pas avoir à mettre à jour le DEV env.
Au-delà de cela, la taille de l'entreprise peut avoir un grand effet. Dans une équipe de deux hommes, quand quelque chose va mal, vous vous penchez par-dessus votre épaule et vous dites "Oi, crétin, remets-le". Dans une entreprise de 300 personnes, vous devez commencer à vous inquiéter de savoir s'il s'agissait d'incompétence ou de malveillance, les managers peuvent être tenus responsables de choses sur lesquelles ils n'avaient aucun contrôle, etc.
À la fin de la journée, si vous suivez la procédure et que vous vous trompez, ils vérifient ce qui ne va pas avec la procédure. Si vous contournez la procédure et que vous vous trompez, c'est maintenant votre seule responsabilité, même si le blâme se répand un peu. À vous de décider si vous voulez lancer les dés.
J'ai essayé de mettre en place un environnement de développement localement, mais je n'ai jamais pu 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 prends en charge les déclarations à éviter développement sur un serveur de production. Vous ne pouvez être justifié de le faire sous le GUN que s'il s'agit d'une correction de faute de frappe dans le fichier de configuration et insistée par votre manager.
WHY NOT? - Parce que, c'est très risqué et prononcé devenir une habitude plus tard cela vous rattraperait mal. Parce que des erreurs/échecs de production fatals peuvent vous coûter à renvoyer de votre travail.
Permettez-moi de le réitérer à nouveau, même si vous avez demandé de faire une correction de faute de frappe sur le serveur production, premier faites-le sur Staging. ou en d'autres termes, testez vos modifications, testez-le et testez-le à nouveau avant de le mettre en production.
C'est quelque chose qui se produit souvent dans des endroits où la culture du "faites-le rapide et sale" semble être une norme.
Edit: Développer sur un serveur de production, comme un environnement séparé est également NON acceptable. Tout problème causé dans votre travail peut simplement faire tomber le serveur de production et affecter les performances de l'application de production. Par exemple, je me souviens d'un cas où il y avait une faille de sécurité, lorsque mon ancien collègue a essayé 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 tranquilles. Ils peuvent contenir des données sensibles et vous ne voulez pas compromettre les performances ou la stabilité des sites de production avec du code non prêt pour la production.
Cela dit, il y a des moments où cela se fait couramment. Si vous êtes dans une position où vous pompez des brouchures à faible trafic ou des sites CMS simples, ce sera probablement moins un problème. Mais si vous travaillez sur quoi que ce soit avec des données sensibles ou des processus "critiques pour l'entreprise", vous ne devriez vraiment pas risquer d'avoir du code de développement sur la même machine.
Une autre raison importante de ne pas développer directement en production est qu'une instance de développement produira et affichera généralement des erreurs verbeuses et des traces de pile. Vous jamais voulez exposer cela à l'utilisateur.
Oui, vous pouvez les enregistrer au lieu de les montrer au client, mais cela rend le débogage tant que ça moins amusant qu'il ne l'est déjà.
Ajouté Résoudre votre problème secondaire d'avoir des problèmes avec votre instance de développement: j'ai eu beaucoup de succès en déployant un VirtualBox - basé VM qui duplique notre environnement de production (à l'exclusion du matériel, bien sûr) avec un buntu Server .
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 devez toujours:
- Construisez localement.
- Poussez-le sur un type de boîte qui imite autant que possible la production pour voir s'il joue Nice là-bas.
- Poussez-la éventuellement vers une instance d'assurance qualité ou de certification pour la transmettre au client/à l'équipe d'assurance qualité pour examiner les modifications.
- Poussez à la production.
Vous pouvez utiliser Capistrano recettes associées à GitHub pour gérer tout cela pour vous. Si vous devez le faire à la main à chaque fois, cela peut vieillir rapidement.
Je suis assez étonné que personne n'ait mentionné la raison la plus importante pour l'instant, 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 d'énormes problèmes dans d'autres calculs, puis, le lendemain, toutes les données sont des ordures et le client est énervé. C'est bien, bien pire qu'un bug dans l'interface utilisateur ou un petit plantage ici et là.
Pour la plupart des applications, la valeur réside dans les données et non dans les routines.
Un autre problème avec le développement sur prod est que, parfois, ces choses sont manquées dans le contrôle de code source et une future version pourrait annuler votre modification rapide.
Si vous êtes dans une entreprise cotée en bourse aux États-Unis, vous ne devriez même pas avoir accès à prod pour des raisons réglementaires. En général, dans aucune entreprise, un développeur ne doit avoir un accès prod (pour les raisons indiquées dans toutes les réponses ainsi que pour d'éventuelles raisons juridiques), votre gestionnaire a donc é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 Edge où la violation d'une meilleure pratique sera justifiée. Un bien meilleur conseil sera "Ne touchez pas les serveurs de production à moins d'avoir de très bonnes raisons"
Dans ma carrière, je n'ai trouvé que deux raisons de changer le code sur les serveurs de production:
Bogues ou comportements qui ne se produisent que là-bas et ne sont pas reproductibles dans l'environnement de développement. Ce sont rares mais peuvent être très ennuyeux et difficiles à trouver.
Correction directe d'un bogue critique que vous ne pouvez pas vous permettre d'attendre pour passer par le processus de déploiement normal si cela prend plus de quelques minutes. Après cela a été autorisé par la direction. Si vous avez de la chance, vous ne devriez en avoir que peu pour toute votre carrière.
Il vaut mieux laisser les deux aux développeurs seniors qui connaissent intimement les systèmes.