Дмитрий

Разницы, ради которой стоит переустанавливать ОС не будет. Это же не РНР 5.5 на 7.4 менять...

От грамотной настройки зависит гораздо больше обычно, чем от свежести версии. Если случается какой-то прямо прорыв в производительности - обычно об этом активно пишут и всё такое.

Правильно - хранить код в одном репозитории.
На проде не требуется даже иметь гит или что там у вас в качестве системы контроля версий.
Нужно настраивать CI/CD так, чтобы в контейнер на прод выкатывались только нужные файлы и каталоги, ничего лишнего.
Очень удобно, когда в девелоперском окружении код работает без докера, но сопутствующие вещи вроде БД и прочих сервисов удобно держать в контейнерах и на девелоперской машине. Так проще развёртывать среду разработки и быстрее вводить сотрудников в процесс. Технически нет особых проблем, чтобы настроить удалённую отладку прямо внутри контейнера. так можно приблизить девелоперское окружение к продовой конфигурации.

Вообще очень многое зависит от сложности вашего проекта, от количества и связности ваших модулей, от механизмов, направленных на масштабируемость.

Храните всё, что нужно для CI/CD в том же репозитории где код. Там же у вас лежат тесты (не нужные в продакте), вспомогательные скрипты, артефакты тулинга и прочее.
Поищите, в гитхабе есть много так называемых "КукиКаттеров". Это инструмент, для шаблонизации проектов на разных стеках. Как правило в созданной по такому шаблону заготовке проекта уже есть всё не обходимое для CI/CD.

Ни в коем случае не пушить туда-сюда.

• В идеальном случае ваш проект должен поддерживать миграции:
  
• Каждая ревизия кода, которая нарушает совместимость с БД относительно предыдущей, должна содержать скрипт миграции. В этом скрипте создаётся структура, модифицируются старые данные, переименовываются поля и т.д. Иногда такие скрипты делают двунаправленными, чтобы поддерживать обратные миграции.
  
• В БД нужно хранить версию или номер ревизии, которой соответствует текущее состояние БД.
  
• При запуске приложения нужно проверять версию и выполнять цепочку миграций, необходимых для приведения версии к требуемому состоянию.
  

Так вы можете добиться того, чтобы продуктовая БД была отдельно, тестовая отдельно, девелоперская отдельно. Очень плохая идея работать на девелоперской машине с данными из продовой базы. Так происходят утечки перс-данных.

Монга - это schema less БД, которая толерантно относится структуре коллекций и не валится при запросе несуществущих полей. Нужно стараться писать код максимально толерантно к отсутствию наполнения БД.

В любом случае у вас в БД есть обычно:

1. структура (в случае монги, как я уже сказал, это не так важно)
   
2. справочники
   
3. пользовательские данные
   
4. производные данные (кэш), которые можно безболезненно удалить, а затем они перегенерятся сами по мере запросов.
   

Нужно писать код так, чтобы он всю структуру и технические справочники, отсутствующие в предоставленной БД и необходимые для работы, умел инициализировать сам. Или, на худой конец, сделайте команду или скрипт init_db.

Если какие-то тестовые данные нужны для тестов или отладки, то можно сделать скрипт, который заполнит БД ими. Это называется фикстуры.

Никогда не храните код в БД. Всякие хранимые процедуры и прочее в БД - это зло. Код должен быть в системе контроля версий, а БД к этому не приспособлены. Если уж нужны хранимки, то храните их в системе контроля версий и заливайте их в БД при инициализации или миграциями.

Не использовать telnet. Есть вполне себе нормальный api, ну или хотя бы ssh.

Алексей очень хорошо описал причины, которые подтверждаются некоторым личным опытом.

Очень часто, в логах сервера, в user-agent можно встретить selenium. Достаточно в конфиг прописать правило отклонения запросов с user-agent: (*selenium*) и проблема исчезает.

Также, те, у кого стоит метрика, могут обнаружить посетителей, которые ничего не делают, после чего отправляют ip в бан руками.

Обходить это, можно загружая страницу через браузер и случайно сдвигать мышь, случайное количество раз (от 5-10), через случайные промежутки. Спасет от ручной проверки, для большинства сайтов.

Для 100% гарантии, чтобы не банили, нужно "наводиться" на ссылки, которые нужно распарсить следующими (по очереди). Однако, в этом случае, вы пожертвуете производительностью парсера.

Как реализовать: Поднять сервис (несколько) на машине с vnc и получать страницу через браузер, имитируя работу мышкой.

Но, обычно, указать корректный user-agent достаточно. (Я, почему-то уверен, что вы остановитесь на этом варианте).

Однако, самым примитивным способом отследить, что твой сайт парсят, является мониторинг нагрузки сайта на сервер. Дело в том, что подавляющее большинство сайтов находиться на виртуальном хостинге, где владельцу сайта, сдается в аренду часть вычислительной мощности сервера.

Владельцу сайта проще заблокировать тот ip, с которого сыпятся запросы, чем проводить оптимизацию кода сайта и выяснять, по какой причине вообще создалась нагрузка (например, из-за не проставленных индексов в бд).
А порой, это является единственным вариантом, т.к. на сервер, может прилететь за час свыше 10000 запросов к сайту с одного ip.
Для сравнения от yandex/google, за сутки, может прийти около 4000 запросов (с минимальными настройками индексации).

В заключение, я скорее всего озвучу желания владельца сайта: "Пожалуйста, собирайте информацию с сайта адекватнее и наиболее приближенно к реальным запросам от людей. Не пытайтесь выгрузить весь сайт за раз в короткий промежуток времени. Тем более, не тестируйте не завершенную программу на реальных сайтах."

берется два алфавита с разными сдвигами и применяются по очереди, к первой букве первый алфавит, ко второй - второй, к третьей снова первый и т.д.

Плюсую Дмитрия.
Плюс от себя: https://githowto.com/ru

https://git-scm.com/book/ru/v2