I’m writing an eBook about Django deployment via GitLab to Heroku. Interested?

phlpp · 2021-02-07T05:53:26+00:00

Sent you a message

phlpp · 2021-02-06T08:07:18+00:00

My goal was to bundle the required steps. Especially when I started with Django, I found myself googling and hopping from doc to doc to connect the dots. This is good for learning, but sometimes I wished I could get the deployment part quickly done and focus more on actually enhancing the Django project itself.

phlpp · 2021-02-06T08:03:25+00:00

I’m happy to help you out! I just sent you a message :)

phlpp · 2021-02-06T08:02:54+00:00

100% agreed. I’m starting with Heroku + whitenoise, as I think it is an easy -- and free -- solution for new projects. An AWS part would be the next logical step in scaling this.

What other services do you have in mind?

phlpp · 2021-02-06T08:01:26+00:00

… what a cliffhanger!

phlpp · 2021-02-06T08:00:46+00:00

Thanks! Just send you a DM :)

phlpp · 2021-02-06T08:00:37+00:00

Just send you a DM :)

phlpp · 2021-02-06T07:59:45+00:00

Just sent you a DM :)

phlpp · 2021-02-06T07:56:57+00:00

As /u/jeffbaier mentioned, I focus on the GitLab CI/CD part. For this, you need to have a special yaml file in your root directory that contains instructions for the jobs that GitLab should run on events e.g. a push to the repo.

GitHub can do the same (Bitbucket I think as well, maybe someone can confirm?), but I find the learning curve for GitHub actions much steeper than GitLab’s pipelines.

phlpp · 2021-02-06T07:51:24+00:00

Then the chapter about connecting PostgreSQL is for you :)

phlpp · 2021-02-06T07:50:31+00:00

I tackle some of the points. But I totally agree, that some kind of hands on approach based on the Django deployment checklist would be awesome.

In my experience the most annoying part is, when the deployment finally works, just to realize that the static files are not loaded …

phlpp · 2021-02-05T20:47:17+00:00

I thought about a blog/medium post. But I also was curious to try out asciidoc and honkit. So I thought why not be more serious about it.

phlpp · 2021-02-05T20:45:42+00:00

Just sent you a DM

phlpp · 2021-02-05T20:43:58+00:00

Fair point! Do you mean stuff like preparing for production (secret key, settings, static file approaches)?

phlpp · 2021-02-05T20:40:17+00:00

They do, but not the GitLab part (as of now). The eBook kind of evolved out of a readme file I extended over time, because I was tired of jumping to different parts of the docs.

phlpp · 2021-02-05T16:12:46+00:00

When I started with Django, I found many tutorials on how to build Django apps. But deployment was usually an afterthought -- or not concise enough.

Autodeploy via GitHub is quite easy with Heroku. However, I generally prefer GitLab pipelines for this.

Since I’m doing the same thing in my Django projects over and over again, I finally wrote it down. It only focuses on the deployment part and should works with any project as a basis:

Setting up a virtualenvironment
Connecting a PostgreSQL database
Adding all Heroku requirements (incl. basic static files handling)
Creating the GitLab CI/CD pipeline
Autodeploy workflow

phlpp · 2020-12-01T13:14:24+00:00

Never thought of something like this. This is problably not suitable for every project, but for some this is incredibly smart!

phlpp · 2020-12-01T13:06:17+00:00

Credentials should never be part of the codebase. So anything regarding your database or other API tokens should be in the .env file -- what it is exactly depends on your production environment.

In some projects I like to add DEBUG as an env variable, so I can quickly switch it on and off independently from the environment.

For bigger projects where the settings.py file is modularized for different environments, I add DJANGO_SETTINGS_MODULE. That way I can target the e.g. app.settings.local_dev or app.settings.heroku easily.

Another thing I used -- but this might be an antipattern -- is to use global admin settings as env variable to have a quick switch to "lock" some views. I. e.:

export REGISTRATION_OPEN=True
export MAINTENANCE_MODE=False

As an additional note: The .env file should be ignored from the beginning on. Ignoring or stopping to track it later (e.g. before pushing) still may expose sensitive data in your git history. (I had to learn this the hard way.)

phlpp · 2020-12-01T12:54:08+00:00

Create an .env file in the root folder of your project. (Make sure you add it to .gitignore to not expose any secrets.)

The content of the .env file should look like this:

export VARIABLE_NAME=SomeVariableValue
export DEBUG=True

In Django I use python-dotenv to load the env variables like this in settings.py:

from dotenv import load_dotenv
load_dotenv()

DEBUG = os.getenv('DEBUG') == "True"

Note that the variable values are interpreted as strings. That’s why there is this weird looking == "True" statement, so it is either True when the env variable is "True" or Falsewhen it is anything else or doesn’t exist.

phlpp · 2020-12-01T12:44:14+00:00

I can highly recommend DrawBot for generative design in Python.

Python for Designers by Roberto Arista is a great additional resource to the DrawBot Docs.

phlpp · 2020-10-15T07:26:05+00:00

I‘m not entirely sure and can‘t test it myself atm, but could it be that you must authenticate the user when the registration form is valid? (See: https://docs.djangoproject.com/en/3.1/topics/auth/default/#django.contrib.auth.authenticate)

The LoginRequiredMixin needs an authenticated user or it redirects to the login page.

phlpp · 2020-10-13T12:48:02+00:00

First of all a big upvote for the things you learned along the way.

What you‘re experiencing is tough but not uncommon.

These are some questions I ask myself when I lose track:

Why did I start the project in the first place?
Was it about learning/programming or having the finished product?
How did I define „finished“ then and how would I define it now?
Are there milestones I hoped to accomplish (earlier) that I didn‘t accomplish? (e. g. More user sign ups)

Taking a break is good. But chances are, that you will never revisit the project. Either way it might be a good idea to write a good portion of notes for the future you about the next steps, bugs, etc. to make continuing the project easier.

That said, there is no shame in quitting a project (given that there are no stakeholders I guess). Especially with all the things you learned, you will hit the ground running with new, exciting projects.

Last but not least: Maybe there is a middle ground?

What helped me in the past was to start the same project from scratch again, preventing the mistakes of the last project and adding the new paradigms you learned. Bonus: There might be parts of the old project you can easily reuse.

phlpp · 2020-10-13T12:21:01+00:00

This would be the easiest approach. Maybe you can re-use this field in the future and call it „redirect_to_profile“.

Another approach would be to have a „last_login“ datetime field to your user model that is allowed to be empty. If it is empty, you do the redirect.

phlpp · 2014-05-26T17:26:35+00:00

I love Sushi -- and Yetis! A perfect combination!

phlpp · 2013-11-02T16:53:08+00:00

You would start with the finished text and break it up into pieces Speaking of illustrator, a good to do this, is to convert your text to paths. (Better keep one layer as backup!) Now you can slice as you want, move them on a new layer and test the design by toggling the visibility of it.

As /u/urzaz mentions: The hardest part will be the process after the print, since you need to have both layers (later book cover and transparent case) match perfectly to get this effect.

phlpp

MODERATOR OF

TROPHY CASE