Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>
Saltar a la sección
La virtualización de servicios generalmente se usa para conectar aplicaciones que dependen de la nube, SOA o API de terceros. Aprenda a expandir una herramienta de virtualización de servicios gratuita a una implementación integral de DevOps leyendo esta publicación de blog.
Saltar a la sección
Saltar a la sección
La mejor manera de lleve la virtualización de servicios a su organización es paso a paso. Úselo donde sea más valioso para reducir el costo total de las pruebas y obtenga el poder de controlar su proceso de automatización de pruebas con un flujo de trabajo DevOps completamente automatizado.
Usemos una analogía. Cuando decida que es hora de adoptar un estilo de vida saludable, puede investigar un poco y terminar con un consejo como, "Sarriba bebiendo alcohol! ¡Empieza a comer kale! ¡Vete a la cama a las 8 en punto! ¡Camina cinco millas todos los días!” Si bien puede tener sentido adoptar todas estas actividades para adoptar un estilo de vida saludable, si intenta adoptarlas todas a la vez, probablemente fracase. En su lugar, debe ir paso a paso. Añade un ejercicio extra aquí. Haga una elección de alimentos saludables allí. Lentamente, llévate a un nivel en el que puedas desarrollar hábitos saludables como un profesional.
Virtualización de servicios no es diferente A lo largo de los años, he ayudado a numerosos clientes a adoptar este valioso habilitador de DevOps. La mayoría de las organizaciones quieren adoptar el enfoque big bang: incorporar de inmediato una solución completamente implementada que abarque varios equipos y que ya esté integrada como parte de su canal de entrega continua.
Si bien todas estas cosas son esenciales para realizar plenamente el ROI potencial que la virtualización de servicios puede proporcionar, si intenta hacerlo todo el primer día, entonces probablemente no podrá escalar de manera efectiva en su implementación completa de DevOps. Entonces, ¿cómo llegas allí?
En este blog, compartiré precisamente eso. Seguiremos a una persona, desde su única licencia gratuita de virtualización de servicios hasta la licencia completa de su organización. implementación de virtualización de servicios, integrado en su flujo de trabajo DevOps. Esto está basado en una historia real, pero por razones de anonimato, llamaremos a esta persona Sally.
Conoce a Sally, la desarrolladora. Sally es inteligente y puede desarrollarse a un ritmo mucho más rápido que sus colegas. Comenzó a utilizar simulacros para aislarse durante la fase de prueba, pero dedicaba mucho tiempo a desarrollar el tipo de lógica que necesitaba para incorporar a esos sistemas porque las aplicaciones reales que estaba creando eran complejas.
Entonces, aprendió cómo la virtualización de servicios podría crear un servicio virtual más complicado en un período de tiempo notablemente corto. Ella descargó el versión gratuita de Parasoft Virtualize para obtener la virtualización de servicios de forma gratuita, lo que le permitió comenzar a crear servicios virtualizados y modificarlos fácilmente a medida que los servicios reales estaban cambiando. Como resultado, pudo realizar todas sus pruebas y desarrollo en un entorno completamente aislado.
Mientras discutía estas ventajas con algunos de sus compañeros de trabajo, ellos también querían aprovechar los servicios que ella había creado porque eran servicios comunes entre los diferentes desarrolladores. Simplemente podrían apuntar sus aplicaciones a la máquina de Sally y cosechar los beneficios.
También obtuvieron virtualización de servicios gratuita con Parasoft Virtualize y comenzaron a crear nuevos servicios, ajustar esos servicios y consumir esos servicios, todo desde sus escritorios gratuitos. El equipo hizo un progreso significativo en el desarrollo y las pruebas porque pudieron reducir muchos de los cuellos de botella que habían estado presentes en el entorno. El equipo se hizo popular por su agilidad y consiguió todos los mejores proyectos.
La gerencia se acercó al equipo de Sally. Ellos eran curiosidad por la solución de virtualización de servicios que el equipo estaba usando para ayudarlos a construir y probar las aplicaciones más rápidamente. Querían tener una discusión sobre su aplicación práctica en el entorno más amplio. Hubo algunos rumores sobre las interrupciones en los entornos de integración y producción causadas por aplicaciones heredadas. Las aplicaciones se basaban en una serie de bases de datos Oracle y un ESB complejo y un mainframe.
Esos sistemas fueron difíciles de probar por una serie de razones. Sally y su equipo pudieron demostrar que era fácil simular los servicios detrás de ESB porque eran servicios REST y SOAP básicos y un par de JMS y MQ con XML desarrollado internamente. Para abordar el hardware heredado, necesitaban potenciar su escritorio de virtualización de servicios, por lo que actualizaron a la versión completa de Virtualización de Parasoft.
En este punto, pudieron aplicar fácilmente la virtualización de servicios para los diferentes desafíos presentes en los casos de uso descritos por la gerencia. Tomó algunos días asegurarse de que los servicios virtuales satisficieran todos los diferentes casos de uso, pero pudieron desbloquear todos los desafíos que tenían en esos entornos. Este fue uno de los puntos de inflexión clave para el movimiento de virtualización de servicios en la organización de Sally porque pudieron aprovechar la experiencia del equipo de Sally con la virtualización de servicios básicos para abordar desafíos más complicados que tenían costos reales asociados.
A medida que el equipo se hizo más popular, quedó claro que necesitaban escalar su implementación. Si uno de los miembros del equipo tuviera que apagar la máquina o irse de vacaciones, afectaría a los usuarios que utilizan los servicios virtuales. Sally decidió que era hora de actualizar su arquitectura de implementación una vez más y adquirieron un servidor de pruebas de virtualización.
Esto permitió que cada miembro del equipo combinara su esfuerzo para crear un ecosistema de prueba simulado completo. El servidor siempre estaba encendido y actuaba como una biblioteca de artefactos virtuales. Estaba conectado al control de código fuente, por lo que, a medida que se implementaban diferentes versiones de los servicios en el servidor, se registraban automáticamente. Esto permitió que el equipo tuviera un punto central de la verdad para todos los activos virtuales. Nadie tuvo que adivinar dónde estaba la versión más reciente.
El equipo tarareó felizmente durante varios meses resolviendo desafíos grandes y significativos para la organización. Creció en tamaño con algunos miembros más. Para aumentar la visibilidad y el conocimiento del equipo, y aumentar el tamaño de su presupuesto, Sally implementó el programa "Hoo-Rah".
Cada vez que el equipo creaba algo con un ROI cuantificable, realizaban un seguimiento de las ganancias y enviaban un correo electrónico público explicando lo que habían hecho y qué equipos se habían beneficiado. Ejemplos de estos “hoo-rah”s fueron:
Estos correos electrónicos de "hurra" fueron vitales para atraer equipos adicionales y ayudaron a las partes interesadas clave del negocio a comprender la importancia de la virtualización de servicios para el proceso de automatización de pruebas.
Mientras realizaba una auditoría de una aplicación crítica, un miembro del equipo de seguridad descubrió un vector de ataque potencial en el sistema que podría explotarse y provocar no solo la filtración de datos confidenciales del cliente, sino también obligar a la organización a incumplir. Si no se soluciona rápidamente, la organización se vería obligada a actualizar el comité de cumplimiento e iniciar el proceso de sanción.
El equipo se dio cuenta de que si podían remediar el defecto dentro de un período de tiempo específico, podrían impulsar los cambios en el entorno de producción y todo estaría bien. El desafío era que, para reproducir con éxito el problema, tenían que poner muchos de sus sistemas de pago de terceros en un estado en el que proporcionarían varias condiciones de error y filtrarían intencionalmente PII o datos de clientes.
El equipo no tenía la capacidad de forzar estos sistemas, que estaban fuera de su control, al estado que necesitaban para exponer el defecto y validar las correcciones que implementarían. Llamaron a Sally a media noche y le pidieron que fuera a trabajar.
El equipo hizo un trabajo rápido al reutilizar los servicios virtuales existentes que habían creado para estos sistemas de pago de terceros y ponerlos en un estado en el que comenzarían a mostrar un comportamiento negativo. Debido a que no era necesario volver a implementar la aplicación, simplemente podían modificar el comportamiento a medida que los desarrolladores realizaban sus cambios y descartar todas las diferentes combinaciones que conducían a la vulnerabilidad potencial. No hace falta decir que el equipo tuvo éxito en la entrega de un parche caliente en la producción que ahorró millones a la empresa.
Luego, el equipo de administración dio el siguiente paso valioso para su organización: crear un centro de excelencia de virtualización de servicios dedicado que podría aprovecharse para crear servicios virtuales cada vez que surgieran nuevos desafíos. Sally, por supuesto, era la opción natural para liderar el equipo.
Sally comenzó a desarrollar procesos en torno a la incorporación de iniciativas de virtualización y la creación de criterios de aceptación, de modo que el equipo en sí no se convirtiera en un nuevo cuello de botella. La gobernanza se convirtió en una parte importante de la conversación.
El equipo estableció una serie de cinco funciones y responsabilidades para garantizar que cada proyecto de virtualización tuviera éxito.
La configuración de estos roles fue fundamental para el éxito del equipo de virtualización de servicios, aclarando las necesidades para que los proyectos de virtualización tuvieran éxito. Cada miembro del equipo de virtualización de servicios tenía el software de escritorio Parasoft Virtualize. Crearían los servicios virtuales en el escritorio y luego los pondrían a disposición de los usuarios.
El equipo del centro de excelencia de virtualización de servicios de Sally se hizo popular entre los desarrolladores y probadores. Muchos empezaron a pedir acceso a Parasoft Virtualize para poder hacer sus propios prototipos y validar escenarios negativos y positivos.
Sally tenía la infraestructura para respaldarlo, pero no necesariamente necesitaba darles el peso que era la versión de escritorio profesional. Volvió a actualizar su infraestructura e incluyó la interfaz de cliente ligero de Parasoft para habilitar completamente sus flujos de trabajo de DevOps. Este tablero centralizado dio acceso a cualquier usuario de la organización y les permitió crear servicios virtuales y casos de prueba directamente desde su navegador.
Esta evolución de la implementación creó un modelo híbrido en el que los miembros individuales del equipo podían actuar de manera federada, creando sus propios servicios virtuales para sus necesidades, accediendo a ellos, modificándolos, etc. Y cuando llegó el momento de integrar esos servicios virtuales en la arquitectura más grande, tenían un mecanismo para colaborar con el centro de virtualización de excelencia. El equipo podría agregar servidores adicionales para soportar la carga e incorporar servidores de rendimiento cuando el equipo de rendimiento se uniera.
En este punto, Sally tenía una biblioteca integral de activos virtuales y los casos de prueba automatizados correspondientes. Tenía una biblioteca de datos de prueba que se alimentaban de estos dos artefactos de prueba. La mayor parte de la creación real de servicios estaba a cargo de los equipos individuales, y el equipo de Sally era el principal responsable de orquestar todos esos diferentes servicios virtuales en un "entorno".
El entorno era realmente solo una plantilla de activos virtuales, casos de prueba y datos de prueba integrados en una configuración específica para satisfacer una iniciativa de prueba. Construyeron muchas de estas plantillas de entorno y las alinearon con las diferentes aplicaciones de la organización.
Cada vez que se necesitaba probar una aplicación y el entorno real no era suficiente, el centro de excelencia de virtualización creaba una entorno de diferentes servicios virtuales y permitir que los miembros del equipo prueben. Los equipos se volvieron cada vez más dependientes de los servicios virtuales como parte de su ejecución de prueba, y fue una transición natural hacia la canalización de entrega continua.
La implementación final y completamente realizada para la virtualización de servicios en la organización de Sally se ve así:
Los miembros individuales del equipo crearían los servicios virtuales y los casos de prueba dentro de sus navegadores. Si era necesario actualizar los servicios virtuales o agregar lógica adicional, el COE de virtualización se encargaría de eso con sus escritorios profesionales.
Los servicios virtuales y los casos de prueba luego se combinarían dentro de la interfaz del cliente ligero. Cuando esos entornos necesitaban estar disponibles, su sistema de compilación los llamaría y los implementaría en la nube o en servidores dedicados. Luego, los casos de prueba automatizados se iniciarían, los resultados se enviarían a su tablero agregado y el entorno dinámico se destruiría.
Las verdaderas pruebas continuas habilitadas por la virtualización de servicios no son algo que sucede de la noche a la mañana. Esta historia es real y todo es posible con la virtualización de servicios. Pero requiere que la organización comience desde cero, tal como lo hizo Sally. Por cierto, ahora forma parte de la junta ejecutiva.
Este enfoque es la mejor manera de llevar la virtualización de servicios a su organización, paso a paso, utilizada donde sea más valiosa. El viaje exacto de todos será diferente, pero los resultados finales deberían ser los mismos: