Хорошие практики для извлечения из git repo на рабочий сервер

Question

У меня есть DigitalOcean VPS с Ubuntu и несколько проектов laravel, для начальной настройки моих проектов я делаю git clone, чтобы создать папку с файлами приложений из моего онлайн-хранилища.

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

Теперь на моем рабочем сервере, когда я хочу добавить все изменения, добавленные в производство, я делаю git pull из origin, пока это привело к тому, что git сказал мне спрятать мои изменения, почему это так?

Каков наилучший подход для внесения изменений в рабочий сервер? помните, что мой рабочий сервер не имеет рабочего каталога, все, что я делаю в своем VPS, это либо клонирую, либо запускаю обновления в производство.

Answer 1

Вы можете взглянуть на системы CI / CD (непрерывная интеграция / непрерывная доставка). GitLab , например, предлагает бесплатный план для небольших команд.

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

И самое большое преимущество в том, что вы можете иметь несколько промежуточных шагов (даже для рабочих веток), где вы можете запускать модульные тесты, которые не позволят вам загружать сбойные сборки (всякий раз, когда вы объединяете нерабочий код)

Answer 2

Для первой проблемы выполните git status на производстве, чтобы увидеть, какие файлы git видит измененными или добавленными, и подумайте о добавлении их в файл .gitignore (который сам должен быть частью вашего репо). Laravel обычно имеет хорошие значения по умолчанию для них, но вы, возможно, добавили вещи или отклонились от них в процессе обновления Laravel.

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

1. Вы определяете параметры развертывания в коде, который вы можете зафиксировать как часть вашего репозитория (конечно, не пароли, а такие вещи, как имя сервера, путь развертывания и задачи развертывания).
2. Вы запускаете развертывание непосредственно с локального компьютера.
3. Сценарий / утилита SSH попадает на целевой сервер и извлекает последний код из удаленного репозитория git (авторизованный с помощью ключа SSH, пересылаемого на сервер) в папку «release».
4. Сценарий выполняет любые дополнительные задачи, которые вы определяете (composer install, npm run prod, systemctl restart php-fpm, общие файлы с мягкими ссылками, такие как .env и т. Д.)
5. Скрипт мягко связывает корень документа с вашей новой папкой 'release', что приводит к практически нулевому развертыванию. Если какой-либо из предыдущих шагов завершился неудачно или вы обнаружили ошибку в последнем выпуске, вы просто софтово связываетесь с папкой предыдущего выпуска, и ваш сайт все еще работает.

Вот несколько решений, которые вы можете проверить, что все делают подобные вещи:

• Laravel Envoyer : сторонняя (платная) служба, позволяющая выполнять развертывание через веб-интерфейс.
• Laravel Envoy : сторонний (бесплатный) пакет, позволяющий подключаться к вашему серверу prod и выполнять задачи развертывания сценариев. Это очень просто: вам нужно написать все команды самостоятельно, но некоторые могут предпочесть это.
• Capistrano : Это (бесплатная) проверенная и популярная утилита развертывания на основе ruby.
• Deployer : (бесплатный) PHP-эквивалент Capistrano. Проще в использовании, имеет много встроенных задач (включая Laravel) и не требует ruby.

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