Я только начал работать на новой работе в прошлом месяце и похоже, что они не имеют контроля над исходным кодом для своего кода. Они полагаются на резервные копии, которые их хостинг-провайдер берет для них.
Немного поговорив, я убедил своего босса, что мы определенно должны использовать систему контроля версий, и после того, как я провел небольшой семинар по этому вопросу, вся команда на борту; они любили 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вывод на сервер (это поможет вам убедиться, что вы игнорируете вещи как кеш)Наконец, я думаю, что наиболее ценной вещью для добавления DVCS в процесс развертывания является то, что это повысит безопасность вашего развертывания, иногда хакеры внедряют вредоносный код в ваши материалы, и у вас действительно нет возможности легко его обнаружить без чего-то вроде контроля версий ( специально распределенный, так как распределенный аспект VCS облегчает проверку целостности ваших файлов).
У меня несколько сайтов взламывали несколько раз, поскольку Mercurial помогает мне буквально отменить эти взломы, просто выполнив команду
hg update -Cна сервере (конечно, вы можете захотеть сделатьhg statusи получить уязвимые файлы для последующего анализа).источник