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

Question

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

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

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

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

Другие идеи?

Спасибо ....

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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