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

Question

Si mi código Perl tiene una ubicación código de producción y la ubicación del código "beta" (por ejemplo, producción de Perl EE.UU. código en /usr/code/scripts, BETA código Perl está en /usr/code/beta/scripts; bibliotecas de producción de Perl están en /usr/code/lib/perl y versiones beta de las bibliotecas están en /usr/code/beta/lib/perl, ¿hay una manera fácil para mí para lograr una configuración tal

Los requisitos exactos son:?.

• El código debe ser el mismo en la producción y la ubicación BETA

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

• versiones beta de secuencias de comandos debe llamar a otros scripts beta y bibliotecas beta (si existe) o bibliotecas de producción (si no existen bibliotecas BETA)

• Las rutas de código deben ser los mismos entre beta y producción con el excepción de directorio de base (/usr/code/ vs /usr/code/beta/)

• las secuencias de comandos debe estar bajo el mismo directorio base pero puede estar en sus subdirectorios a nivel de profundidad arbitraria (esto excluye la solución clásica use lib "$FindBin::Bin/../lib" de la sección 31.13. utilizar lib de "programación Perl")

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

Answer 1

Nuestra propia solución fue la siguiente:

• tener una biblioteca (vamos a llamarlo BetaOrProd.pm)

  • la biblioteca debe ser incluido a través de "use BetaOrProd;" en cada guión
  • La biblioteca DEBE ser la primera declaración use en cada secuencia de comandos después de "use strict;" pragma (y "usar advertencias" si usamos eso). Incluyendo antes cualquier bloque BEGIN.
  • La biblioteca tiene un bloque BEGIN que contiene la mayor parte de la lógica
  • Eso BEGIN bloque en los controles de la biblioteca ruta del directorio del programa (basa fuera de $ 0 con ruta absoluta aplicada)
  • Si la ruta del directorio comienza con /usr/code/beta, el programa se considera a correr en lugar BETA, lo demás en la producción
  • en cualquier caso, es /usr/local/lib/perl-un desplazado hasta el principio de la lista @INC
  • Si la ubicación BETA, /usr/code/beta/lib/perl es desplazada de la ONU para el comienzo de @INC lista después de eso.
  • Si la ubicación BETA, una variable especial $ isBETA (accesible mediante un método de acceso exportado desde BetaOrProd.pm) se establece en "BETA".

• Cada vez que un script/biblioteca tiene que llamar a otro script, la ruta de acceso al script llamado se calcula con base en dicho descriptor de acceso a la variable $ isBETA exportado de BetaOrProd.pm

• Cada vez que un Perl necesidades de la biblioteca a se requiere o se usa, no se necesita ninguna 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 guión debe tener "use BetaOrProd;" como el primer use declaración en cada guión después de "use strict;" pragma.

   Mitigada 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 realizar la prueba BETA BetaOrProd.pm a través de /usr/code/beta/lib/perl. D'uh.

   mitigado por unidad muy minucioso y prueba de integración de la biblioteca

Answer 2

he tenido que utilizar 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 el formato AAAAMMDD, si el mercado de valores estaba ya abierta, etc.)

Answer 3

que abordan esto con FindBin:

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

O bien, si el modo de atenuació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 de 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 anterior al use lib 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 de inmediato.

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

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