Como faço para usar o beta módulos Perl do beta scripts Perl?

Question

Se o meu código Perl tem um código de produção local e "beta", o código de localização (e.g.a produção de código Perl-nos em /usr/code/scripts, BETA código Perl em /usr/code/beta/scripts;produção Perl bibliotecas estão em /usr/code/lib/perl e as versões BETA de as bibliotecas estão em /usr/code/beta/lib/perl, há uma maneira fácil para mim conseguir o tal configuração?

Os requisitos são:

• O código deve ser O MESMO em produção e BETA localização.

  Para esclarecer, para promover qualquer código (ou biblioteca de script) de BETA para a produção, a ÚNICA coisa que precisa acontecer é, literalmente, a emissão de cp comando do BETA para prod localização - tanto o nome do arquivo E o conteúdo do arquivo deve permanecer idêntico.

• Versões BETA de scripts deve chamar outros BETA scripts e BETA bibliotecas (se existir) ou de produção (bibliotecas de se BETA bibliotecas não existem)

• Os caminhos de código deve ser a mesma entre BETA e de produção, com excepção do da base de dados de diretório (/usr/code/ vs /usr/code/beta/)

• Os scripts devem estar todos sob a mesma base de diretório mas eles podem estar em seus sub-diretórios no arbitrária nível de profundidade (isto impossibilita o clássico use lib "$FindBin::Bin/../lib" solução de seção 31.13.use lib de "Programação Em Perl")

Vou apresentar a forma como resolvemos o problema como uma resposta para esta pergunta, mas eu gostaria de saber se há uma maneira melhor.

Answer 1

Nossa própria solução foi a seguinte:

• Tenha uma biblioteca (vamos chamá -lo de betaorprod.pm)

  • A biblioteca deve ser incluída via "use BetaOrProd;" dentro cada script
  • A biblioteca deve ser a primeira use declaração em cada script depois "use strict;"Pragma (e" Use avisos "se usarmos isso). Incluindo antes de qualquer BEGIN blocos.
  • A biblioteca tem um BEGIN bloco que contém a maior parte da lógica
  • Este BEGIN Bloco na biblioteca verifica o caminho do diretório do programa (com base em US $ 0 com o caminho absoluto aplicado)
  • Se o caminho do diretório começar com /usr/code/beta, o programa é considerado como executado na localização beta, else em produção
  • Em ambos os casos, /usr/local/lib/perl não mudou para o início de @INC Lista
  • Se beta local, /usr/code/beta/lib/perl não mudou para o início de @INC Lista depois disso.
  • Se a localização beta, uma variável especial $ isbeta (acessível por um método de acessador exportado de betaorprod.pm) está definido como "beta".

• Sempre que um script/biblioteca precisa chamar outro script, o caminho para o script chamado é calculado com base no referido acessador da variável $ isbeta exportada de betaorprod.pm

• Sempre que uma biblioteca Perl precisa ser necessária ou usada, nenhuma lógica especial é necessária - o @INC Modificado por betaorprod.pm cuida de saber de onde os módulos devem ser importados. Se o módulo estiver presente no local beta, a biblioteca do local beta será usada pelo script beta, caso contrário, a biblioteca da Prod Local.

As principais desvantagens dessa abordagem são:

1. Exigência disso cada script deve ter "use BetaOrProd;"Como o primeiro use declaração em cada script depois "use strict;"Pragma.

   Mitigado pelo fato de que nossa empresa exige que todos os códigos implantados passem pelo validador automatizado, o que pode verificar esse requisito.

2. Não é possível testar betaorprod.pm via /usr/code/beta/lib/perl . D'Uh.

   Mitigado por uma unidade muito completa e teste de integração da biblioteca

Answer 2

Eu abordo isso com FindBin:

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

Ou, se o modo de mancha estiver ativo:

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

Como isso depende de caminhos conhecidos ou fixos, ele permite tantos conjuntos independentes do código em uma única máquina quanto eu quiser, simplesmente criando uma nova cópia do diretório do projeto.

Eu mantenho cópias completas de todos os módulos de projeto em cada imagem de desenvolvimento do projeto, mas parece que você não e confia na cópia beta que volta aos módulos da cópia ao vivo; uma use lib /path/to/live/bin antes do use libS acima lidaria com isso, ou você poderia apenas vincular /path/to/live/bin em um dos diretórios sobre @INC para que sempre esteja disponível imediatamente.

Se as versões ao vivo e beta serão executadas de diferentes contas, Local :: lib Também pode valer a pena olhar, mas isso realmente não parece ser o que se destina.

ATUALIZAÇÃO: Isso não funciona se os scripts podem viver em vários subdiretos de um determinado diretório, mas funcionarem de outra forma.

Answer 3

Eu tive que usar uma configuração semelhante.O módulo foi nomeado após o nome do projeto, porém, e pode executar algumas outras tarefas:carregamento de alguns específicos do ambiente de configuração de variáveis (locais de dados, credenciais para dev/prod bancos de dados, por exemplo), o processamento de alguns argumentos de linha de comando, e a definição de algumas outras variáveis que foram úteis para a maioria dos scripts no projeto (a data atual no formato AAAAMMDD, se o mercado de ações foi aberto no momento, etc.)