partage de code ruby ??au sein d'une organisation

Question

Mon équipe et moi-même commençons à créer quelques scripts réutilisables. Ils sont réutilisables au sein de notre organisation uniquement car ils fonctionnent avec des applications propriétaires et notre environnement de serveur particulier. Donc, ne convient pas vraiment à rubyforge ou github, etc.

Ma question est la suivante: quelle est la meilleure pratique pour vous assurer que nous utilisons tous les scripts les plus récents et les plus performants pour tous les utilisateurs? Nous exécutons ces scripts sur un serveur, mais nous devrons peut-être développer d'autres logiciels.

Devrions-nous les grouper dans des gemmes et démarrer un serveur de gem privé?

Ou quelque chose de plus simple, comme un répertoire lib commun et partageable. Peut-être avec un script à télécharger / mettre à jour à partir de notre GDS?

D'autres idées?

Merci ....

Answer 1

Cela dépend de certains facteurs, tels que le nombre de personnes voulant modifier le code (uniquement votre équipe ou une autre personne également) ou le montant d'argent dont vous disposez pour cela.

Personnellement, je créerais un serveur build + gem, où vous pourrez télécharger les scripts à l'aide d'un système de gestion de versions (comme git ou svn, selon le nombre de personnes travaillant sur le projet), puis créer un travail cron, générerait automatiquement les gemmes à partir des sources à des intervalles génériques et les stockerait sous différentes versions. De cette façon, vous pouvez être sûr que vous avez toujours un serveur faisant autorité qui stocke les gems de vos applications, et vous pouvez toujours obtenir une version antérieure si quelque chose se cassait. Votre script peut créer des noms de version de gem distincts, tels que " appserv-edge " ou "appserv-stable"

Vous pouvez également consulter les options de sources fermées de github si vous en avez les moyens. Cependant, je ne sais pas s'ils ont construit ou hébergé des pierres précieuses pour des programmes non ouverts.

Answer 2

J'ai créé un serveur de gems privé et il est extrêmement facile. Le seul problème qui se pose est de décider comment vous souhaitez que vos utilisateurs téléchargent des gemmes. Personnellement, j’utilise simplement un formulaire de téléchargement PHP et le fais vérifier pour ne pas masquer les pierres précieuses existantes.

Answer 3

Dans mon bureau, nous utilisons une approche plutôt hybride pour certains de nos scripts et bibliothèques partagés. Nous les regroupons tous dans une gemme, mais plutôt que d’utiliser un serveur de gem, nous les conservons dans le contrôle de source, puis nous construisons la gem (à l’aide de newgem) et l’installons localement si nécessaire.

L'inconvénient de cette approche est qu'il faut deux commandes au lieu d'une pour installer la gemme, mais cela est largement atténué dans les environnements de production et de production, car nous utilisons Capistrano pour le déploiement.

L’avantage, c’est qu’il est extrêmement simple et que, dans le développement, il existe un très bref cycle de modification / construction / déploiement si vous travaillez avec quelque chose qui nécessite des modifications de la gemme. Je tire actuellement beaucoup de fonctionnalités communes dans la gemme partagée, donc j'apprécie vraiment cet aspect.