Я использую Git для управления циклом разработки своего веб-приложения, а также для изменений, в которых git pull достаточно и никаких изменений не требуется, я просто поддерживаю сайт в рабочем состоянии и git pull перемены.
Но я думаю, скажем, у меня было изменено 100 файлов, и что на диск была некоторая неожиданная загрузка, что произойдет, если кто-то сделает запрос в течение в тот момент, когда git фиксировал изменения на диске? Разве это не сделает мое приложение уязвимым для возможного повреждения данных или искаженных ответов?
Я имею в виду, что это очень и очень маловероятно для веб-сайта с низким трафиком, но если вы получите действительно высокий трафик и произойдет всплеск нагрузки на сервер, есть некоторый риск.
Я действительно думал о решении, но, вероятно, это не лучшее решение, если я откатываю свою собственную реализацию, и я не уверен, насколько оно практично. Я помню, как читал статью о том, как мы не видим артефактов на наших экранах, в основном путем записи новых данных в совершенно другой блок памяти графического процессора, а затем просто переключения актуальные данные экрана (как бы это ни называлось) указатель к новому блоку и, возможно, отбрасывая или повторно используя старый блок в конце. Таким образом, если графический процессор отстает, наполовину записанные данные отображаться не будут.
Было бы это практично, если бы можно было реализовать такую же вещь?
Вам понадобится балансировщик нагрузки. Он может обеспечивать постепенные обновления, высокую доступность и горизонтальное масштабирование.
Большие, нетривиальные, но почему-то постоянно обновляющиеся сайты постоянно меняются незначительно. Возможно, они выпускают ежедневное обновление или какая-то функция не работает, но все еще работает. Они решили, что не стоит отказываться от немного другого пользовательского опыта. Вам нужно будет принять собственное решение о том, включает ли ваше решение запланированные простои.
На отдельном веб-сервере определенные методы развертывания обеспечивают более резкий переход. Предварительное развертывание кода и последующее его перемещение на место - более чистый вариант, чем обновление рабочей копии в реальном времени. Хотя это не учитывает базы данных, обновления веб-сервера и другие сложности. Вы по-прежнему хотите, чтобы балансировщик нагрузки давал вам варианты.
Один из канонических способов сделать это, независимо от того, что вы используете git или нет (но с его помощью вы можете реализовать эту схему с некоторыми из ее хуков), это иметь каталог на веб-сайте, где вы устанавливаете каждую новую «версию» в ее собственном конкретном каталоге, например, с меткой даты / времени в ее имени . Настоящий живой контент, используемый в настоящее время веб-сервером, находится в другом пути, который является символической ссылкой на один каталог «версии».
После завершения передачи и проверки, что все прошло хорошо (отсутствие недостающих файлов, правдоподобное содержимое, правильные права Unix, отсутствие болтающихся символических ссылок и т. Д.), Вам просто нужно изменить символическую ссылку с "производственного" пути на ваш путь новой "версии".
Изменение символической ссылки почти атомарно, поэтому это не вызовет сбоев.
Это также позволяет легко вернуться: просто снова измените символическую ссылку.