Desarrollar con confianza sin un entorno de desarrollo real.

12

Recientemente me contrataron para un proyecto que implica trabajar con y alrededor de varios sistemas de "empresa" de terceros. Debido a lo que imagino sería el costo astronómico y el esfuerzo requeridos para construir una réplica suficientemente fiel del entorno de producción, la posibilidad de tener un entorno de desarrollo real parece muy escasa.

Por supuesto, esto no es lo ideal. En el lado positivo, me imagino que debe haber personas por ahí que prueben e implementen software de manera segura en entornos irreplicables como este, y probablemente pueda seguir sus pasos.

¿Cómo lo hacen quienes manejan efectivamente este tipo de situaciones?

testing development-process

— Jason Swett
fuente

1

Virtualización, tener entornos "similares a", etc. En esencia, intente replicar lo que pueda, en menor escala, para cubrir al menos la mayoría de las "partes móviles" del sistema.

— Oded el

66

Debe confiar en la corrección de la API del sistema empresarial y hacer muchas pruebas de integración, tal vez con algunas cuentas de prueba.

— Robert Harvey

@RobertHarvey está muerto aquí. Alguien debería exponer esto en una respuesta, pero esto es exactamente lo que necesita. En ausencia de un entorno para probar manualmente el sistema, todo lo que puede hacer es probar automáticamente el código.

— Jimmy Hoffa

1

De acuerdo, tal vez un buen punto de partida es que si no puede tener un entorno de desarrollo completo, las cuentas de prueba en producción pueden ser la mejor opción.

— Jason Swett

9

Esto sucede todo el tiempo en el mundo real. Conozco a un tipo que escribe aplicaciones que controlan gigantescos invernaderos agrícolas: ventilación, calefacción, control de humedad, lo que sea. No tiene un "invernadero de prueba", pero tiene un programa de simulador proporcionado por la compañía que construye los sistemas de hardware reales. Si el código funciona correctamente con el simulador, se supone que funciona correctamente con el equipo real. En raras ocasiones, el simulador resulta estar equivocado, pero ese es el problema de la empresa de hardware de invernadero para tratar, porque no está simulando correctamente.

— Ross Patterson
fuente

El OP no parece tener la garantía de un "simulador". Además, en su caso, el empleador de su colega probablemente podría solicitar una compensación si falla el simulador. ¿Qué puede hacer el OP en una situación similar? Molestar a la compañía de seguros?

— K.Steff

44

Si el OP no tiene un simulador, necesita adquirir uno - rogar / robar / pedir prestado / construir - realmente no importa. Qué tan bueno debe ser un simulador; eso es algo que debe decidir, y si siente la necesidad, puede / debe hablar con una compañía de seguros sobre una pequeña cosa llamada indemnización.

— mattnz

3

Estas son situaciones en las que la documentación API, los documentos de control de interfaz y los emuladores son primordiales. En una empresa para la que trabajé anteriormente, esto realmente sucedió, esto sucedería con frecuencia dentro de un proyecto durante ciertas fases de integración en las que un segmento estaba listo, pero otros estaban atrasados, se estaba trabajando en otra característica o por alguna otra razón no podían implementar La última versión de su segmento para nuestro sistema de prueba. Entonces, sí, en realidad teníamos una réplica fiel de nuestro entorno de producción que probamos; sin embargo, en la práctica, todos los segmentos nunca estuvieron listos a tiempo, pero las interfaces habían sido acordadas y bloqueadas antes del inicio del desarrollo, y se habían creado emuladores que podían imitar en su mayor parte el comportamiento de los otros segmentos.

Como dijo otra respuesta, el emulador es lo que permitirá que las pruebas se realicen antes de la implementación. Un buen emulador; sin embargo, depende de interfaces y documentación bien definidas.

— Fred Thomsen
fuente

1

Estoy en tales situaciones todo el tiempo.

Seguramente no necesita interactuar con toda la aplicación, sino probablemente con algunas interfaces de algún tipo. Asegúrese de haber confirmado y detallado la documentación de las interfaces, luego configure los simulacros de estas interfaces solo para verificar que su código agregado / modificado funciona de la manera en que desea que funcione.

También puedes hacer un híbrido. Intente replicar las partes que puede hacer con bastante facilidad, luego "conéctese" a los sistemas reales (si esto es posible en su situación). Lo hice con cierto éxito, en algunos casos donde mi lógica y el software del servidor se ejecutaban localmente, pero todavía tenía conexiones con el sistema ERP real para verificar las facturas, etc. No es ideal, pero las cosas rara vez lo son.

Dado que solo tiene un sistema de producción con el que trabajar, tenga en cuenta que no puede contar solo el tiempo de desarrollo ahorrado en la configuración de una réplica, sino que debe tener en cuenta el riesgo comercial de usar código en gran medida no probado con datos comerciales en vivo. Su código SERÁ menos confiable que el código probado contra una réplica. ¿Pueden los sistemas estar inactivos por algún tiempo? ¿Se pueden restaurar en caso de corrupción de datos? ¿Cuánto cuesta eso?

Una práctica recomendada en las empresas es colocar una réplica (o quizás más de una) de la producción en el momento en que se configura el entorno de producción. En ese momento, el costo adicional no será tan grande.

— Petter Nordlander
fuente

1

Nuestro sistema funciona con varios sistemas externos grandes. Combinamos los siguientes enfoques cuando los probamos si no tenemos una configuración completa de extremo a extremo:

Grabar-reproducir datos reales. Registre datos reales (solicitudes / respuestas de sistemas externos reales), parametrícelos si es necesario y repítalos
Cree o compre un simulador que actúe como un sistema externo
DSL para la generación de datos de prueba. Para sistemas basados en datos, escriba DSL de alto nivel para generar datos de prueba.

— dzieciou
fuente