I don't want to remove it from the production app or even staging. Deleting it from the Settings on Heroku doesn't seem to work, it'll just show up again when I try to rebuild the app.
In app.json file, you can find a section buildpacks. That's where you can set which buildpacks will be used for your review apps.
Related
My node modules by itself take up 500MB.
Heroku only allows 500MB. My complete app is about 700MB. What do web developers do to deploy their app and bypass this problem? It seems create-react-app downloads so much node modules to where it is almost impossible to deploy the app.
Try adding /node_modules to your .gitignore.
I am using a Capistrano deployment workflow for a Magento project.
On deploy Capistrano builds this Magento project on the server using https://github.com/Cotya/magento-composer-installer.
The issue is sometimes my Magento modules don't install correctly and I need to clear the cache, reindex or some other task to get everything 100%. The issues occur sporadically so I haven't been able to script a fix into the deployment process.
What I would like is on deploy Capistrano does not change the symlink to the new build straight away. Instead I am able to preview the site on another link, fix what needs to be fixed, then change the symlink manually.
Is this possible to set up using Capistrano?
If not, my other solution to this is to use the Magento maintenance flag however I would rather avoid having to put the site in maintenance. Open to other idea's as well!
Thanks
It is probably possible to do this by telling Capistrano to not include the symlink change as part of the process (something like Rake::Task["deploy:symlink:release"].clear_actions), and then running that manually (cap [env] deploy:symlink:release).
However, under the category of "Open to other ideas as well!" I'd suggest that you set up a staging site. Create a process to automatically restore a prod database back to stage, then deploy your code to stage and check it there. Once you have confirmed it works, deploy to prod and let the symlinks automatically do their job.
In starting a new project, I put together the skeleton for a Node app that has tests and generates some build artifacts, like asset compilation and compression. I have the tests running in Codeship so successful builds initiate a deploy to Heroku. They've made it all super easy, except I can't find any way to deploy built files, just a copy of what's in the repo.
Has anyone done this successfully? I feel like writing a custom deploy script to rebuild the assets after the tests and manually deploy them would be working against the existing toolset, and I know can't possibly be the first person to want to do this...
Turns out that Codeship doesn't keep anything, in fact, different servers do the deployment than the testing. It seems that the best-practice here is to recreate the assets on the Heroku side with a custom buildpack, which, directly after the git pull, does the dependency installation and compiles the app slug.
I am creating a very small and clean meteor app and have recently updated to v0.9 of meteor to be able to get rid of meteorite as "package manager".
For me it is really important in a way not to have any deployment specific stuff wired up into the sourcecode if it is possible.
What I am trying to do in a way is to have a good and clean Continuous Integration running. Right now I am using Codeship to run the tests and then push to heroku. But since I updated top meteor v0.9 there not seems to be a working buildpack.
Is it a reasonable way to create a buildpack on my own? That one would not have to do more than just install node, npm and meteor. Or is there another way to have the app bundled on a "build server" (can codeship do that?) and then have it somehow pushed to heroku as normal node.js app with all the necessities and dependencies?
Concerning the buildpack way:
I have been trying to install meteor via
curl https://install.meteor.com | /bin/sh
But when I run
meteor deploy --directory deploy
I get
bundle: You're not in a Meteor project directory.
This buildpack (which I authored) works for meteor >0.9 using meteor's native packager; no meteorite:
https://github.com/AdmitHub/meteor-buildpack-horse
You could start off with the existing buildpack (or one of the many forks of it).
It should be relatively easy without meteorite since you would no longer have to worry about it, its just getting rid of meteorite and updating the version of node. https://github.com/oortcloud/heroku-buildpack-meteorite
Regarding deploying to heroku. meteor deploy is meant to deploy to *.meteor.com or via Meteor's upcoming commercial product. Deploying to heroku is also relatively easy.
Deploying to heroku is setting up the buildpack, adding the git remote and git pushing to it. Also easy, perhaps easier, than meteor deploy.
During the git push process heroku will take your meteor app, bundle it, download node and run it (as in the buildpack). It's quite easy that way. One nice thing without meteorite is I imagine the build process is much faster.
I'd like to develop a heroku app with the neo4j addon, and i've followed the instructions here but I'm lost as to how to integrate the heroku-like environment variables into my local development environment.
My major goals:
Make things behave as similarly as possible to the deployed app.
Allow me to run automated test suites locally.
Allow me to run the app locally, for quick development iteration.
The only heroku helpcenter article I've found (here) that deals with this seems to recommend always deploying, but this means I have to check-in and push every little edit I make, syntax errors and all, and doesn't allow for running automated tests locally.
It seems like there should be a way for me to edit my Foreman Procfiles to get the desired behavior, but I don't see how I can do that without affecting the deployed processes as well.
This article seems to be what I needed, although I'm still not sure how I was supposed to find it: https://devcenter.heroku.com/articles/config-vars#local-setup
In summary, you can do heroku config > .env to install the production environment locally, then edit the file as needed. Foreman then uses this file to set environment variables.
The article recommends adding the .env file to .gitignore, but as far as I can tell, checking it in is safe since it seems heroku seems to already override it.