compartir código ruby ??dentro de una organización

Question

Mi equipo y yo estamos empezando a crear algunos scripts reutilizables. Son reutilizables dentro de nuestra organización solo cuando trabajan con aplicaciones propietarias y nuestro entorno de servidor particular. Así que no es realmente adecuado para Rubyforge o Github, etc.

Mi pregunta es, ¿cuál es la mejor práctica para asegurarnos de que todos estamos usando las últimas y mejores secuencias de comandos de todos los usuarios? Prácticamente ejecutamos estos scripts en un servidor, pero es posible que debamos expandirnos a otros.

¿Deberíamos agruparlos en gemas (s) e iniciar un servidor de gemas privado?

O algo más simple como un directorio lib común que se puede compartir. Quizás con un script para descargar / actualizar desde nuestro SCM?

¿Otras ideas?

Gracias ....

Answer 1

Esto depende de algunos factores, como la cantidad de personas que desean cambiar el código (solo tu equipo u otra persona también) o la cantidad de dinero que tienes para esto.

Personalmente crearía un servidor build + gem, donde puede cargar los scripts usando algún sistema de versiones (como git o svn, depende de cuánta gente esté trabajando en el proyecto), y luego crear un trabajo cron, que generaría automáticamente las gemas de las fuentes a intervalos genéricos y las almacenaría como versiones diferentes. De esta manera, puede estar seguro de que siempre tiene un servidor autorativo que almacena las gemas de sus aplicaciones y siempre puede obtener una versión anterior si algo se rompe. Su secuencia de comandos podría crear nombres de versiones de gemas separadas, como " appserv-edge " o " appserv-stable "

También puede consultar las opciones de código cerrado de Github, si tiene el dinero para pagar eso. Sin embargo, no sé si tienen instalaciones de creación de gemas y hospedaje para programas que no sean de código abierto.

Answer 2

He creado un gemserver privado y es muy fácil. Lo único difícil es decidir cómo quieres que tus usuarios carguen gemas. Personalmente, solo uso un formulario de carga de PHP y lo verifico para asegurarse de que no esté ocultando ninguna gema existente.

Answer 3

En mi oficina estamos usando un poco de un enfoque híbrido para algunos de nuestros scripts y librerías compartidos. Los agrupamos todos en una gema, pero en lugar de usar un servidor de gemas los mantenemos en el control de origen, y luego construimos la gema (usando newgem) y lo instalamos localmente según sea necesario.

La desventaja de este enfoque es que se necesitan dos comandos en lugar de uno para instalar la gema, pero esto se mitiga en gran medida en los entornos de producción y qa, ya que utilizamos Capistrano para la implementación.

La ventaja es que es muy simple, y en desarrollo hay un ciclo muy corto de edición / creación / implementación si está trabajando con algo que requiere cambios en la gema. Actualmente estoy incorporando una gran cantidad de funciones comunes a la gema compartida, así que realmente aprecio ese aspecto.