rsync vs git for Django development? + Project directory location?

[drone4four]

Have two questions.

To manage development of a Django project, when interfacing local changes and mirroring them to my remote webserver, would you people recommend using rsync or git? I have a little experience with both. I've been using rsync to mirror basic HTML and CSS changes from my local host to my remote Apache public_html directory for a while now. I was thinking of using rsync for transferring changes to my webserver but in one of the courses I am taking, the instructor uses git and GitHub. I’m not sure if using git is overkill or not best practices. What would you people recommend?

Whether I go with git or rsync, I also need to make a decision about where to place my Django project folder on my VPS. One of the guides I am using, titled, “How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04” suggests putting it inside the user’s home folder. I gather this isn’t the most secure option. It’s also not a good idea to place the Django project folder inside the Apache public_html folder, am I right? I read both these things somewhere a while ago but I can’t recall exactly where. Anyways, to set the record straight, where would you people recommend I place my Django project folder on my VPS?

[Bill Freeman]

I'm sure that you'll get many opinions, but:

I've had success with git, presuming that filesystem space is not very tight on the remote server.  You arrange your deployment scripts to run on the remote (there are several tools to help with that, or for small scale operations, ssh in and run them directly.  These scripts do a pull from your central git repository (if you've got that on something other than your development box, such as github, then your code and version history are now redundantly in 3 places, at least), and then check out the revision that has passed continuous integration (you will want to eventually) and code review (buddy up with someone in the same boat if need be - I don't care how good you are, a second set of eyes is a treasure).  And if it bombs, or a problem shows up, rollback to the previous version is just another checkout, your typed commands being the only things that must cross the network.  If you had migrations with the new version, you may have to run reverse migrations (a DB backup on the remote or DB server just before installing a update is a good idea).

As to the security of the user account on the server box, that depends on whether the user does anything else, and how automagically someone cracking your development box can leverage that into access on the server.  Worse that having stuff in a random user account also used for other things is having this stuff under root.  It means that you have to get into root way too often, and also a bug that tries to blow things away has the root access to do it.  I've often deployed with apache, and made the /www directory belong to apache.  Nothing there is served by apache except by being explicitly listed in the apache configuration, such as directories for CSS and js that are populated by running django's collectstatic management command, which your scripts should run, among other things, after checkout of a different revision..  The project directory and probably a venv directory are there for convenience, but can't be served by apache.  I presume that Nginx is similarly competent.  It was used at a few places I worked, but I didn't have to deploy it, so I've not learned the details.

Bill

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/994e80b8-0c4d-439c-b0e3-636b8e4f00e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.