¿Cuáles son las diferencias entre los diversos entornos de codificación posibles que no son de producción (por ejemplo, desarrollo, pruebas, puesta en escena, control de calidad)?

Las definiciones y los números dependen de la empresa, el proyecto y los costos. Lista de ejemplos de definiciones en la parte inferior, pero aquí también hay algunos comentarios generales.

Estará en la mejor forma si planifica y comunica para quién / para qué es cada entorno y también automatiza la creación, configuración, acceso y terminación tanto como sea posible. Scripts, docker, nube, lo que sea que necesite para facilitar la conexión, inicializar datos y comenzar a trabajar.

¿Qué es un “medio ambiente”? Si su sistema utiliza servidores web, bases de datos, directorio activo, correo electrónico, etc., ¿está haciendo copias de todos esos? ¿O simplemente implementando el código en varios servidores? Algunos proyectos tienen el lujo de poner en marcha laboratorios completos con todo, pero otros tienen que conformarse con una base de datos / servidor diferente.

¿Quién gobierna el acceso para usuarios y aplicaciones? ¿Los desarrolladores tienen acceso a todas partes? ¿Cómo se rastrean los errores y las entradas?

¿Quién posee realmente los ambientes? Tenemos algunos sistemas donde controlamos los servidores web, pero otra empresa está controlando el servidor de la base de datos. No siempre podemos obtener múltiples entornos para esa aplicación y tenemos que coordinarnos.

Costo: tenemos una variedad de sistemas locales y en la nube con los que trabajamos y, a veces, los entornos adicionales en la nube son muy costosos. Algunos proyectos configuramos implementaciones en la nube para entornos y otros los mezclamos en prem / cloud.

El desarrollo es generalmente para que los ingenieros lo codifiquen.

Test / QA generalmente es para que el equipo de QA o las pruebas automatizadas se ejecuten.

La integración a veces es un entorno para combinar múltiples sistemas que se conectan.

Migración: algunos de mis proyectos han tenido un entorno distinto para las pruebas de migración de datos para que la gran carga de la base de datos en esta área no afecte a los equipos de desarrollo o prueba.

UAT es la aceptación del usuario y a menudo atrae a los clientes después de que los entornos anteriores no hayan confirmado problemas obvios.

Paralelo: use este a menudo para tener una ejecución paralela para que los usuarios puedan probar ambos por un tiempo para confirmar con escenarios en tiempo real que no hay problemas.

Espejo: algunos proyectos tienen esto, que es una copia exacta de la producción, de modo que si surge un problema, el equipo de desarrollo puede investigar y reproducir sin afectar el área en vivo.

Prod – live, por lo general no hay acceso de desarrollo dependiendo de la madurez de la empresa.

Tomaré el proyecto que estoy trabajando como referencia e intentaré darle una oportunidad.

Varios entornos de aplicación suelen ser

1. Entorno de desarrollo

• Como su nombre indica, está destinado al desarrollo.
• Puede estar alojado en cada máquina de desarrollador
• Todos los desarrolladores pueden usar una instancia local común
• Aquí se realizan pruebas unitarias y pruebas de componentes (depende).

2. Componente y entorno de prueba de integración

• Aquí un equipo de prueba dedicado prueba todo el componente
• Prueba las interfaces del componente.

3. entorno E2E

• Fase de prueba importante
• Comienza con un fuerte paquete de regresión
• Viaje completo E2E probado
• El resultado es una provisión ficticia de servicio / producto

4. Entorno de prueba de aceptación del usuario

• Entrenamientos para usuarios
• Los usuarios en vivo probarán la aplicación
• Los usuarios pueden ser gerentes de producto, equipo de ventas, equipo de recepción que realmente usa el sistema en vivo
• Si se encuentran vacíos, esto puede llevar a una discusión y posiblemente a un cambio de código.

5. Ambiente de producción

• Antes del lanzamiento del producto, pueden hacer pruebas de preparación
• Una vez que se aprueba, los usuarios activos usan la solución

Entonces, ¿por qué tantos modelos de prueba? ¿Son necesarios para todos los componentes?

Respuesta:

Depende de la importancia del componente, su posición en el flujo E2E, la frecuencia de la historia y el Cliente, etc.

¿Por qué estas tantas pruebas?

Este es un proceso estándar que una organización suele seguir para asegurarse de que no haya ningún problema en el último momento cuando el producto esté listo para su envío.

Un término llamado SIGN OFF que se usa con bastante frecuencia en el entorno de TI.

El diseñador E2E necesita la firma del arquitecto

El Diseñador de componentes necesita la aprobación de E2E

El desarrollador necesita firmar la prueba de componentes

CIT necesita entrega de Dev

E2E necesita la aprobación de CIT

UAT necesita firmar E2E

La versión de producto necesita la firma de Business y UAT

Las necesidades comerciales de prueba de preparación firman.

Por lo tanto, generalmente es difícil tener una filtración de defectos si se sigue una práctica tan estándar.

Gracias..

Hola,

Estos diferentes tipos de entornos se configuran para garantizar que el producto esté casi libre de errores antes de que finalmente se envíe a los usuarios finales. Sin embargo, no hay una respuesta estándar para cuántos entornos diferentes se requieren. Porque todo difiere de un caso a otro y se deriva principalmente del presupuesto y el esfuerzo que cualquier compañía de software está dispuesta a invertir en infraestructura. La compañía de pruebas de software se adapta a tales requisitos y, en consecuencia, contrata a los ingenieros de control de calidad para una mejor eficiencia y ROI. Un mayor número de entornos es directamente proporcional a un mayor costo de mantenimiento, más esfuerzo de prueba y más tiempo para estar listo para la producción. Pero al mismo tiempo, proporciona el beneficio de una experiencia increíble para el cliente, ya que obtienen un producto que se prueba a fondo y la probabilidad de presencia de errores es muy baja.

Gracias,

Sumit

Creo que solo depende de lo que necesites.

Estoy en un pequeño equipo de 5 ingenieros, y trabajamos en una aplicación móvil. En este momento tenemos 3 entornos totales, porque es todo lo que necesitamos: desarrollo, puesta en escena y producción.

El desarrollo es para más cosas “experimentales” que acabamos de aterrizar, y todavía se actualiza a TestFlight (puede usar esto con aplicaciones iOS para probar la aplicación en múltiples dispositivos sin necesidad de enviarla a la App Store) para que todos los desarrolladores tienen una idea clara de lo que está viviendo exactamente en la rama de “desarrollo” de nuestros repositorios de Github en un momento dado.

Cuando estamos satisfechos con eso, podemos fusionar todo con el entorno de preparación, lo que brinda la oportunidad a algunos usuarios más internos y externos (piense, administradores internos, personal de productos, socios externos que quieran probar las características que se utilizarán en producción) para ver qué está pasando en el próximo lanzamiento de la aplicación.

El entorno final, la producción, es donde todo está vivo para los consumidores previstos.

En este momento, esto es todo lo que necesitamos, pero puede cambiar en el futuro. Creo que una de las únicas buenas métricas para determinar si eres demasiado redundante es si no estás haciendo uso de algún entorno particular que hayas configurado. Si no lo necesita, puede valer la pena deshacerse de él.