compartilhar código Ruby dentro de uma organização

Question

Eu e minha equipe está começando a construir alguns scripts reutilizáveis. Eles são re-utilizáveis ??dentro de nossa org apenas como eles trabalham com aplicativos proprietry e nosso ambiente de servidor em particular. Então não é realmente apropriado para rubyforge ou github, etc.

A minha pergunta é, qual é a melhor prática para garantir a todos nós estamos usando os scripts mais recentes e melhores para todos os usuários? Nós praticamente executar esses scripts em um servidor, mas pode precisar expandir para os outros.

Devemos empacotá-los em gem (s) e iniciar um servidor gem privada?

Ou algo mais simples como um comum, lib compartilhável. Talvez com um script para download / atualização do nosso SCM?

Outras idéias?

Obrigado ....

Answer 1

Isso depende de alguns fatores, como quantas pessoas querem mudar o código (somente sua equipe, ou outra pessoa também), ou quanto dinheiro você tem para isto?

Pessoalmente eu criar um servidor gem de construção +, onde você pode carregar os scripts usando algum sistema de controle de versão (como git ou svn, depende de quantas pessoas estão trabalhando no projeto), e, em seguida, criar um trabalho cron, que seria genereate automaticamente as gemas das fontes em intervalos genéricos e armazená-los como versões diferentes. Desta forma, você pode ter certeza que você sempre tem um servidor authorative que armazena suas aplicações pedras preciosas, e você sempre pode obter uma versão anterior se algo der errado. Seu script pode criar nomes de versão gem separadas, como "appserv-edge" ou "appserv-estável"

Você também pode querer verificar as opções de código fechado do github também, se você tem o dinheiro para pagar por isso. Não sei porém se eles têm edifício gem e instalações de hospedagem para programas não-fonte aberto.

Answer 2

Eu criei um gemserver privada e é absolutamente fácil. O bit somente difícil é decidir como você deseja que seus usuários façam upload de pedras preciosas. Pessoalmente, eu apenas usar um formulário PHP upload, e tê-lo certifique-se de que não está mascarando qualquer gemas existentes.

Answer 3

No meu escritório estamos usando um pouco de uma abordagem híbrida para alguns de nossos scripts e bibliotecas compartilhadas. Fazemos empacotá-los todos em uma jóia, mas ao invés de usar um servidor jóia que mantê-los no controle de origem, e em seguida, construir a gema (usando newgem) e instalá-lo localmente como necessário.

A desvantagem dessa abordagem é que leva dois comandos em vez de um para instalar a gem, mas esta é largamente atenuado em ambientes qa e de produção, uma vez que usar Capistrano para implantação.

Os upsides são de que é simples morto, e em desenvolvimento há um ciclo editar / build / deploy muito curto, se você está trabalhando com algo que requer mudanças na jóia. Atualmente estou puxando um monte de funcionalidade comum para a gema compartilhada, então eu estou realmente apreciar esse aspecto.