I had a project deployed to Heroku but needed to push changes to it. The changes were visible locally but did not push to heroku, I never could figure out why. I deleted the git remote associated with my project and simply started a new Heroku project, then pushed to it.
The new project comes up as a blank screen on Heroku. I did some digging and realized that my local project is not in Production mode.
For the past couple of hours I have tried every solution I can find to get my project into production mode but to no avail.
Deleting public/static and then running npm run build appears to work in terminal, yet the project is still in dev mode.
I would like to simply start over, as though I am deploying for the first time. Is this possible?
I am a beginner and completely at a loss. Thanks in advance.
Related
I have a AWS CodeStar Java Web application. I have a Route 53 domain which links to this application. Until yesterday, everything was working fine.
Yesterday, I was adding some new features and pushing them to the CodeStar repository. I didn't notice that four commits failed to build due to one issue. Today I noticed the failed builds and posted a new commit that fixes the issue. The commit was built and successfully deployed.
The problem is that the changes that I did in the commits that failed to build are not propagated to the web app. I can't see them on my website. I can open Developer tools and see that the source code is like it was before my changes.
BUT when I look at the code in AWS CodeCommit, all the changes are there. Included the changes I did in the commit that failed to build. The code is complete the same way I have it in my local machine.
What is the problem here? Why are the changes not propagated to the website if I can see them in CodeCommit? Do the failed builds have some negative effect here? What should I do to get my changes to my web app?
I wasn't able to figure out what the issue is, but I just created a new CodeStar project, copied the code from the old project to the new project and continued onwards with the new (working) project.
I'm somewhat new to maintaining separate production vs development builds of an app.
I want to have my current build deployed to heroku so i can easily get it in front of people for critique but I'd also like to run a local version as well so i can make changes and see them quickly on the fly.
With my app on heroku, everytime i make a change, I have to push to github then hit the deploy button. This takes a relatively long amount of time compared to just launching the app on localhost and just refreshing the browser page to see how the changes came out. This is fine if you have made a ton of changes and you know they all work as expected, but its horrible for trying incremental changes, as you can imagine.
I know this is sort of a newbie question, but how can I have the best of both worlds?
The only way to achieve something like this is with review apps.
Instead of doing a git push, you will need to enable GitHub Sync. You will be able to deploy either through the heroku dashboard, or automatically when a push is made to master.
Review apps will automatically create a test app and configure it, for each pull request.
Then, when you wish to do QA with other people, you just have to give them the address to that review app where the new code is deployed instead of the main one.
I have a Parse application that will soon be used in production, and I need to be able to continue developing things locally without breaking things for live users when I make changes to cloud code.
I have cloned the app, and can now deploy to either the production or staging app using the parse deploy staging and parse deploy production commands, however these commands only work if I am on the master branch.
What I would like to have are two branches in git, one that can be pushed to my staging app, and the other that can be pushed to the production app.
At the moment all I can think of doing is to just tag commits in master as being pushed to production, then continue ontop of that for development, but that is going to be a nightmare if I need to patch the released app when I have all my development changes on master.
Pushing directly to the heroku git repos doesn't seem to work either, parse deploy must be doing something extra (plus it tries to build the app so I can see when things go wrong).
Another issue is that when other developers start working on this as well, we won't be able to all deploy to the development server, and as far as I know there isn't an easy way to run parse cloud code locally on windows.
What is the best way to manage all this?
You have to setup parse-server (use parse-server-example), parse-dashboard and mongoDB on a local or remote development server. You and your team can now develop everything locally, test and then deploy to production.
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.
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.