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

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

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

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

Ответы на вопрос(4)

Я лично люблю это решение,https://github.com/mbuchetics/heroku-buildpack-nodejs-grunt И взгляните на это тоже:https://medium.com/the-javascript-collection/how-to-deploy-a-grunt-project-on-heroku-c227cb1ddc56

Это честно один из самых чистых способов.

 slurmomatic17 июн. 2014 г., 12:02
Ницца! Это на самом деле мой собственный проект. Действительно рад, что другие находят это таким же полезным, как и я.

your dev and production represent environments, and are directories with generated content:
They shouldn't be in a VCS, but automatically produced by a script which would recognize the environment in which it is running, and create the right directory accordingly.

the dev and production mentioned in the article you are referring to "Deploying multiple environments on Heroku (while still hosting code on Github)" represent promotion stages, and are branches.

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

 24 июн. 2012 г., 12:21
В этом случае @slurmomatic, ответ Кевина (за который я проголосовал) должен быть более адаптирован к процессу управления выпусками Heroku, чем мой (более общий) ответ.
 slurmomatic24 июн. 2012 г., 10:59
& APOS; DEV & APOS; не содержит сгенерированного контента, то есть исходного кода, который я там пишу. & APOS; производство & APOS; то же самое, но с оптимизированными файлами. Я знаю разницу с ветками. У меня проблема с развертыванием Heroku, основанным на репозиториях Git. Я могу только развернуть то, что находится в хранилище. Я не могу отделить то, что выталкивается в Github, и то, что выталкивается в Heroku (если не используются ветки).

I use a process that's similar to the one in the article you referenced. I'd create only a single app as your saying. I'd create it starting a new git repository in your dev folder. I'd then recommend a deployment strategy similar to the one described in this answer: https://stackoverflow.com/a/8058194/267025 . I've adapted it below:

Создать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 напрямую. Рейк-файл будет:

set the maintenance page, push to production, do your post processing of files, take down the maintenance page.

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

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

 24 июн. 2012 г., 13:13
Я полагаю, что вы можете быть правы - также я понял после того, как написал это, что вы развертываете код node.js, а не rails code.
 24 июн. 2012 г., 13:14
Мой комментарий о вашей необычной ситуации был сделан исходя из того, что вы предполагаете, что вы развертываете код rails. Я менее знаком с node.js на heroku, так что это может быть не так.
 24 июн. 2012 г., 12:19
+1: более точный механизм развертывания
 slurmomatic24 июн. 2012 г., 13:00
Я не думаю, что это сработает. В документации об Разовых процессах (devcenter.heroku.com/articles/oneoff-admin-ps) в нем говорится: «У каждого dyno есть своя собственная эфемерная файловая система, которая не используется совместно с другими dyno, и которая сбрасывается при отключении». Это будет хорошо работать для сценариев базы данных и т. Д., Но не для чего-то, что изменяет файловую систему. Или я что-то упустил? Кроме того, почему моя ситуация необычна?
Решение Вопроса

.slugignore файл (ссылкаhttps://devcenter.heroku.com/articles/slug-compiler).

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

Корень проблемы заключается в том, что стратегия развертывания заключается в том, что вы загружаете последние биты на свой сервер, гдеthe bits are an artefact of building your repository, В таких случаях сборки обычно хранятся и архивируются отдельно от исходного кода.

Модель Heroku немного отличается от этой модели тем, что она предполагаетyour repository is the artefact to deploy, Разница незначительна, но в вашем случае это просто означает, что вам нужно передать в свой репозиторий биты, которые вы хотите, чтобы героку служил.

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

 08 янв. 2013 г., 17:46
Другая функция, которую я использовал в стандартном пакете, поддерживается через NPM. Вы можете добавить"postinstall" сценарий к вашемуpackage.json и запустить произвольный код таким образом.npmjs.org/doc/scripts.html
 slurmomatic04 янв. 2013 г., 12:23
Это то, что я делаю сейчас ... Я создал свой собственный сборочный пакет (см.github.com/mbuchetics/heroku-buildpack-nodejs-grunt) который использует Grunt для создания рабочей папки при каждом развертывании. Это работает нормально, и я могу не допустить все производственные вещи из git-репо.

Ваш ответ на вопрос