13 ноября 2009 г.

Синхронизация файлов проекта в Eclipse c помощью rsync

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

Узким местом было монтирование директории development-сервера на свою рабочую станцию. При этом получалось, что все операции с файлами, особенно ресурсоемкая работа с репозиторием (в нашем случае svn), происходила непосредственно на примонтированном разделе. При плохом коннекте бывали случаи, когда примонтированная директория вообще отваливалась, а так как workspace нашего любимого IDE предполагалось хранить также удаленно, его дальнейшее поведение нельзя было назвать самым стабильным.



На новую идею нас натолкнула статья Сергея Чикуёнка об автоматическом копировании файлов в Eclipse с помощью плагина FileSync. Идея заключается в том, чтобы хранить все свои проекты и workspace на своей рабочей машине, а синхронизироваться с dev-сервером автоматически с помощью, например, rsync.

Теперь чуть более подробно о реализации. Так как мы используем Eclipse, расскажу на его примере. Автоматическое выполнение каких-либо команд после любых операций с файлами можно добиться с помощью создания Builder'a (Project -> Properties -> Builders):

1

Выбираем Program и создаем новый билдер со следующей командой:
/usr/bin/rsync
-u -r --progress
--exclude=".svn"
--exclude="img/upload/"
/${workspace_loc}/${project_name}/
${username}@${username}.example.com:/var/www/${username}.example.com/${project_name}/

3

Параметр -u позволяет синхронизировать только те файлы, которые изменились; -r - рекурсивная синхронизация; если хотите наблюдать процесс синхронизации в табе Console, то оставьте --progress.

С --exclude=".svn" все должно быть понятно, а вот --exclude="img/upload/" нужен для того, чтобы не затирать файлы, которые вы заливаете через свои скрипты.

${username}.example.com -- адрес вашего dev-сервера. ${workspace_loc} и ${project_name} переменные, о которых по умолчанию знает Eclipse, а ${username} - задается нами (Variables... -> Edit Variables...):

2

Теперь для автоматического срабатывания процесса перейдем на вкладку Build Options и отметим параметры During auto builds и, если хотите, Allocate Console:

4

Так как rsync работает по протоколу ssh, то для него остаются актуальными authorized_keys (будет синхронизироваться без ввода пароля) и компрессия (параметры: --compress, --compress-level=NUM).

В итоге мы получили возможность синхронизации по протоколу ssh файлов своих проектов с сервером разработки, что нам может позволить  отказаться от монтирования директорий. Данная заметка не претендует на свою универсальность, так как жестко привязана к Eclipse, но мне кажется, что в других IDE ситуация с билдингом проектов похожая. Для тех, кому приходится работать под MS Windows придется потратить на настройку чуть больше времени, так как rsync нужно будет устанавливать через Cygwin и немного поковыряться с русскими названиями файлов, c Mac OS X проблем не будет.

5 комментариев:

  1. Пытался когда то реализовать подобную схему, но отказался от неё, т.к. синхронизаторы в начале работы выкачивать сотни мегабайт картинок и прочего мусора.

    В итоге не стал заморачиваться и настраивать исключения, а просто нашел нормального провайдера -)

    ОтветитьУдалить
  2. А почему не использовать VCS.. к примеру GIT

    ОтветитьУдалить
  3. Вы изобретаете велосипед. Почему бы не использовать maven2 и не генерировать eclipse проекты для каждого пользователя на месте из файла описания проекта?

    ОтветитьУдалить
  4. Интересно, надо будет взять на заметку. Хотя лично меня вполне устраивает в Ant'е. rsync это уже более продвинутая вещь.

    ОтветитьУдалить
  5. Павел Воробьев14 ноября 2009 г., 14:32

    Александр,как только у нас будет более серьезная работа с ветками, я думаю, мы перейдем на распределенные системы контроля версий.


    Кстати git сильно быстрее работает при коммитах и чекаутах на примонтированной директории, чем svn.


    Santa, никогда раньше не слышал про maven, возможно, потому что он заточен под java. Но ознакомившись с ним сейчас, понимаю, что это совсем другое. Если я не прав, поправьте меня, но maven никак не может лучше решить проблему описанную в первых двух абзацах, чем rsync.

    ОтветитьУдалить