Distinguishing between configuration-only and fully automated modes

[ehmatthes]

The initial plugins for django-simple-deploy all have two modes: configuration-only, and fully automated. This is distinguished by running either manage.py deploy, or manage.py deploy --automate-all.

The distinction between these two modes is much more challenging to articulate when targeting VPS providers than it is when targeting PAAS providers.

Open questions

1. Is it worth building out a configuration-only mode, or are most people going to be happy with a fully-automated approach?
2. If you support a configuration-only mode, can you share the set of commands you'd expect users to run?

Configuration-only and fully automated modes for PAAS providers

When targeting PAAS providers, the configuration-only mode does some or all of the following:

• Usually requires you to create an empty project on the host platform.
• May create secondary resources such as a database, if that's not typically created by the host platform.
• Modifies the local project.
• Sets things like env vars on the host platform.
• Does not make any commits on behalf of the user.
• Does not run the platform's push or deploy command.
• Does not open the project for you.

The fully automated mode does the following:

• Creates resources such as an empty project on the host platform.
• Commits local changes for you.
• Runs the platform's push or deploy command.
• Opens your project in a new browser tab.

To see what this looks like more clearly, see the Fly.io Quick Start guide.

Fully-automated deployments to VPS hosts

When targeting a VPS provider, it's much easier to start by building out a fully-automated approach and then consider how a configuration-only approach might be structured. For example, here are the broad steps in a fully automated approach, starting with a fresh VPS instance:

• Add a new non-root user.
• Update the server.
• Install all necessary resources on the server, ie Python and any other system packages.
• Reboot as needed.
• Configure local and remote to support pushing the project. For example, configure a Git remote, and set up a bare repository on the server. This involves writing to locations outside the local project, such as storing ssh keys.
• Configure the local project. This includes writing some kind of script for serving the project.
• Commit changes.
• Push the project.
• Begin serving the project.
• Open the project in a browser.

One of the reasons it's easier to start by building a fully automated approach is that you know right away if you missed any steps. The order of these steps also doesn't matter as much in a fully automated approach. For example, you can configure Git before or after configuring the local project.

Configuration-only deployments to VPS hosts

The configuration-only approach is relatively simple when targeting PAAS providers, because they provide the push command. They also have code that automatically starts a server process after the project has been pushed. When targeting a VPS host, we need to take care of all that.

Configuration-only runs for PAAS providers typically look like this:

$ python manage.py deploy
# Review changes, and make your own commit.
$ <platform-cli> push

All changes are contained in that single commit. Also, all changes happen in the local project.

For a VPS host, it might look something like this:

$ python manage.py deploy --configure-server
$ python manage.py deploy --configure-local
# Review changes, and make your own commit.
$ git push vps_remote main
$ python manage.py deploy --serve-project

There are lots of variations on this. For example, I believe you could add a post-receive hook to start the server process. You can implement an rsync-based approach to pushing code to the server. In the end, you're basically going through the same series of decisions every PAAS founder has gone through when designing their platform.

Some pieces are clear. For example, anyone using django-simple-deploy to deploy their project to a VPS almost certainly wants to automate the process of configuring the server. The main thing people seem to want in a configuration-only mode is the chance to review changes that were made locally before committing those changes, and the chance to run a specific deploy command when they're ready to push from local to remote.

Since configuration involves changes to files outside the local project, such as storing ssh keys, abandoning the deployment is less straightforward to clean up. You can't just git checkout . && git clean -fd.