Ответ 1

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

Сведения о проекте

Один из наших клиентов имеет большую и тяжелую платформу, используемую для управления его бизнес-процессом (что-то вроде ERP и CRM). Платформа была первоначально разработана с использованием Symfony 2, и теперь мы обновили ее до Symfony 3. Чтобы быть уверенным, что все работает правильно, в проекте много тестовых примеров. Мы также используем:

• Doctrine Migrations, чтобы мы могли безопасно обновлять базу данных на рабочих серверах всякий раз, когда это необходимо.
• Phing
• Бауэр
• Assetic
• PHPUnit
• Git
• Дженкинс

Тестирование

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

Развертывание

Мы привыкли к этому так же, как вы, - загрузите архив после завершения работы jenkins. Это, однако, оказалось довольно проблематичным, поскольку в некоторых случаях архив может быть сломан (т.е. Из-за проблем с сетевым подключением между экземпляром jenkins и производственным сервером). Также потребовалось значительно больше времени, чтобы загрузить файл с нашего сервера на клиентский сервер. Вот почему мы решили использовать git и вытащить нужную версию оттуда. Использование git оказалось более надежным и обеспечило абсолютную копию проекта на стороне клиента. Кроме того, откат назад к предыдущей версии - это всего лишь один git checkout:)

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

Как только работа сборки jenkins будет успешной, и мы вручную выпустили и отметили версию продукта, мы запустили бы phing update на клиентской машине через SSH (этот шаг мог быть автоматизирован, но был намеренно не из-за некоторых требований к проекту). Эта команда будет выполнять следующие действия:

• Получить последнюю версию с тегами с нашего сервера git
• Если версия current последняя с тегами (с хешем 19a6d9) переходит к следующему шагу
• phing maintenance:on (устанавливает платформу в автономном режиме)
• git fetch origin 19a6d9
• git checkout 19a6d9
• phing composer:install
• phing database:upgrade (который выполняет несколько команд, включая резервное копирование базы данных и doctrine:migrations:migrate)
• phing assets (запускает команды bower install, assetic и компилирует все js/css в one.css и one.js)
• phing cache:clean
• phing maintenance:off (включает платформу)

Наша задача phing update также окружена trycatch, и в случае, если фаза обновления попадает в кирпич, она автоматически переходит в фазу отката. Это делается с помощью команды phing rollback PREVIOUS_VERSION, которая выполняет следующие действия:

• git checkout PREVIOUS_VERSION - восстанавливает fs до предыдущей версии git
• phing composer:install
• phing database:rollback PREVIOUS_VERSION
• phing assets
• phing report (здесь сообщается о проблеме с обновлением нашего журнала ошибок с прикрепленным файлом журнала)

Ответы на ваши вопросы

• Вы предпочитаете переносить папку bower_components и vendor в живую систему вместо повторного выполнения bower install и composer install?

  • Я бы пошел с bower install и composer install, потому что с первого раза у вас уже будет все кеширование. Каждый следующий прогон был бы почти мгновенным или, по крайней мере, намного быстрее, чем повторная загрузка всех активов снова и снова через ftp. Это может сэкономить вам пропускную способность и, самое главное, время. Если вы захотите сделать аналогичную установку для моего, вы можете избежать compiling js/css в экземпляре Jenkins, как вы это делаете на сервере prod.

• Как вы обрабатываете свои пароли при выполнении рекламной кампании в прямом эфире?

  • Не уверен, что вы спрашиваете?

Заключение

Настройка зависит от ваших требований к проекту, имеющихся у вас ресурсов (т.е. vps, совместного хостинга, git, ssh и т.д.) и процесса выпуска. Как вы можете видеть, наше развертывание немного отличается от того, что вы делаете. Это не делает его плохим и хорошим - это просто соответствует нашим потребностям. Если у вас уже есть работы для вас и решает все ваши проблемы - вы должны придерживаться его и пытаться его оптимизировать. Если вы только начинаете, это то, о чем вы должны быть особенно осторожны:

• FULL... BACKUPS! Наличие резервной копии файловой системы производства отлично, но вы также должны иметь резервную копию базы данных. Во время разработки вашего проекта, вероятно, у вас появятся новые функции, которые изменят базу данных. Некоторые из этих изменений могут быть несовместимыми в обратном направлении. Поэтому обязательно создайте резервную копию всего, или у вас может получиться резервная копия fs без работы db, чтобы не было возможности отката.

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

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

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