Développer en toute confiance sans véritable environnement de développement

12

J'ai récemment été embauché pour un projet qui implique de travailler avec et autour de plusieurs systèmes "d'entreprise" tiers. En raison de ce que j'imagine que ce serait le coût astronomique et les efforts nécessaires pour construire une réplique suffisamment fidèle de l'environnement de production, la perspective d'avoir un véritable environnement de développement semble disparaître.

Ce n'est bien sûr pas idéal. Du côté positif, j'imagine qu'il doit y avoir des gens qui testent et déploient des logiciels en toute sécurité dans des environnements non reproductibles comme celui-ci, et je peux probablement suivre leurs traces.

Comment ceux qui gèrent efficacement ce genre de situations le font-ils?

testing development-process

— Jason Swett
source

1

Virtualisation, ayant des environnements "similaires à" etc ... Essentiellement, essayez de reproduire ce que vous pouvez, à plus petite échelle, pour couvrir au moins la plupart des "parties mobiles" du système.

— Odé le

6

Vous devez vous fier à l'exactitude de l'API du système d'entreprise et effectuer de nombreux tests d'intégration, peut-être avec certains comptes de test.

— Robert Harvey

@RobertHarvey est mort ici. Quelqu'un devrait expliquer cela dans une réponse, mais c'est exactement ce dont vous avez besoin. En l'absence d'un environnement pour tester manuellement le système, tout ce que vous pouvez faire est de tester automatiquement le code.

— Jimmy Hoffa

1

D'accord, alors peut-être un bon point à retenir est que si vous ne pouvez pas avoir un environnement de développement complet, les comptes de test en production peuvent être la prochaine meilleure chose.

— Jason Swett

9

Cela se produit tout le temps dans le monde réel. Je connais un gars qui écrit des applications qui contrôlent de gigantesques serres agricoles - ventilation, chauffage, contrôle de l'humidité, vous l'appelez. Il n'a pas de «serre d'essai», mais il a un programme de simulation fourni par la société qui construit les systèmes matériels réels. Si le code fonctionne correctement avec le simulateur, il est supposé fonctionner correctement avec l'équipement réel. En de rares occasions, le simulateur s'avère faux, mais c'est le problème de la société de matériel de serre à traiter, car il ne simule pas correctement.

— Ross Patterson
source

L'OP ne semble pas avoir la garantie d'un «simulateur». De plus, dans votre cas, l'employeur de votre collègue pourrait probablement demander une compensation si le simulateur tombe en panne. Que peut faire l'OP dans une situation similaire? Ça dérange la compagnie d'assurance?

— K.Steff

4

Si l'OP n'a pas de simulateur, il doit en acquérir un - mendier / voler / emprunter / construire - n'a pas vraiment d'importance. À quel point un simulateur doit être bon - c'est quelque chose qu'il doit décider, et s'il en ressent le besoin, il peut / devrait parler à une compagnie d'assurance d'une petite chose appelée indemnité.

— mattnz

3

Ce sont des situations où la documentation de l'API, les documents de contrôle d'interface et les émulateurs sont primordiaux. Dans une entreprise pour laquelle je travaillais précédemment, cela s'est réellement produit, cela se produirait fréquemment au sein d'un projet au cours de certaines phases d'intégration où un segment était prêt, mais d'autres étaient en retard, une autre fonctionnalité était en cours d'élaboration ou pour une autre raison, ils ne pouvaient pas se déployer. la dernière version de leur segment à notre système de test. Donc, oui, nous avions en fait une réplique fidèle de notre environnement de production sur laquelle nous avons testé; cependant, dans la pratique, tous les segments n'étaient jamais prêts dans les délais, mais des interfaces avaient été convenues et verrouillées avant le démarrage du développement, et des émulateurs avaient été créés qui pouvaient pour la plupart imiter le comportement des autres segments.

Comme une autre réponse l'a indiqué, l'émulateur est ce qui permettra aux tests d'avoir lieu avant le déploiement. Un bon émulateur; cependant, dépend des interfaces et de la documentation bien définies.

— Fred Thomsen
source

1

Je suis dans de telles situations tout le temps.

Vous n'avez sûrement pas besoin d'interagir avec l'ensemble de l'application, mais probablement quelques interfaces en quelque sorte. Assurez-vous d'avoir une documentation confirmée et détaillée des interfaces, puis configurez des simulations de ces interfaces uniquement pour vérifier que votre code ajouté / modifié fonctionne comme vous le souhaitiez.

Vous pouvez également faire un hybride. Essayez de reproduire les parties que vous pouvez faire facilement, puis "connectez" aux systèmes réels (si cela est possible dans votre situation). Je l'ai fait avec un certain succès - dans certains cas où ma logique et le logiciel serveur étaient exécutés localement, mais j'avais toujours des connexions avec le vrai système ERP pour vérifier les appels, etc. Pas idéal, mais les choses le sont rarement.

Étant donné que vous n'avez qu'un système de production avec lequel travailler - notez que vous ne pouvez pas compter uniquement le temps de développement économisé lors de la configuration d'une réplique, mais vous devez prendre en compte le risque commercial d'utiliser un code largement non testé avec des données commerciales en direct. Votre code SERA moins fiable que le code testé contre une réplique. Les systèmes peuvent-ils être en panne pendant un certain temps? Peuvent-ils être restaurés en cas de corruption de données? Combien ça coûte?

Une meilleure pratique dans les entreprises consiste à mettre en place une réplique (ou peut-être plus d'une) de la production au moment où l'environnement de production est configuré. À ce moment, le coût supplémentaire ne sera pas si énorme.

— Petter Nordlander
source

1

Notre système fonctionne avec plusieurs grands systèmes externes. Nous combinons les approches suivantes lors de leur test si nous n'avons pas une configuration complète de bout en bout:

Enregistrer-rejouer des données réelles. Enregistrer des données réelles (demandes / réponses de systèmes externes réels), les paramétrer si nécessaire et les rejouer
Construisez ou achetez un simulateur qui agit comme un système externe
DSL pour la génération de données de test. Pour les systèmes pilotés par les données, écrivez DSL de haut niveau pour générer des données de test.

— dzieciou
source