Синхронизация рабочего пространства веб-разработчика



Доброго времени суток, Хабр!

Недавно я озадачился синхронизацией рабочего пространства среди всех используемых мной компьютеров. Я понял, что таскать все файлы и базы данных сайта с одного компьютера на другой, не вариант. Решив автоматизировать этот процесс, я обратил внимание на Dropbox \ Google Drive \ Yandex.Disk \ любой другой облачный диск ( выбрать свой вариант ).

Первым делом я подумал о GIT ( bitbucket, github ), но с ним очень проблематично синхронизировать базы данных. Тем более хотелось полностью автоматического решения. Поэтому этот вариант отпал.

Для начала я решил поискать некий сервис, который выполнил бы все необходимые мне действия, в том числе:

  • Синхронизация рабочих файлов сайтов ( PHP, HTML, CSS, etc ) таким образом, чтобы они могли редактироваться на обоих системах ( Windows, Mac )
  • Синхронизация баз данных
  • Синхронизация настроек IDE, плагинов и сниппетов
  • Возможность локальной работы, без интернета. Поэтому были исключены многие онлайн сервисы, такие как koding.com.
  • Возможность синхронизации через используемый мной облачный диск Google Drive


Потратив пару часов на поиски, я так и не нашел ничего подходящего. Но в процессе наткнулся на множество инструкций и гайдов по синхронизации рабочего пространства через Dropbox и ему подобные. Не найдя другого способа, я так же решил попробовать данное решение.

К сожалению, ни одна статья не имела исчерпывающих инструкций по всем интересующим меня пунктам. Так же, в процессе я наткнулся с немалым количеством проблем, которые и вовсе не были освещены.

Первым делом нужно было определиться со стеком инструментов. Я использовал пакет Денвера, для разработки под Windows и MAMP для работы на Mac OSX. К сожалению, эти инструменты плохо совместимы, и я решил поискать им альтернативу. Хотелось найти кросс-платформенное решение, которое исключило бы конфликт версий. Изначально я планировал использовать XAMPP, но при попытки его настройки возникли проблемы.

image

После недолгих поисков я наткнулся на AMPPS

Преимущества:
  • Кроссплатформенный( Windows, Mac OSX )
  • Бесплатный
  • Удобный интерфейс запуска и настройки сервера
  • Полная синхронность версий PHP, MySQL и других. Обновление в один клик
  • Отличный web-интерфейс, с кучей возможностей. Например, установка любой CMS или фреймворка.
  • Поддержка MongoDB ( мне он не нужен, но вдруг кому-то необходим )

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

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

image

Необходимо зайти в раздел Apache, и выбрать пункт Configuration. Откроется конфигурационный файл, в котором нам надо найти и изменить строчку

# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "D:\путь\к вашему\облачному диску"

Следующим действием нужно синхронизировать базу данных. Здесь было больше всего проблем и конфликтов. Для того, чтобы использовать синхронизацию, нужно изменить конфигурацию. Заходим в панель, кликаем MySQL и выбираем пункт конфигурация. Далее ищем и меняем строчку:

# Replication Master Server (default)
# binary logging is required for replication
#log-bin=mysql-bin

Необходимо закомментировать логирование MySQL, т.к. из-за него происходили сбои и конфликты. Далее нужно синхронизировать сами базы. Для этого мы переходим в папку AMPPS\mysql. Нужно сделать символическую ссылку на папку data и связать ее с папкой в облачном диске. Для этого открываем консоль:

Для первой машины, Windows:

cd “C:\путь\к\AMPPS\mysql”
mkdir "D:\путь\к\облачному\диску\mysql"
mv data “D:\путь\к\облачному диску\Sublime\User”
cmd /c mklink /D data "D:\путь\к\облачному\диску\mysql\data"


Для каждой последующей, Windows:

cd "C:\путь\к\AMPPS\mysql\"
rmdir -recurse data
cmd /c mklink /D data "D:\путь\к\облачному\диску\mysql\data\"


Для первой машины, MacOSX:

