Re: Подскажите инструментарий для file release system.
> Предприятие занимается разработкой ПО и имеет множество внутренних
> библиотек/модулей, которые, для поддержания модульности, релизятся
> (в настоящий момент) на FTP для возможности использовать
> другими проектами.
>
> С доступом на чтение все просто - анонимный доступ через FTP/HTTP, etc.
>
> А вот запись на FTP посредством прошитого логина/пароля в скрипт сборки
> совсем не нравиться...
>
> После гугления и вопросов на stackoverflow и comp.software.config-mgmt
> пришел к выводу что бы избавиться от хранения логина/пароля
> можно воспользоваться scp/sftp и открытыми ключами.
>
> Но как то мне не ясно каким образом разделять права на запись
> между различными проектами различным персонам...
>
> Не создавать же отдельную группу пользователей для каждого проекта и +s
> на корневой каталог?
>
>
> Я также подумал об использовании SVN для хранения результатов сборки
> (в основном это бинарные файлы).
>
> Мне кажется в этом случае получаем рад преимуществ:
>
> * синтаксис svn.authz интуитивно понятен, права описаны в одном
> месте и очень компактно
> * аутентификация из существующего LDAP
> * пароли кешируються встроеным менеджером клиента SVN
>
> Собственно резумируя - посоветуйте или пните в соответствующее
> направление по теме каким образом можно организовать релиз файлов
> на некоторый сервис с удобным разграничением доступа.
В принципе, идея с Subversion достаточно грамотная. Мне, однако, все время
лень настраивать HTTP-вариант, и я предпочитаю ssh. Ну и кроме того, я сейчас
предпочитаю распределенные VCS, из которых, если хочется попроще, лучше брать
mercurial. Из централизованных - да, я бы брал Subversion.
У нас предприятие было маленькое, и в итоге всё свелось к тому, что от
разграничения прав один геморрой, поэтому всё свелось к ssh и одной группе
разработчиков. Маленькое - это полтора десятка человек, которым нужен этот
доступ, и примерно столько же проектов. Практика показала, что почти в каждый
проект может потребоваться коммит почти от любого разработчика. Поэтому
технические средства разграничения только мешали - в конце концов, не
трехлетние дети работали, интеллекта не коммититься куда не надо людям
хватало.
В нынешнем предприятии, насколько я понимаю, ситуация примерно та же, хотя
народу существенно больше. Даже систем версионирования принципиально
различных используется больше двух. Но доступ не разграничивают, потому что
не нужно. Ошибочные коммиты встречаются, но их несложно откатить, а
разграничение прав предотвращает не больше половины ошибочных коммитов.
--
Functional programming is like describing your problem to a
mathematician. Imperative programming is like giving instructions to
an idiot.
-- arcus, #scheme on Freenode
Reply to: