perl testing perl-module

¿Cómo uso los módulos Beta Perl de los scripts beta Perl?



testing perl-module (3)

Nuestra propia solución fue la siguiente:

  • Tener una biblioteca (llamémoslo BetaOrProd.pm)

    • La biblioteca DEBE incluirse a través de " use BetaOrProd; " en cada script
    • La biblioteca DEBE ser la primera declaración de use en cada script después de " use strict; " pragma (y "use warnings" si lo usamos). Incluyendo antes de cualquier bloque BEGIN .
    • La biblioteca tiene un bloque BEGIN que contiene la mayor parte de la lógica
    • Ese bloque BEGIN en la biblioteca comprueba la ruta del directorio del programa (basado en $ 0 con la ruta absoluta aplicada)
    • Si la ruta del directorio comienza con /usr/code/beta , se considera que el programa se ejecuta en la ubicación BETA, sino en producción
    • En cualquier caso, /usr/local/lib/perl no se desplaza al comienzo de la lista @INC
    • Si la ubicación BETA, /usr/code/beta/lib/perl no se desplaza al comienzo de la lista @INC después de eso.
    • Si la ubicación BETA, una variable especial $ isBETA (accesible por un método de acceso exportado desde BetaOrProd.pm) se establece en "BETA".

  • Cada vez que un script / biblioteca necesita llamar a otro script, la ruta al script llamado se calcula en base a dicho acceso a la variable $ isBETA exportada desde BetaOrProd.pm

  • Cada vez que se necesita o se necesita una biblioteca de Perl, no se necesita una lógica especial: el @INC modificado por BetaOrProd.pm se ocupa de saber de dónde se importarán los módulos. Si el módulo está presente en la ubicación BETA, entonces la biblioteca de la ubicación BETA será utilizada por la secuencia de comandos BETA, sino la biblioteca de la ubicación prod.

Los principales inconvenientes de este enfoque son:

  1. Requisito de que cada secuencia de comandos debe tener " use BetaOrProd; " como la primera declaración de use en cada secuencia de comandos después de " use strict; " pragma.

    Mitigado por el hecho de que nuestra empresa requiere que cada pieza implementada de código pase el validador automatizado, que puede verificar este requisito.

  2. No se puede probar BetaOrProd.pm a través de /usr/code/beta/lib/perl . D''uh.

    Mitigado por unidad muy completa y prueba de integración de la biblioteca

Si mi código Perl tiene una ubicación de código de producción y una ubicación de código "beta" (por ejemplo, código de producción Perl en /usr/code/scripts , el código BETA Perl está en /usr/code/beta/scripts ; las bibliotecas de producción Perl están en /usr/code/lib/perl y las versiones BETA de esas bibliotecas están en /usr/code/beta/lib/perl , ¿hay alguna manera fácil para mí de lograr dicha configuración?

Los requisitos exactos son:

  • El código debe ser EL MISMO en producción y ubicación BETA.

    Para aclarar, para promocionar cualquier código (biblioteca o script) desde BETA hasta la producción, lo ÚNICO que debe suceder es emitir literalmente el comando cp desde BETA a la ubicación del producto: tanto el nombre del archivo como el contenido del archivo deben permanecer idénticos .

  • Las versiones BETA de scripts deben llamar a otros scripts BETA y bibliotecas BETA (si existen) o bibliotecas de producción (si las bibliotecas BETA no existen)

  • Las rutas del código deben ser las mismas entre BETA y producción, con la excepción del directorio base ( /usr/code/ vs /usr/code/beta/ )

  • Los scripts deben estar todos bajo el mismo directorio base, pero pueden estar en sus subdirectorios a un nivel de profundidad arbitrario (esto excluye la solución de use lib "$FindBin::Bin/../lib" clásico use lib "$FindBin::Bin/../lib" de la sección 31.13. Use lib de "Programming Perl" )

Presentaré cómo resolvimos el problema como respuesta a esta pregunta, pero me gustaría saber si hay una mejor manera.

Tuve que usar una configuración similar. Sin embargo, el módulo recibió el nombre del nombre del proyecto y podría realizar otras funciones: cargar algunas variables de configuración específicas del entorno (ubicaciones de datos, credenciales para bases de datos dev / prod, por ejemplo), procesar algunos argumentos de línea de comandos y configurar algunas otras variables que fueron útiles para la mayoría de los scripts en el proyecto (la fecha actual en formato YYYYMMDD, si el mercado de valores estaba actualmente abierto, etc.)

Dirijo esto con FindBin :

use FindBin; use lib "$FindBin::Bin/../lib";

O bien, si el modo de contaminación está activo:

use FindBin; use lib ("$FindBin::Bin/../lib" =~ m[^(/.*)])[0];

Como esto no depende de ninguna ruta conocida o fija, permite tantos conjuntos independientes de código en una sola máquina como quiera, simplemente creando una nueva copia del directorio del proyecto.

Mantengo copias completas de todos los módulos del proyecto en cada imagen de desarrollo del proyecto, pero parece que no lo hace, y confío en que la copia beta recaiga en los módulos de la copia en vivo; un use lib /path/to/live/bin antes de use lib ''s de arriba manejaría eso, o podría simplemente vincular /path/to/live/bin en uno de los directorios en @INC para que siempre esté disponible inmediatamente.

Si las versiones en vivo y beta se ejecutarán desde cuentas diferentes, también puede valer la pena explorar local :: lib , pero esto realmente no parece ser lo que se pretende.

ACTUALIZACIÓN: Esto no funciona si los propios scripts pueden vivir en múltiples subdirectorios de un directorio determinado, pero funciona de otro modo.