How to avoid error 500 after syncing local apps with remote ones?

Question

Django

I am creating my first Django project and have already released the first version to production.

But soon I ran into a problem that was unexpected for me, when it would seem (for me) there is nothing criminal in what I did - no. I synchronized the folder with my apps/* applications with remote hosting through the desktop ftp application and this provoked a 500 error.

Technical support almost looked for a violation of the scripts for 4 hours and really could not give an answer why everything worked.
They only suggested that it is mandatory to synchronize the installed modules for the future.

Here's what I did locally before uploading: 1. Installed a
third-party module with its own dependencies
2. Removed the module after testing (didn't compare requrements with pip list for tails)
3. Updated the file with custom filters in the templatetags folder
4. Renamed it and changed this name to index.html

Then it was synchronized, where __PYCACHE__ flew from all subfolders of my applications and a new file appeared in templatetags, which I renamed on local (here there are two of them , of course, but I don’t think that this could cause the scripts to stop working)

My assumptions:
1. or the caches merged into one
2. or still pip install / uninstall on local could somehow affect
Maybe there is something else, what I do not see

Help, who understands what is happening, so that I no longer fall into such a trap. In principle, I would like to understand what is allowed to be combined, and what is only individually handled on the server to edit.
If there is an article on this topic, I would be grateful for a link.

Thanks in advance.

Answer 1

• bytecode of two versions of the application should not be mixed, rake off
  
• virtual environment for the same reasons cannot be updated on the fly
  
• 5 years ago, I would have suggested switching application versions on symlinks, but now you can use any containers you like for the same purpose
  
• it would be nice to have 2 servers, switch one at a time and make sure that the next release does not break the previous one running at the same time, but this already depends on the ratio of QoS to costs