What's a good devops approach for a single developer writing python web applications?

I'm guessing this question will seem incredibly trivial for some readers, but as someone who is a developer but with little experience of deploying apps in anything other than a manual, hit and hope sort of a way, I hope you will understand that it's quite daunting to see the number of different approaches and tools there are, so I could do with a bit of advice to get me started in the right direction.

I am a developer, now only in my spare time, which is limited. Up to now I have worked with Java, building webapps, and have been reasonably happy with deploying a war file to a Tomcat environment which keeps things nicely encapsulated.

I am now working in Python and Django, but as I get closer to the point where I need to deploy, I want to set up a solid devops workflow to automate as much as I can and ensure I can deploy reliably, but given that my use case is relatively simple, I want to avoid learning a big fat toolset which is over-engineered for my needs and which requires a big investment of time I would rather use coding my app.

So I am looking for a middle ground which allows me reliably to deploy and manage my app(s) without investing a huge amount of time setting up and learning a big devops ecosystem.

Some more details...

Context

• I develop on a Mac, using PyCharm to build Django 2, Python 3.

• I use git (but not on github) to manage software versioning.

• I am comfortable with other languages and scripting languages and have written a few (probably fairly amateurish) bash scripts, although I don't enjoy bash. I've also dabbled with Perl, which I realised isn't really a language for dabbling (i.e. you need to spend time learning it properly)

• I intend to deploy on a VPS environment, probably DigitalOcean.

• My app isn't mission critical but it is important that I know if the site goes down, and need to have a way of reliably recovering if it does, whether this be restarting the app, restarting the server, or moving to another server (or other

I am not familiar with Python development nor DigitalOcean, so I'll just offer a few pointers:

• The goal is to automate. Everything. How you achieve that is really up to you, and creating your own tooling is not far-fetched, many do it that way. One concrete and pretty low(ish) hanging fruit is to get a git post-receive hook running which deploys and restarts your test environment. If you have that, the rest should be simple.

• "My worry about this is that the scripts will be code which needs testing" - that worry is unfounded. You are testing those scripts every time you deploy to your test environment, after all. Especially coupled with a blue-green approach it will be fine to have bash scripts.

• "I don't enjoy bash." - then find another scripting language that you enjoy. Maybe try Ruby? The language and core libraries are very clean and well documented, and I'd say, rather easy to learn. Or, just for fun, Go(lang), which seems to be well-suited to devops tooling tasks. And finally, as you seem to like Python, you certainly can do installation tasks with that as well. From these, Go has the benefit that it creates standalone binaries and does not need a complex environment installed first, itself, so bootstrapping may be easier.

• "a staging environment which is as identical to the live as possible" - if you have a script that spins up an environment from scratch, i.e. from a more or less empty base image, then your environments will be identical, save for deltas encoded in your script. That's the point of all of this.

• "Way to switch live site to another server" - the only thing to ponder is what happens with your persistent data. I.e., you will want to make it so you can link your applications with different persistent volumes/stores on the fly, to be able to switch back and forth.

• "Docker - daunted" - to be honest, it should not be that bad. If you know how to build an environment from scratch with command line tools (no GUI tools), then placing those in a Dockerfile should be rather easy. The worrisome details appear when it's time to tune (i.e., reduce image sizes), but apart from that it should not be too bad. First get it to work somehow, then find out how to make it beautiful. The good thing is that the knowledge you gain will transfer to lots of other environments.

Good luck!

StackExchange DevOps Q#4228, answer score: 5