The prod commit

Last Edited: Sun Jan 22 06:00:00 UTC 2023

This website and my other website bowdoin.wine are both pretty simple Django apps. They've got some basic auth|entication/orization functionality, full CRUD functionality, some routing, some templating, the works. Part of that Django deployment involves several differences from my local machine to my server, so before explaining what the prod commit system I've been using is, I'll first go over my tech stack.

Base layer: Linode nanode server running Debian. Web server: Nginx Django servers: Running Gunicorn servers reverse-proxied to the Ngninx server managed by Systemd daemons and run through File Sockets (also managed by systemd). Git/hub to sync between my machine and the server.

And that's the whole stack.

A feature of doing a reverse proxy in this way requires me to do static file collection in Django, point the nginx server to the collected files, run separate migrations, point to different static files in the settings.py file, have a separte secret, and more. Doing all of this requires a pretty significant change between the dev environment and the prod environment. Enter my solution: The prod commit.

The prod commit is just what it says in its name. It is a GitHub commit that contains all of the changes from dev to prod.

I understand that there is immense utility in different env files and stuff like that, but my prod commit system has a couple advantages:

1. No need to worry about secrets. All secrets exist on the server and, should I need, they can be checked into version control.
2. No need to worry about complex automation infra.
3. No need to authenticate github on my server. This is, for me, a significant advantage because GitHub tokens are annoying.

To implement the prod commit system, here is what you do.

1. Make a Django project and keep it up to date with GitHub.
2. Clone the repo on your server.
3. Make necessary static file collections and migrations. You can even connect to a Postgres database instead of an sqlite instance.
4. You're done!

But what about when I need to update the website? Simple, run the following procedure.

1. Git stash.
2. Git pull.
3. Migrate stuff (if needed)
4. Git stash apply
5. Systemctl restart

That's it. 5 commands. I could even write a bash 5 liner to do this for me. It's proven to be a very effective system for my productivity and takes all of the hassle and stress out of prod deployment ops and reduces it to using Git, a simple tool that I am already acquainted with.

If you find it useful, I'm glad. If not, you're probably right in your criticism, but for my scale it's working great. That's all I've got for now.