Simplifying Heroku deployments

Using Django
1

It’s much easier to deploy a simple Django project to Heroku than a general VPS such as Digital Ocean or Linode, but I’ve always felt the process could be simplified further. It seems like all of the steps involved could be automated. This would make the process much less error-prone for beginners, and simpler for experienced developers as well. The core idea is that if you have a project working locally using SQLite, you should still be able to push your project to Heroku without making any local changes.

I’ve made a modified version of the Heroku Python buildpack that does this. It currently works for simple projects that use a requirements.txt file. Assuming you’re using Git to track your project and you already have the Heroku CLI installed, you can deploy your project by running these steps from a terminal in your project’s root directory:

$ heroku login
$ heroku create
$ heroku buildpacks:set https://github.com/ehmatthes/heroku-buildpack-python.git
$ heroku config:set AUTOCONFIGURE_ALL=1
$ git push heroku master
$ heroku run python manage.py migrate
$ heroku open

Notice there are no changes to the local project; everything that needs to happen for deployment happens on Heroku’s servers.

If you want to read more about this, here’s a blog post and the Github repo.

Thank you to everyone who has ever helped a newer developer through their initial deployment process. :slight_smile:

3 Likes
2

I’ve only tested this on two of my own projects. If you like the idea of a simpler deployment process and have a simple to moderately complex Django project to try deploying, I’d love to know the limits of this process. Please report any successes or failures here.

If you don’t have a good test project but you want to try out the project, here’s an instance of the Learning Log project from Python Crash Course to try it out on.

3

Awesome work @ehmatthes . This is really useful for simplifying the first time process and I’ll definitely look at it when I next need to introduce someone.

It is a shame that django-heroku is deprecated/archived without replacement. It seems Heroku/Salesforce aren’t really focussing on supporting new application deployments. I think there could even be space for a new player, which it seems you’re part way to creating… :wink:

You mentioned SQLite versus PostgreSQL in your post at the start. Is it right the deployed application uses SQLite? Is there any story for getting persistence to work on Heroku there?

(Also one style tweak - reading your post on dark mode, I can’t read the emphasized lines of code:

Screenshot 2020-10-19 at 19.01.12
Screenshot 2020-10-19 at 19.01.121712×1390 253 KB
)

4

Thanks for the kind words, that’s really encouraging. I wasn’t sure if this was just a minor annoyance for me, or something that bothers a lot of people. The more I used it myself, the more I like it and think others will as well.

I agree this hasn’t been a priority for Heroku. The people responsible for Python at Heroku have been aware of this issue for a while, but they seem to have other priorities. There’s also been a bit of cycling through developers in the lead position that’s kept this from being resolved.

That said, I think the buildpack is a much better place to make default configurations than an external library like django-heroku. If heroku is going to maintain code to simplify deployment, why not put it right in the buildpack where they’re working every day?

You mentioned SQLite versus PostgreSQL in your post at the start. Is it right the deployed application uses SQLite? Is there any story for getting persistence to work on Heroku there?

The deployment uses Postgres. I meant that if a brand new Django developer is working locally using SQLite, they shouldn’t even have to know initially what Heroku uses for a database. If it works locally, it should work on whatever Heroku uses by default. I haven’t had an issue with persistence on small projects. I’m not sure what the limits are on the default free instance.

Thanks for the screenshot, I’ll take a look at my blog in dark mode.

5

Ah okay. My only concern with this is the differences between SQLite and PostgreSQL are not small, and even things that beginners can run into like type sensitivity (SQLite allows any type in any column).

I’d also love to see use of SQLite in production more, it’s actually not a bad shout for smaller projects…

1 Like
6

I understand the differences between SQLite and PostgreSQL. I like to think about this by considering what happens if people new to deployment follow the simplest directions offered by a host. If they do this on Heroku, they will modify their settings in a way that it points to Posgres for the deployed version, while they continue to use SQLite locally. So if people use, the auto_configuration approach, they end up with the same setup. If they are going to run into issues where the root cause is differences between SQLite and Postgres, they’ll still run into them at the same stage - either on the initial push, or when they’re interacting with their site.

To me, this is a question of documentation. It should be clear, whichever approach people take, what the deployed infrastructure looks like. My primary complaint with the current process is that people are being asked to take a number of default manual steps that could be automated, and that those manual steps are likely to cause unneeded difficulties for many beginners.

My thinking on this isn’t specific to Heroku. I have been corresponding with another host that uses Docker internally. They ask people to write a dockerfile, even if they’re not using docker locally. My guess is they could auto-generate that simplest case dockerfile. Then you can have people only create or modify the default dockerfile when their use case requires going beyond common defaults.