Snappy

Great summary of GitLab CI's advantages. Nice, easy read. Thanks Pierre!

(Disclaimer: I work at GitLab)

Take a look at GitLab's plan for Issue Boards (https://gitlab.com/gitlab-org/gitlab-ce/issues/17907). It's not quite Jira, more like Trello, but a great step in solving modern issue management and planning.

Thanks! Glad you like the direction!

Yes, it's a GitLab EE-only feature, but it's also available for free on GitLab.com, which is running GitLab EE.

If you're going to use the shared runners, I don't think that configuration is going to work. The build step will build it locally, and even though you named it to use the registry, it won't actually push to the registry automatically. By breaking up the push to another step, you're actually going to run that deploy stage on a fresh Digital Ocean instance, so your previously-built image will be lost.

That's why the example pushed the image right after the build step.

Having said that, if you're literally using that script, you don't even have tests, so you may as well just put both steps into a single build stage like the simplified example. :)

For now, you'll need the explicit `docker login` as well. We'll work to remove that.

Thanks!

No current plans for rkt, but feel free to create an issue to discuss it.

It really comes down to cost and convenience. We don't charge anything additional to run the container registry (including unlimited private projects for personal or business use), and it's already installed with GitLab.

Having said that, we do love deep integration, so we'll continue to improve it going forward. If you have any ideas for improvements, please do create an issue!

Yeah, sorry about that. We'll update the blog post to clarify. We're updating the CI runners this week to support this.

You can run a post deploy script to load development data. e.g. `rake db:seed`.

Heroku scheduler runs in a separate dyno so that wouldn't impact idling of the web dyno.

For (2), Type `aspen` in the search bar of Heroku Dashboard.

Don't forget the continuous protection backups...

But was it serving _your_ 500 error page? In which case you could make it say anything you want. Heroku platform errors are not 500s; they're 502s (or 503s, I forget).

You mean like this? https://devcenter.heroku.com/articles/error-pages#customize_...

Thanks for the feedback. We (Heroku) have been wondering if people would prefer that.