Amazing, really good tutorial!!
Do you know if sometimes changed with new versions? Could I integrate this with my current CI on Gitlab using pipelines?
I’ll try to do it later on with 1.4.2 and Digital Ocean
Thank you for your very kind words!
I’m sorry to say that large chunks of it are obsolete. The switch from Meteor 1.2 to 1.3 was just too great and happened when I was 98% done, having spent waaay too much time on it
There’s plenty of useful fragments, but as a whole it needs a complete overhaul to get it to work again.
Meanwhile, I’m working on HabitatForMeteor and Meteor Mantra Kickstarter which will form the underlying projects of the next version of Meteor CI Tutorial, if I can ever get back to it.
I’d offer them to you as an alternative, but they are both in an indeterminate state at the moment.
At least until someone helps me get past this aggravation, How to debug failing apk --> host connection?
1 Like
wow, nice job behind that. I’d be really glad to help but unfortunately my devops skills are useless : (
What you’re doing with HabitatForMeteor is similar to Mup, right? I tried it but like others tutorials related to Meteor deployment I get stuck at some point of them.
What I’ve achieved at the moment is create some jobs using the Gitlab pipelines and on this process run some tests, clean up my project, create a Docker image and push it to Docker Hub. I’d need the next step: download either the new code from my hosting (Ubuntu - DigitalOcean) or just download the Docker image from Docker Hub and restart the project.
But this would happens when I push to master, I didn’t like mup cause I needed to push and deploy separately. That’s ok for a CI but not for a CD (more info here: https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/). I’d like to have a whole automatic after push to be deployed.
It’s a shame because Meteor is a pretty nice framework but this process, the most important one, makes Meteor ugly and a complicating tech.
Yeah, I don’t know if Mup can be seen as a DevOps tool; I see it more as a stop gap measure between the plush space of Galaxy and doing it all by hand.
With Habitat For Meteor, I’m trying to create something that really can serve in a DevOps shop, but it’s a lot more work than I expected, and I’m not happy with it. In particular, I haven’t built it into CI the way you ( and I ) would like.
Well, I’m guessing Galaxy is too important an income center for MDG to want to hand out the tools to easily avoid it. I support that; I’d hate to see them run out money.
The problem with Galaxy is the pricing. Probably the best option to deploy a Meteor app but not definitely the cheapest one
What makes Galaxy “the best”? Benefits of Heroku include:
- automatic deploy on push to git repo
- pipelines for automatic testing and one-click promotion to production
- rollback to previous deploy with the click of a button
- two-factor authentication
- good docs
- hobby apps for just $7 monthly
You can do all of that using Gitlab CI
1 Like
Sure but does using gitlab ci make galaxy more competitive? You could use gitlab CI with Heroku too. Or you could use Codeship too or you can roll your own CI, but I think the way these these features are integrated in Heroku makes it more attractive than Galaxy.