I have a set of older apps, which I moved to a new Heroku pipeline.
I successfully upgraded the Dev App to the new Heroku-16 Stack and deployed it to the production apps using the pipeline promotion.
The settings page of the production apps still says, that they use Cedar-14. Is this right? I assume, that they are also using the Heroku-16 stack?
I won't do any git commit again to the production apps, because I'm currently always deploying and releasing via pipeline.
I answered the question by myself...
Yes, the new stack also applies to targets of the pipeline.
Related
I'm beginning to understand how Heroku works, but haven't yet used a pipeline. I have an app I'm working on that is near its first production version. I'd like to begin using pipelines.
But I don't understand how to begin. What do I need to do to make a copy of the current app and have that copy be in the development stage and make another copy for the staging stage? Do I fork my git repository twice and add each one?
I'm trying to take this one step at a time. I don't need GitHub integration yet. This is a small project and will not have any pull requests for quite some time, if ever. I'm only interested in the ability to develop, stage and release in the three stages offered by Heroku.
While pipelines do use multiple apps, they should use the same git repository with different remotes. Heroku's help page helped me understand that the process is to link the repository to each app different remote names and then push to the remote that I'm currently working on.
A default heroku pipeline has the stages review-->staging-->production
with review being optional.
There is a way to add a development stage - but I can't find how to do this anywhere.
Is there a way to do this through a config file in the repo, or CLI, or the web GUI?
Found it...
Create an app in the staging stage, after you create it, the menu on the app has the option move to development, and then the development stage is created/revealed.
I believe your question is answered here.
I have a rails app that runs database migrations in a rake task after tests have succeeded and immediately before deploying code to Heroku.
I am using CodeShip to run the tests, run the migrations, and then finally deploy to heroku.
However, I am running into a problem with Heroku's new Pipelines feature.
Upon promoting a version of my app from one environment to another, only the the application slug is copied over to the new environment. No branches are merged or updated in git, and no codeship builds trigger.
Even the heroku build history shows only a promotion entry with no build log associated. Which makes sense since it is just copying the slug over, not building a new slug.
So my problem is that when I promote my app to a new environment, I am not able to find any way of hooking a custom script into that event to perform database migrations.
Main Question
Is there support for this that I am just having trouble finding? If not, is a feature in the works that would support this?
Feature Suggestion
Ideally I would like the promotion feature to work by merging the underlying git branches, that way codeship could still kick off, run all tests and migrations again in the new environment, and then finally trigger the build in the next environment. This would require each environment in the pipeline to be tied to a specific branch, instead of just promoting by commit hash, but I don't think that would be problematic.
Essentially I would like the promote button to just do what we developers would often do when manually promoting a version of our app, merge to a git branch associated with that environment and let our CI server's git hooks kick it off from there.
Post-promotion script can be defined in Procfile with release process type.
release: npm run migrate
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 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.