Это хорошая идея, чтобы установить Mercurial на свой сервер и hg pull для развертывания?

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

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

Итак, сейчас мы так работаем:

º----------BitBucket
º---------/
º--------/

Я и три других разработчика hg pullиз BitBucket вносим наши изменения, затем hg pushв BitBucket.

Теперь для развертывания кому-то понадобится отправить последние файлы по FTP на рабочий сервер.

Я думал об установке Mercurial на наш сервер и использовании hg clone(впоследствии hg pull) для поддержания версий в актуальном состоянии.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Это хорошая идея? Какие-нибудь потенциальные подводные камни, которые я, возможно, не вижу? Кто-нибудь здесь делал что-то подобное? Как развернуть большое приложение на PHP-фреймворке (мы используем Moodle)?

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

Единственная проблема может возникнуть, когда в вашей базе кода есть конфиденциальная информация (например, ключи API и т. Д.), Которую вы не хотите загружать на сторонние серверы (в вашем случае это будет Bitbucket). В этом случае простой сценарий, запускаемый после извлечения данных из хранилища для восстановления конфиденциальных данных в нужном месте, решит эту проблему.

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

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

Другая (на мой взгляд, лучшая) возможность: использовать сервер сборки / сервер непрерывной интеграции.

Краткое краткое объяснение: это сервер (может быть собственным, не обязательно должен быть в Интернете), который вы настроили для мониторинга своих репозиториев, и всякий раз, когда в репозиториях появляются новые наборы изменений, сервер создает ваш код ( AFAIK это не обязательно в PHP) , запускает модульные тесты и развертывает ваш код на веб-сервере.

Для получения дополнительной информации, проверьте эти ссылки:

• Статья про КИ из Википедии
• Вопрос переполнения стека: в чем смысл «сервера сборки»?

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

Альтернативное дешевое решение:

Если настройка сервера сборки требует слишком больших усилий или вы хотите больше контролировать, когда именно ваш сайт развернут, просто настройте файл сценария (Batch / Powershell в Windows или что-то подобное в Linux / Mac), который тянет новейшая версия из вашего хранилища и FTP-файлы на рабочем сервере.

По сути, это то же самое, что сервер сборки, только проще.

Независимо от того, как именно вы решите это в конце концов ... обязательно как-то его автоматизировать!

Вы хотите иметь возможность развертывания одним кликом / вводом одной команды, чтобы ВСЕ могли делать это, не зная ничего особенного, и не совершая ошибок - даже в случае аварии или стресса.

Мы делаем это или подобные вещи. Неатомный @johannes упоминает угол - одна из проблем, хотя в реалистическом смысле это происходит так быстро, что все должно быть в порядке, и, как он указывает, есть способы обойти это.

Вероятно, более важным, чем эта неатомичность, было бы «как вы управляете обновлениями схемы базы данных» - такое развертывание плохого кода облегчает исправление. Большая проблема возникает при развертывании обновления, которое изменяет базу данных, которую вы хотите откатить. Или если вы делаете плохие обновления и портите данные.

Другая проблема, с которой мы столкнулись при использовании инструментов DCVS (в отличие от использования SVN), заключается в том, что теперь у вас есть копия всей кодовой базы на компьютере, где злоумышленник потенциально может получить доступ. А также то, что эта кодовая база DCVS может получить довольно большой размер, что может иметь значение, если вы платите за хранение и / или резервное копирование. Мы все еще используем SVN для окончательного развертывания по этим причинам.

Это отличная идея, однако имейте в виду следующее:

• Старайтесь не фиксировать на сервере (хотя в некоторых редких случаях имеет смысл сделать это, например, установить плагин или добавить ресурсы контента)
• Используйте промежуточный сервер или развертывание вторичного репозитория для тестирования
• Будьте всегда осторожны, чтобы hg update -Cне повлиять на работу (т.е. удалить важные файлы)
• Иметь производственную и развивающую ветку, только развернуть производственную ветку
• Обрабатывать активы как резервную копию (например, изображения для контента) и игнорировать пользовательские данные (например, вложения / загрузки, кэш и т. Д.)
• Всегда иметь чистый hg statusвывод на сервер (это поможет вам убедиться, что вы игнорируете вещи как кеш)
• Не размещайте репозиторий в веб-папке. Используйте символические ссылки вне публичного пространства (например, ln -s / myrepo / src / web / public_html / myapp)
• Будьте осторожны, чтобы не изменять конфигурационные файлы (особенно с паролями базы данных или другими)
• Не используйте вместо производственной резервной копии, это резервная копия для производственного кода , а не для производственных данных.

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

У меня несколько сайтов взламывали несколько раз, поскольку Mercurial помогает мне буквально отменить эти взломы, просто выполнив команду hg update -Cна сервере (конечно, вы можете захотеть сделать hg statusи получить уязвимые файлы для последующего анализа).