Если над вами работают только вы и еще один разработчик, то ночные сборки, вероятно, не принесут вам особой пользы.
Я бы сказал, что эквивалентом ночных сборок в веб-приложении будут промежуточные сайты (которые могут быть созданы ночью).
Когда ночные сборки в промежуточной зоне начинают приносить реальные дивиденды, это когда у вас есть клиенты, менеджеры проектов и специалисты по контролю качества, которым необходимо видеть обновленную, но относительно стабильную версию приложения. Ваши песочницы разработчика (если вы похожи на меня, по крайней мере), вероятно, проводят много времени в непригодном для использования состоянии, когда вы ломаете вещи, пытаясь реализовать следующую функцию. Таким образом, типичная проблема заключается в том, что специалист по обеспечению качества хочет проверить, исправлена ли ошибка, или премьер-министр хочет проверить, что какая-то запланированная функция была реализована правильно, или клиент хочет увидеть, что вы достигли прогресса в решении проблемы, которая его волнует. около. Если у них есть доступ только к песочницам разработчика, есть хороший шанс, что когда они увидят его, либо версия песочницы не работает (так как это означает, что ./manage.py runserver где-то в терминале), либо в сломанном состоянии из-за чего-то еще. Это действительно тормозит всю команду и тратит много времени.
Похоже, у вас нет промежуточной настройки, поскольку вы просто автоматически обновляете рабочую версию. Это может быть хорошо, если вы в порядке более осторожны и дисциплинированы, чем я (и я думаю, что большинство разработчиков), и никогда не делаете ничего, что не является полностью пуленепробиваемым. Лично я предпочел бы удостовериться, что моя работа прошла через хотя бы некоторый поверхностный контроль качества кем-то, кроме меня, прежде чем она попадет в производство.
Итак, в заключение, установка, где я работаю:
- каждый разработчик запускает свою собственную песочницу локально (так же, как вы это делаете)
- на dev-сервере есть "обычная" промежуточная песочница, которая обновляется каждую ночь с помощью cronjob. ПМ, клиенты и QA идут туда. Им никогда не предоставляется прямой доступ к программным средам разработчика.
- Существует автоматическое (хотя и инициированное вручную) развертывание в производство. Разработчик или руководитель проекта могут «подтолкнуть» производство, когда мы чувствуем, что все в достаточной степени проверено и стабильно и безопасно.
Я бы сказал, что единственным недостатком (помимо небольшого количества дополнительных затрат на настройку ночных промежуточных сборок) является то, что это делает день исправления ошибок. то есть QA сообщает об ошибке в программном обеспечении (основываясь на просмотре ночной сборки в тот день), разработчик исправляет ошибку и фиксирует ее, затем QA должен подождать до сборки следующего дня, чтобы убедиться, что ошибка действительно исправлена. Обычно это не такая большая проблема, так как у каждого достаточно вещей, которые не влияют на график. Когда приближается веха, и мы находимся в замороженном режиме, только для исправления ошибок, мы будем чаще обновлять промежуточный сайт вручную.