совместное использование кода ruby внутри организации

Question

Я и моя команда начинаем создавать несколько сценариев многократного использования.Их можно повторно использовать в нашей организации только в том случае, если они работают с собственными приложениями и нашей конкретной серверной средой.Так что не совсем подходит для rubyforge, github и т.д.

Мой вопрос в том, какова наилучшая практика для обеспечения того, чтобы все мы использовали новейшие и лучшие скрипты для всех пользователей?В основном мы запускаем эти скрипты на одном сервере, но, возможно, потребуется расширить их на другие.

Должны ли мы объединить их в gem (ы) и запустить частный gem-сервер?

Или что-то более простое, например, общий каталог lib, доступный для совместного использования.Возможно, с помощью скрипта для загрузки / обновления из нашего SCM?

Другие идеи?

Спасибо....

Answer 1

Это зависит от некоторых факторов, например, сколько людей хотят изменить код (только ваша команда или кто-то еще), или сколько у вас на это денег?

Лично я бы создал сервер build + gem, куда вы могли бы загружать скрипты, используя какую-нибудь систему управления версиями (например, git или svn, зависит от того, сколько людей работает над проектом), а затем создал задание cron, которое автоматически генерировало бы gems из источников через определенные промежутки времени и сохраняло бы их как разные версии.Таким образом, вы можете быть уверены, что у вас всегда есть сервер авторизации, на котором хранятся драгоценные камни ваших приложений, и вы всегда можете получить более раннюю версию, если что-то сломается.Ваш скрипт может создавать отдельные имена версий gem, например "appserv-edge" или "appserv-stable".

Возможно, вы также захотите ознакомиться с опциями github с закрытым исходным кодом, если у вас есть деньги, чтобы позволить себе это.Однако я не знаю, есть ли у них средства для создания gem и хостинга для программ без открытого исходного кода.

Answer 2

Я создал частный gemserver, и это чертовски просто.Единственная сложность заключается в том, чтобы решить, как вы хотите, чтобы ваши пользователи загружали драгоценные камни.Лично я просто использую форму загрузки PHP и проверяю ее, чтобы убедиться, что она не маскирует какие-либо существующие драгоценные камни.

Answer 3

В моем офисе мы используем немного гибридный подход для некоторых наших общих скриптов и библиотек.Мы объединяем их все в gem, но вместо того, чтобы использовать сервер gem, мы храним их в системе управления версиями, а затем создаем gem (используя newgem) и устанавливаем его локально по мере необходимости.

Недостатком этого подхода является то, что для установки gem требуется две команды вместо одной, но это в значительной степени смягчается в qa и производственных средах, поскольку мы используем Capistrano для развертывания.

Плюсы в том, что это предельно просто, и в разработке существует очень короткий цикл редактирования / сборки / развертывания, если вы работаете с чем-то, что требует изменений в gem.В настоящее время я добавляю много общих функций в общий gem, так что я действительно ценю этот аспект.