Столкнулись с такой проблемой - ведется разработка ПО, которое потом используется на 8+ компьютерах. Часть из них работает под Linux, часть - под Win. Компоненты, настройки и базы данных могут несколько отличаться(а могут быть идентичными). При внесении изменений нужно обновить ПО на каждом из хостов, причем где-то нужно добавить что-то в базу или скопировать те или иные модули, внести изменения в конфигурационные файлы...одним словом, выполнить достаточно нудную и рутинную задачу. А тут еще и 8 раз! А если еще и не один раз в месяц, а больше? Становиться совсем грустно:)
Поискав в Интернете, я обнаружил, что существует целый класс ПО, предназначенного для решения подобных задач: SSDS(Secure Software Distribution System), что может переводиться как безопасная система распространения программного обеспечения. Первое, что мне попалось под руку, оказалось Tivoli. Хорошо, но слишком глобально для нашей задачи, да и не так и дешево. Я так же нашел несколько SSDS, созданных на perl: SEREDS и NRS. Последний, судя по всему, уже не развивается, SEREDS все еще показывает какую-то активность.
Хотел узнать, кто сталкивался с задачами подобного рода и каким образом они решались? Просто мы сейчас стоим перед тем, что, скорее всего, сами займемся разработкой SSDS системы на perl, но не хотелось бы изобретать очередной велосипед:) Вот и решил высказать мысли вслух перед сообществом.
и все же насколько сильные отличия?
И все же насколько сильные отличия?
- если у вас например все линуксы одинаковые, то конечно очень сильно выиграете, еще хороший вариант если отличия на уровне diff.
Я видел, в крупных компаниях, где много UNIX часто используют CVS/SVN для хранения конфигов/скриптов и для разработки.
- Общая схема довольно простая: создается общий репозиторий и плюс под личные настройки каждой машины делается отдельная ветка (branch) или совсем отдельное дерево в общем репозитории.
Главный смысл и общая идея что в случае отказа машины просто делается откат на предыдущую рабочую конфигурацию или автоматическое скачивание всех скриптов и конфигов из репозитория, аналогично поступают с обновляющимся софтом, правда для софта часто делают одно общее дерево.
Второй смысл что коммиты (изменения) делаемые в главном репозитории часто идут не напрямую а обязательно через координатора, который обязательно просматривает их и может не пропустить, тогда делается откат, плюс система требует чтобы с одним файлом всегда работал только один человек.
То есть механизм такой: прежде чем чего-то менять девелопер лочит какой-то файл, скачивает себе копию, изменяет, отсылает diff (коммит), снимает лок, если другой хочет править этот файл то он просматривает (и может рецензировать) diff, лочит этот файл и тд, затем приходит координатор, и чего-то пускает а чего-то не пускает..
В распределенных системах файлы не лочат, а только при слиянии всех ветвей идет тяжелая работа по выявлению и разрешению конфликтов.
По необходимости можно сделать чтобы каждая машина автоматически периодически проверяла обновления (cvsupdate) и либо сообщала админу что нужно произвести обновление, либо даже полностью сама обновилась и перезапустила соответствующие сервисы.
Наиболее развитые системы xBSD (FreeBSD,NetBSD,OpenBSD,.. там весь софт в "портах" с открытым кодом (и не только)), debian linux, gentoo linux (у генту вообще система почти копия freebsd).
В unix для приложений обычно применяется CVS, в разработке ПО сейчас больше любят SVN, но вобщем там не очень принципиальные отличия для простой модели разработки (например, в SVN есть понятие пакета всех изменений с версии n до m, не помню как называется, а в CVS нет, но вроде реализуется внешними программами и еще в SVN принципиально все делается в UNICODE а в CVS каждый устанавливает собственные правила).
В крупных open source програмных проектах на определенном этапе уходят от централизованной схемы к распределенным системам контроля версий, где каждый девелопер работает с отдельной копией общего дерева и все периодически синхронизируются, но тут проблема что в централизованной схеме _каждый_отдельный_коммит_ проверяется отдельно, и часто не одним человеком, а в распределенной коммиты проверяются только при слиянии в релиз, то есть выше вероятность что пролезут баги.
Короче, есть подозрение, что системы контроля версий есть надмножество SDS, при этом активно используются и развиваются везде, а SDS используются только в некоторых enterprise, причем по большому счету SDS дублируют часть функций решаемых системами контроля версий, и соответственно SDS вымирает как ненужный вид.
Есть правда нюанс с системами контроля версий
Есть правда нюанс с системами контроля версий, что не все умеют делать двоичные диффы, то есть когда надо хранить не сильно измененные двоичные файлы, большинство систем сохраняет в новой версии не diff а файл целиком, плюс нельзя увидеть что именно изменилось. Но вобщем это можно решить надстройками.
Мы как раз
Мы как раз завязаны на бинарных файлах, так как нужно распространять уже готовое приложение. rsync был первой мыслью:)