cd ~/Application/AMPPS/mysql/
mkdir ~/путь/к папке/облачного диска/mysql/
mv data ~/путь/к папке/облачного диска/mysql/
ln -s /путь/к папке/облачного диска data


Для каждой последующей машины, MacOSX:

cd ~/Application/AMPPS/mysql/
rm -r data
ln -s /путь/к папке/облачного диска data


Теперь ваши базы данных синхронизированы. Для создания нового сайта, нужно пройти в web-панель управления, адрес localhost/ampps. Далее в раздел Add domain. Главное, что нужно заполнить правильно в данном разделе — Domain path. Указываем здесь папку в облачном диске, созданную в той же директории, куда был прописан DocumentRoot Apache. Эту процедуру нужно проделать для каждой машины. После этого у вас будет доступен полностью синхронный проект.

Последним пунктом, я хотел синхронизировать проекты, настройки и плагины для моего любимого IDE Sublime text. В данный момент я использую 3 версию. Для правильной синхронизации необходимо синхронизировать только папку Packages/User, т.к. для каждой OS, может быть своя версия плагина. А в таком случае, будет синхронизирован список плагинов ( нужно заранее установить Package Control ), и правильная версия загрузится автоматически.

Для первой машины, Windows:

cd "$env:appdata\Sublime Text 3\Packages\"
mkdir “D:\путь\к\облачному диску\Sublime”
mv User “D:\путь\к\облачному диску\Sublime\User”
cmd /c mklink /D User “D:\путь\к\облачному диску\Sublime\User”


Для каждой последующей, машины Windows:

cd "$env:appdata\Sublime Text 3\Packages\"
rmdir -recurse User
cmd /c mklink /D User “D:\путь\к\облачному диску\Sublime\User”


Для первой машины, MacOSX:

cd ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/
mkdir ~/путь/к папке/облачного диска/Sublime
mv User ~/путь/к папке/облачного диска/Sublime
ln -s ~/путь/к папке/облачного диска/Sublime/User


Для каждой последующей машины, MacOSX:

cd ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/
rm -r User
ln -s ~/путь/к папке/облачного диска/Sublime/User


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

Прежде чем написать этот пост, я провел тестирование данного способа синхронизации. Были написаны 3 проекта, от начала и до конца. Лишь единожды произошел сбой базы данных и не значительная потеря данных. С 90% вероятностью, причиной этому был мой косяк в коде. Скорость и удобство синхронизации покрывает всю мороку с настройкой и позволяет значительно улучшить поток работы.
Поделиться публикацией

