Лучший способ запускать скрипты сборки перед развертыванием веб-приложения?

Question

При работе с репозиторием git, который содержит все исходные активы и сценарий сборки gulp/grunt, или composer install, который должен быть запущен до того, как он будет функционировать, как лучше всего его развернуть на производственный сервер? Вот некоторые решения я придумал:

• Сохранение локальной копии на стадии производства (запустить скрипт сборки и композитор установки, а затем развернуть на сервере через (s) FTP). Это кажется непрактичным и добавляет по крайней мере один дополнительный шаг к процессу развертывания.

• Создание ветви распространения, отслеживание скомпилированных/конкатенированных/мини-файлов там. Это кажется неинтуитивным и, как и первый вариант, добавляет дополнительный шаг к процессу развертывания.

• Использование capistrano или стороннего инструмента развертывания, который будет ssh на рабочем сервере, клонировать репозиторий, запускать скрипты сборки и создавать символическую ссылку на недавно установленную версию. Это похоже на «самое опрятное» решение, хотя оно требует полного доступа к серверу и может иметь некоторые последствия для безопасности.

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

Answer 1

один метод, который я видел работать, чтобы объединить местную сборку скрипты с простым развертыванием git и использование двух репозиториев: например src и www.

1. Ваше хранилище ЦСИ содержит источники и сборочные скрипты, тесты и т.д.

2. Сборка выполняется локально (композитор, хрюкать, дерзость, JS-мин и т.д.) и выводит «статический» результат через к www/htdocs в репозитории www.

3. WWW repo совершает сборку и переносится на пульт развертывания.

4. Пульт развертывания находится на сервере-изготовителе, с крюком после приема, который проверяет головку (от голого репо в/var/git/yourdomain) до веб-сервера (например, в/var/www/yourdomain), который является рабочим каталогом git.

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

Я обнаружил, что строительство ветви - это кошмар, отчасти из-за упорства git на файлах отслеживания и необходимости избегать некоторых слияний. Например, очень сложно сделать сборку чисток. Вы должны, по крайней мере, иметь отдельную папку WWW, которую вы создали бы, по существу, дублировать любые внутренние скрипты, которые не были скомпилированы (например, PHP). И управление версиями и ветвление dev vs. релизы иногда расходятся. Имея два репозитория, полностью разделяет это и позволяет развернуть ветви развертывания на разных веб-сайтах, например (staging, prod).

Конечно, метод развертывания git означает, что вам нужен «полный» доступ к хосту для установки git, перехватчиков и доступа к ssh. Но большинство веб-хостов предоставляют доступ к SSH?

Я обнаружил, что git-развертывание является чрезвычайно надежным и безопасным.