[meric]

Of course deploying as root is doing it wrong.

However, I still haven't found enough reason to switch from using SSH for deployment. It's almost always three lines. ssh; git pull; ./manage.py syncdb/migrate/collectstatic.

The only hindrance has been configuring the site to work on the server for the first time, i.e what the site at this link claims to solve.

I've spent several hours on fabric before but gave up when I realised I've spent more time on learning it than the time I spent deploying my code.

Can you tell me what I am missing out? I'm still relatively new to django deployment and I feel I'm missing something but I haven't found it yet.

[heretohelp]

Idempotence, edge-cases, compliance ensurance.

What if you want to redeploy a configuration change to your web servers? What if you want to ensure such changes get re-deployed everytime a change is made to a config file?

[meric]

I guess if you are deploying the same site to more than 1 production server these will become worthy problems to solve?

[heretohelp]

These are problems that can be solved in an afternoon, and then never repeated ever again.

You need to be using automation.

We have something like 16-17 servers, of which 4-5 are actually production servers. Every single one of them was provisioned, configured, and are pushed to via my code.

Everything from haproxy, to the frontend web servers, to the backend web servers, to the frontend assets, the CDN, the image server, the backups, our staging cluster, experimental cluster, databases...all of it is automated.

Do it once, do it right, do it in code, never do it manually again.

The idempotence is just so you can repeat the same job over and over if it fails halfway between without causing any breakage.