Синхронизация среды производства и разработки

Question

У меня есть веб-приложение на моем компьютере и на веб-сервере с ssh. Проблема в том, что я разрабатываю приложение локально на своем компьютере и хочу синхронизировать его с сервером, а не копировать файлы через ftp. Есть ли другой путь? мерзавец?

Answer 1

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

Git (и SVN, и Mercurial, и т. Д.) Отлично подходит для контроля версий, но для синхронизации систем часто требуется нечто большее, чем просто контроль версий. Если вы человек типа Python, вам может понравиться чтение Инструментов современного хакера Python: Virtualenv, Fabric and Pip . Это говорит о синхронизации не только кода, но и всей вашей среды.

Чтобы просто синхронизировать файлы на двух системах, я рекомендую rsync . Я использую это для всех видов задач, как на одной машине, так и для резервного копирования / синхронизации каталогов между машинами. У нас есть клиент в SoCal, где мы реализуем трехуровневую стратегию резервного копирования (2 на сайте, 1 вне сайта) с объемом данных более 5 терабайт, и в основе его лежит rsync и rsnapshot .

Обновление для комментария:

Неважно, на чем написан ваш сайт, вы все равно должны убедиться, что все ваших изменений дойдут до производства. Это часто многоэтапный процесс. Fabric специально разработана для того, чтобы инкапсулировать эти шаги и сводить их к одной команде. Pip и virtualenv более специфичны для Python для записи дополнительных изменений библиотеки и т. Д., Но Ruby / Rails, вероятно, имеют нечто эквивалентное. Цель состоит в том, чтобы иметь единственную команду все , необходимую для перехода от разработки к этапам, и еще одну команду для перехода от подготовки к производству.

Предостережение: не делайте , а не , для автоматической синхронизации прямо с вашего компьютера в рабочий каталог. Всегда сначала переходите в промежуточный промежуточный каталог на рабочей машине . Почти наверняка, что эти две машины не имеют 100% идентичных сред, и то, что работает на dev, может вообще не работать на вашей рабочей машине. Лучше потратить лишнюю минуту или две на тестирование в стадии подготовки, а не вызывать ошибку 500 на всей производственной площадке.

Answer 2

У вас должна быть автоматизированная сборка из репозитория исходного кода как для вашей разработки, так и для производственных сборок.

У вас также должен быть автоматизированный сценарий для развертывания в средах разработки и производства.

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

Это верно независимо от того, какое программное обеспечение / окружение / инструменты вы используете.

Answer 3

Capistrano , изначально созданный для развертывания, в частности, приложений Rails, с тех пор был расширен для развертывания любых веб-приложений (так называемое развертывание без рельсов ).

После настройки рабочий процесс выглядит следующим образом:

1. Редактирование исходного кода программы.
2. Зарегистрируйте свои изменения и отправьте их в центральное хранилище (git / mercurial / svn / что угодно)
3. Запустите cap deploy в вашей программе.

Шаг 3 - это место, где происходит волшебство, и это то, для чего был построен Capistrano. Capistrano извлечет новую копию вашего кода из репозитория, скопирует этот код в новый каталог «release» (с именем что-то вроде 20091028230834, отметка времени) и, наконец, свяжет каталог current с вашей последней копией. В середине, это может запустить миграции, если они существуют. Вы остались с настройкой каталога, как это:

...deploy-to-path/current  ->  ./releases/20091028230834
...deploy-to-path/releases/
    20091028230834/
    20091028225623/
    ...    # You can configure the number of releases kept after deployment.
...deploy-to-path/shared/
    cached-copy/  # A cached copy of your repository, which Capistrano updates
    ...           # Any shared data, like file uploads, for your application.

Документация для Capistrano не велика. Им действительно нужен кто-то, чтобы прийти и написать это слаженно. Однако, по сути, вы пишете файл (deploy.rb) со следующей информацией:

• Где находится сервер? (например, www.example.com)
• Каковы ваши учетные данные ssh? (пользователь, пароль)
• Где хранится ваш код? (URL вашего хранилища)
• Где вы хотите код на сервере?

Для начала я предлагаю запустить capify в вашем приложении (предоставляя файлы по умолчанию) и запустить его на тестовом сервере (или в тестовом каталоге на сервере), чтобы посмотреть, что оно делает. Получив развертывание чего-либо, вы можете настроить его для дополнительного перемещения / символической ссылки.

Answer 4

Я бы обычно ожидал бы оставить git для вашей среды разработки.

Ваша сборка создаст некоторые развертываемые (а. tar.gz, возможно), указав тег для сборки (такой, что ваша сборка проверяется и повторяется), а затем вы скопируете это на свой сервер, используя ssh /scp.

Я бы не просто синхронизировал из среды разработки. Это нужно для разработки, для экспериментов, для поддержки инструментов и файлов и т. Д.

Answer 5

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

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

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