Как вы деплоите django приложение на сервер?
Исходя из вашего вопроса - "деплой" это разворот сервера с нуля до рабочего состояния.
Все зависит от количества деплоев:
1. Если вам достаточно задеплоить 1 сервак и забыть про него - проще поднять руками.
2. Если вы постоянно разворачиваете > 2 серваков - однозначно надо использовать автоматизированные инструменты.
Рассмотрим несколько популярных инструментов:
1. Ansible - на мой взгляд самый удобный инструмент для быстрой и удобноый работы с парком серверов, устанавливает весь софт и настройки на вашей VPS.
2. Docker - позволяет создать на вашей VPS еще одну виртуальную машину с заранее прописанными настройками и софтом, также его иногда используют для параллельного запуска нескольких БД / веб - серверов и т.д.
3. Также есть Puppet, Chef, Salt - ими не пользовался.
Рассмотрим другое толкование слова "деплой" - заливка изменений проекта на сервер, который находится в рабочем состоянии (т.е. имеется уже рабочий проект)
Тут все зависит от размеров проекта:
1. Если проект маленький / средний fabric вполне справляется с такими задачами, как подтянуть изменения из репозитория / собрать статику / перезагрузить nginx и т.д., но использовать его для разворота сервера - это тяжелая работа, которую проще делать с помощью других инструментов (описано выше). Сам я тоже использую fabric для обновления прода.
2. Если проект большой и приближается к хайлоаду - то надо использовать Continuous Integration, это позволит вам сделать автоматизированную выкладку кода на боевой сервер - к примеру, пушите коммиты в репозиторий на github, срабатывает хук, начинает работать Jenkins, идет прогон тестов, при успехе тестов обновляется прод. 
Инструментов для CI много:
1. Jenkins - простой и бесплатный, с кучей расширений и прочих плюшек.
2. Travis-CI - бесплатный для опен сорс, платный для приватных проектов (69$ минимальный план).
3. Buildbot, tox - не использовал. P.S. Я думаю, что понятие "деплой" - это выкладка изменений на боевой сервер. То, что делаете вы - создаете новый сервер, разворачиваете окружение - ближе к развороту сервера. Если так делается каждый раз, когда льются изменения на боевой сервак - надо менять workflow.
ну Вы же понимаете, что универсального способа быть не может - все зависит от размеров проекта
главный вопрос, на который ищется ответ при деплое - "все ли работает", откуда два шага 1) обновление кода 2) тестирование
с (1) проблем нет: у нас Ansible, но, думаю, хоть fabric, хоть админ с командной строкой (хотя надо избегать такого из-за непередаваемости опыта) код обновит
а вот с (2) ... все проблемы: например, на тестах заглушка базы, и все отрабатывает, а на проде какой-нибудь новый автоинкремент/sequence и привет...
поэтому такой распределенный зоопарк продакшинов и тестировочных машин можно поддерживать только автоматически + сохраняя в репе те же конфиги Энсибла
плюс основная боль   - на какие участки писать тесты, на "все где хочется" никогда не будет хватать времени
По-нормальному (по-взрослому), при выкатке на прод нужно использовать CI only, но даже там например, при распространенности JIRA, мы используем не Bamboo (Бамбу тоже, но эпизодически), а Jenkins   - с ним банально больше умеющих тестировщиков, т.е. не так просто люди осваивают новые инструменты
Все это окупается, когда проект большой, слабой зависимостью от кадров, отсутствием необходимости вспоминать "как было" и т.д., но стоит это время, много времени, много оплачиваемого времени
Сократить время можно только знанием о неизменности участков кода, что, ессно, для больших проектов очень сложно.
Поэтому единственное, что полезное для Вас из этого топика - рекомендация использовать Ansible 
что касается Докера  - то, ессно, никаких Докеров на Проде,
однако, если, возможно, в вашей практике образы идут как способ быстрого восстановления  и проекты небольшие - то почему бы и нет