I am working on a web app, hosting the source code on Github and running the app on Heroku. Everything works fine, but I have on issue I can\'t wrap my head around. Before the d
This situation is a bit unusual. But here are some ideas:
dev
folder.Create a rake
file with two tasks in it: rake deploy:production
and rake deploy:postprocess_files
. Those tasks might look something like this:
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
Then deploy to production using rake deploy:production
rather than pushing using git directly. The rake file will then:
Note that the second rake task in your file has the commands to do the post processing on your files and is invoked to run on heroku by the first rake task.
As an alternative, it's possible you may be able to extend the assets:precompile task that Heroku runs as part of each deploy. That's essentially what you're doing anyway -- preparing assets for deployment to production.
You may want to simply consider using the heroku .slugignore
file (ref https://devcenter.heroku.com/articles/slug-compiler).
This file would allow you remove the dev
folder from the package that heroku deploys to each server instance, while allowing you to keep all your code in the same repository.
The root of the problem is thinking about the deployment strategy as one where you upload final bits to your server, where the bits are an artefact of building your repository. In such cases, builds are usually stored and archived separately from the source.
Heroku's model is slightly different from this in that it assumes your repository is the artefact to deploy. The difference is slight, but in your case, it just means that you need to commit to your repository the bits you want heroku to serve.
Another way of thinking about it is that you could do without your production
folder, and as part of starting your server, the script would be run to generate the production
folder files. This would allow you to remove the production
folder, and keep your repository clean at the cost of running this process on every start of your server. This may prove to be prohibitively expensive and undesirable (there are limits to how long Heroku will wait for a server to startup before it gives up on it), but hopefully helps in providing some clarity around the Heroku and git relationship.
It is a bit confusing because:
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.
Using branches is good, only for isolating code variations (in said branches), not for storing release generated code.
Your particular release management issue (ie generating the right delivery) should be managed by a script (which can be version-controlled alongside your code), and use as a hook, for instance, to generate and deploy the right set of codes at the right place.
I personally love this solution: https://github.com/mbuchetics/heroku-buildpack-nodejs-grunt And take a look at this too: https://medium.com/the-javascript-collection/how-to-deploy-a-grunt-project-on-heroku-c227cb1ddc56
It is honestly one of the cleanest way.