Комментарии 54

    +2
    Возможность локальной работы, без интернета. Поэтому были исключены многие онлайн сервисы, такие как koding.com, а так же системы контроля версий.


    Не вижу зависимости между «локальной работой» и «системами контроля версий».

    Я успешно использую тот же git (bitbucket) для поддержки репозиториев кода и конфигов. И работаю локально.
      0
      Я тоже сразу подумал о git'e, когда столкнулся с данной задачей. Но синхронизировать базы там гораздо сложнее, если вообще возможно. Плюс требуется постоянно делать комиты и пуши. Мне кажется для соло разработчика это решение лучше.
        0
        Всё зависит от размера базы. Относительно небольшие можно хранить просто как sql-дампы в системе контроля версий. Благодаря этому появляется версионность базы и полная синхронность с исходниками. А если использовать mercurial, в репозиторий сохраняются только diff'ы.
          0
          Т.е. сценарий, когда я внес изменения в базу, сделал дамп, запушил на одной машине, потом запулил на другой, а еще залил дамп и перегрузил базу, вы считаете лучшим, чем полностью автоматическая синхронизация за считанные секунды?
            0
            Если делать это всё вручную, то звучит достаточно долго, хотя на практике занимает не больше минуты. Но это всё можно автоматизировать, чтобы надо было только скрипт запустить. Просто как я понял, в вашем варианте нет версионности базы и если нужно откатиться на предыдущую версию или на соседнюю ветку, то можно папасть в неработоспособную среду.
            Кстати для версионирования базы есть отдельные, более автоматизированные, решения. Тут даже на хабре пару раз писали. Мне просто не очень часто приходится базу синхронизировать, поэтому автоматизацией этого процесса особо не занимался.
              0
              Вообще для этого существуют миграции баз данных. Плюс еще на сервер деплоить становится проше
                0
                с помощью hook-ов git-а можно настроить автовыгрузку и автозагрузку базы из дампа
          +2
          Читая подобные статьи понимаю, что выбор ноутбука в качестве основного рабочего инструмента был верным решением 8 лет назад и остается им до сих пор.
            0
            Носить с собой ноутбук не всегда удобно. Мне вот лично до работы сейчас поболее часа добираться.
            Постоянно таскать с собой ноут по городу/метро — то ещё удовольствие.

              +1
              А я вот за 5 лет уже начинаю подзадалбываться каждый день на работу с сумкой ходить…
                0
                сервер(а) на линоде/диджитал оушен + mba + 4г хотспот — вот оно счастье
                  0
                  Воздух легок, но к нему 3 монитора не подрубить без бубна
                    0
                    Я сторонник одной 30ки.
                0
                Как показывает практика, для разработки в связке Apache/PHP под мак какие-то готовые стеки подходят не очень, учитывая наличие встроенного в ОС веб-сервера. Сборка и подключение расширений проходят как танец с бубном.

                И мне так же, как и bvn13, думается, что разница между git и G drive при оффлайн-работе минимальна. К тому же в системе контроля версий мержить можно ручками, а как разрешать конфликты настолько же гибко в облачных папках мне неизвестно.

                Upd. не туда, простите.
                  +1
                  Каждый делает выбор основываясь на своих специфических требованиях, которые могут включать очень большое количество различных факторов. И ноутбук далеко не таблетка от всех болячек для программиста.
                  Как по мне так это вообще костыль: Испытывать дискомфорт в размере монитора и размерах клавиатуры постоянно + перемещение его, и его комплектации за собой постоянно (личный транспорт конечно убирает большую часть этого неудобства)…
                  Как по мне, задачу синхронизации можно решить более качественно ;)

                  Я уже молчу, про соотношение цен на эквивалент по мощности для стационарного компа с хорошими, если не топовыми характеристиками…
                    0
                    Я периодически синхронизирую данные между ноутбуком и обычным компом )
                      +3
                      Начав работать на 2х мониторах full HD, я понял как же я ошибался работая на ноутбуке.
                        0
                        К ноуту можно и 3 монитора подключить.
                      +5
                      Все что нужно — GIT и поднятный локальный сервак на всех машинах, на которых ведется разработка (точнее на тех, где необходимо обеспечить возможность работать в оффлайне). Вы какой-то чушью занимаетесь, ей богу. 2013 год на дворе.
                        0
                        Вся фишка в автоматизме. А еще в синхронизации базы данных.
                          0
                          Мы на разных языках говорим. Извините.

                          Ключевые слова для гугла: репликация баз данных, git.

                            0
                            Действительно на разных. Повторюсь, дело в автоматизации процесса. Согласитесь, как альтернатива такое решение имеет право на существование?
                              0
                              Как плохая альтернатива — имеет.
                              Для синхронизации файлов — есть git, для синхронизация баз — штатные средства БД. Вы для этого используете инструмент, который предназначен для другого.

                              В чем выгода-то?

                              Вы совершенно определенно работаете в гордом одиночестве, и притягиваете на разные машины одни и те же собственные правки. То есть вероятность конфликтов правок стремится к нулю. Можно и с помощью GIT автоматическое притягивание изменений сделать, если уж сильно приперло. Думаю я не один такой, для кого git pull origin master при начале работы — как руки перед едой помыть.

                              Дело то ваше, конечно. Нравится так синхронизировать — ну и здорово. Только все равно при появлении еще хотя бы одного разработчика или верстальщика придется переходить на GIT, Dropbox там не спасет.

                              Повторюсь, для того, что вы делаете, существуют специально созданные для этого инструменты.

                                0
                                У облачных дисков миллион предназначений, в этом вся их соль. Да, это решение для соло разработчика. В команде, конечно только git.
                                  0
                                  Я, даже если пишу один, всё равно использую систему контроля версий (в моём случае — svn либо git).
                            0
                            тогда как вам такой вариант: выбрать компьютер с выходом в интернет без NAT, поднять на нем OpenVPN-сервер, на всех рабочих машинах — клиенты. В проектах с базой работать через OpenVPN и делать регулярные дампы базы в архив. Результат: база всегда одна и едина.
                              0
                              Для синхронизации базы данных при разработке хорошо использовать фикстуры.
                              1. Вы никогда не потеряете данные
                              2. Вы всегда можете их обновить
                              3. Они контролятся тем же гитом
                              4. Можно делать разные фикстуры под свои нужды (к примеру тестовая база только для юнит тестов)
                            +1
                            У меня похожее решение, только я использую Open Server и установлен он у меня просто в папку с Дропбоксом. А так как при запуске сервера он создает себе виртуальный диск и запускается там — то не имеет значения где расположены файлы. За 3 года небыло никаких проблем при синхронизации, ни с файлами проэктов, ни с БД, ни с конфигами.
                              0
                              Классно! Жаль нету версии под MacOSX. В посте я описал именно кроссплатформенное решение.
                              0
                              И лучшее решение… барабанная дробь… флешка!
                                +1
                                Флешку нужно носить с собой, а если потеряете или испортите?
                                  0
                                  Ага приходилось работать с флешкой — тормоза еще те…
                                  +2
                                  Чтобы не настраивать рабочую среду на разных машинах, я установил всё под vmware и скопировал. На данный момент рабочая среда пережила уже одну смену компьютера и два падения жесткого диска. Ну а исходники и пр. через всякие bitbucket'ы.
                                    0
                                    А еще можно vagrant и образ в дропбокс положить
                                    +1
                                    Можно проще.
                                    Я создал шифрованный контейнер TrueCrypt, который монтирую как отдельный диск (такая виртуальная флешка). И все что нужно лежит в этом контейнере.
                                    Сразу решается несколько проблем:
                                    — Защита проекта стойким шифрованием (для параноиков)
                                    — Меньше возни с путями для файлов, в некоторых случаях можно использовать Portable-версии софта
                                    — Меньше глюков синхронизации.
                                      0
                                      Не вижу плюсов кроме шифрования. Софт будет разный ( Windows и MacOSX ), поэтому все равно нужно будет прописать пути, да и глюков может возникнуть даже больше. Но, да, идея интересная, я тоже думал о возможности все это соединить в один контейнер.
                                        0
                                        А что мешает завести один и тот же софт везде?
                                      0
                                      Годная конфигурация — флешка + vagrant + chef/puppet + git
                                      Все прелести использования dropbox и аналогов к сожалению перечеркивает один минус — они не умеют синхронизировать симлинки :(
                                        0
                                        А зачем синхронизировать симлинки? Они ведь созданы на машине, и указывают на диск, а не наоборот.
                                          0
                                          Если Ваш documentroot находится на облачном диске и Вы используете в нем симлинки для того, чтобы не плодить контент (например папки с картинками, файлами между frontend и backend), ожидайте неприятных сюрпризов.

                                          В моей практике также было, что dropbox очень качественно попортил локальный репозитарий git когда пришлось включить старый компьютер после 3-4 месяцев простоя.
                                        0
                                        bittirrent sync?
                                          0
                                          Нужно чтобы обе машины были включены. Такое бывает редко :)
                                          0
                                          Windows, Mac OSX — это еще не кросплатформенный, под линукс же нет %)
                                            0
                                            Как писали выше — репликация БД + git. Все люди так и работают.
                                            Однако, как вариант который иногда требуется — поднять свой маленький тестовый сервак, например на каком-нибудь WD MyBookLive, настроить ему DynDNS и работать откуда угодно если требуется именно реальный серв — он отовсюду будет виден одинаково. Проблема бэкапа решается, опять же, git + репликация БД.
                                              0
                                              А вот поделитесь опытом, как вы репликацию на трех машинах настраиваете (с учетом, что запись идет в локальный сервер БД)? В кольцо ее замыкаете?
                                                0
                                                Если для инфраструктуры включающей MyBookLive — тогда все более чем очевидно, головная база лежит на нем а он включен 24/7.
                                                Если для инфраструктуры без него, тогда головную базу оставляю на компе, за которым работаю большее время.
                                                На худой конец, никто не отменял возможность слить дамп БД в любой момент, что в принципе можно сделать одним кликом по скрипту.
                                                Все сугубо индивидуально.
                                                С недавних пор на работу поставили один небольшой серверочек на атоме, который также включен 24/7 (кушает мало, атом же), и для целей локальной синхронизации он решает все проблемы.
                                                Для файлов используем SugarSync, тариф на 100 GB, весь код в проектах лежит на bitbucket.
                                                Если что-то коряво объяснил — спрашивайте, уточню.
                                              +1
                                              Только вот с InnoDB таблицами при таком тупом копировании файлов, могут быть большие проблемы.
                                                0
                                                как бы в самой статье мало чего полезного, можно было двумя словами написать «делайте симлинки».

                                                В целом, проблема так и не решится, например, МАС и винда по разному работают с правами на файлы, а сайты то вообще в линуксе будут, даже если использовать ХАМРР на обеих машинах проблемы могут быть другого порядка, про AMPPS я не слышал, но если это не виртуальная машина, то легче не станет.

                                                Мой вариант такой:
                                                — VirtualBox с Linux + веб-сервер
                                                — некоторые даже в виртуалку ставят графическую систему с системами IDE + все остальное (например, Drupal quickstart)

                                                Если нужно экономить трафик, то есть 2 пути:
                                                — поискать где-то на хабре была статья про Dropbox trueCrypt в которой рассказано как настроить что бы обновлялись нужные части диска (не проверял, но может поможет)
                                                — в виртуальной машине сделать несколько дисков: система, базы данных, файлы. Ну и синхронизировать только нужные диски (систему только один раз синхронизировать и если на нее не ставит новый софт или делать настройки, то ее можно больше не синхронизировать)
                                                  0
                                                  Симлинками тут дело не ограничивается. Как минимум нужно еще отключить логирование :)

                                                  В целом, не понял о чем ваш комментарий, но проблема решена, и прежде чем написать сюда, я провел тестирование. Никаких проблем с правами на файлы не было, ведь каждая система имеет свою копию файлов. Виртуалка это такой кошмарный костыль, как по мне.
                                                    0
                                                    В чем заключается «костыльность» виртуалки? Вы ее использовали ранее?

                                                    Назначение виртуалки ПОЛНОСТЬЮ эмулировать сервер на котором будет работать ваш сайт, практически вы получаете копию сервера Linux на котором работает ваш сайт. Проблем при работе виртуалки даже в теории быть не может ибо мы переносите не часть системы, а всю систему. При этом данный подход будет работать не только в винде и МАС, но и в любом линуксе, везде где запустится VirtualBox и везде будет 100% одинаковая работа. Уточните в чем костыльность данного подхода.

                                                    Это Денвер в данном ракурсе костыль.
                                                      0
                                                      Конечно, использовал. Теперь когда вы мне объяснили, это не кажется таким плохим решением. Но все же является более комплексным, и подразумевает не слабые навыки работы как в линуксе так и в настройке виртуалки.
                                                  0
                                                  Просто хочу похвастаться. Вот недавно перешёл на такую схему: всё под контролем git, включая sql-дампы. Сохраняю не всю базу, потому что данные проще получить из сети на свежеустановленном рабочем месте (ну, такая специфика). Взятая VDS-ка является по сути сервером разработки, на который я отправляю изменения в репозитории. На рабочий сервер, кстати, всё шлёт скрипт deploy.sh (rsync), настраивает окружение setup.sh (права доступа на файлы и папки).
                                                  Раньше я был глупее и синхронизировал всю папку с проектом (вместе с .git) обычным дропбоксом.
                                                    0
                                                    Очень интересно, вам нужно написать пост об этом, он явно больше понравится про-кодерам =)
                                                  • НЛО прилетело и опубликовало эту надпись здесь

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое