Стратегии развертывания Heroku + Github

Я работаю над веб-приложением, размещая исходный код на Github и запуская приложение на Heroku. Все работает нормально, но я по делу не могу обернуть голову. Перед развертыванием моего кода я запускаю некоторые скрипты для оптимизации кода (минирование, объединение файлов и т.д.). Приложение heroku использует только оптимизированную версию приложения.

В принципе, у меня есть две папки: dev и production. dev содержит исходный код, который я пишу, production создается моими скриптами сборки (я использую grunt и requirejs). В настоящее время обе папки находятся в моем репозитории Git, и оба они переносятся в Github и Heroku. Мне бы хотелось только иметь dev в Github и только production на Heroku. Я прочитал несколько статей о том, как настроить разные ветки для Heroku, как описанные в этом блоге. Могу ли я настроить производственную ветвь и иметь только папку production, сохраняя при этом папку dev в моей главной ветке? Или мне нужны отдельные репозитории?

Кто-нибудь пробовал что-то подобное? Я бы предположил, что это не что-то необычное.

ОТВЕТЫ

Ответ 1

Вы можете просто рассмотреть использование файла heroku .slugignore (ref https://devcenter.heroku.com/articles/slug-compiler).

Этот файл позволит вам удалить папку dev из пакета, который heroku разворачивает на каждый экземпляр сервера, а также позволяет сохранить весь ваш код в том же репозитории.

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

Модель Heroku немного отличается от нее тем, что предполагает, что ваш репозиторий - это артефакт для развертывания. Разница небольшая, но в вашем случае это просто означает, что вам нужно зафиксировать в вашем репозитории биты, которые вы хотите использовать герою.

Еще один способ подумать о том, что вы можете обойтись без вашей папки production, и в рамках запуска вашего сервера будет запущен script для создания файлов папок production. Это позволит вам удалить папку production и сохранить ваш репозиторий за счет запуска этого процесса при каждом запуске вашего сервера. Это может оказаться непомерно дорогостоящим и нежелательным (существуют ограничения на то, как долго Heroku будет ждать запуска сервера, прежде чем он откажется от него), но, надеюсь, помогает в обеспечении некоторой ясности вокруг отношений Heroku и git.

Ответ 2

Эта ситуация немного необычна. Но вот несколько идей:

  • Я использую процесс, похожий на тот, который вы указали в статье.
  • Я бы создал только одно приложение, как ваше высказывание. Я бы создал его, создав новый репозиторий git в вашей папке dev.
  • Затем я рекомендую стратегию развертывания, аналогичную описанной в этом ответе: fooobar.com/questions/168947/.... Я адаптировал его ниже:

Создайте файл rake с двумя задачами в нем: rake deploy:production и rake deploy:postprocess_files. Эти задачи могут выглядеть примерно так:

namespace :deploy do

  task :production do
    puts "turn on 'maintenance page' on heroku"
    system "heroku maintenance:on"

    puts "deploying to production"
    system "git push heroku-prod master"

    puts "post processing files..."
    system "heroku run rake production:postprocess_files"

    puts "take off maintenance page"
    system "heroku maintenance:off"

    puts "done"
  end 

  task :postprocess_files do
    puts "run postprocessing of files on heroku"
    ... add commands here to post process the files.
  end 
end

Затем разверните его с использованием rake deploy:production, а не нажав непосредственно с помощью git. Затем файл рейка:

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

Обратите внимание, что вторая задача рейка в вашем файле содержит команды для последующей обработки в ваших файлах и вызывается для запуска на heroku первой задачей рейка.

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

Ответ 3

Это немного запутанно, потому что:

  • ваши dev и production представляют среды и являются каталогами с сгенерированным контентом:
    Они не должны быть в VCS, но автоматически создаются с помощью script, который распознает среду, в которой он запущен, и создайте соответствующий каталог соответствующим образом.

  • dev и production, упомянутые в статье, вы ссылаетесь на " Развертывание нескольких сред на Heroku (при размещении кода на Github )" представляют этапы продвижения и являются ветвями.

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