Где я могу узнать об управлении надежным процессом развертывания между средами разработки и производства?

Остановимся на минутку и вспомним Зачем мы в первую очередь разделяем среду разработки и производственную среду.

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

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

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

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

По сути, вам нужны инструменты двух типов: инструменты тестирования и инструменты развертывания.

Как минимум, все вы действительно необходимо два сервера: рабочий сервер и тестовый (промежуточный) сервер. Сначала вы протестируете свои изменения на своей локальной рабочей станции. Если все в порядке, вы отправляете свой код на промежуточный сервер и снова тестируете его. Если все еще кажется, что все в порядке, вы отправляете его в производство и ждете, пока сработает пожарная сигнализация.

Одна из самых эффективных методологий тестирования вашего программного обеспечения - это непрерывная интеграция. С помощью этого метода всякий раз, когда вы регистрируете код в общем репозитории, сервер проверяет код и запускает весь ваш набор тестов. (Вы написали модульные и функциональные тесты для вседа?) Он также может выполнять интеграционное тестирование. Если все тесты пройдены, вы можете настроить такие инструменты на продвигать код в производство и развернуть его автоматически. Например, это делает Github. Сегодня два распространенных инструмента CI - это Jenkins и Travis.

Наконец, есть развертывание. Это кажется очевидным: вы копируете свой новый код на (промежуточный или производственный) сервер, а затем указываете веб-серверу запускать новых исполнителей на новом коде. Такие инструменты, как Capistrano, Commando или Deployer, помогают автоматизировать это. Они также обычно могут вернуться к предыдущему развертыванию, если что-то пойдет не так. (И ваш язык или среда должны иметь способы справиться с откатом изменений схемы базы данных, таких как миграции в Rails. Для Flask вы можете использовать что-то вроде SQLAlchemy и Alembic.)

Конечное состояние, в котором вы, вероятно, захотите быть, - это состояние, в котором у вас есть 100% тестовое покрытие, с модульными, функциональными и интеграционными тестами для всего, так что вы можете воспользоваться преимуществами непрерывной интеграции для развертывания ваших изменений - или выявления ошибок - как как можно быстрее. Начните с малого, с одного «тестового» сервера, и продвигайтесь вверх, пока не доберетесь до цели.

Почему не стоит запускать разработку в продакшене

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

Как вы можете настроить свою среду

1. Настройте простой обратный прокси-сервер NGINX.
2. Настроить staging.yourwebsite.com сайт с собственной папкой
3. Создайте производственный сайт с собственной папкой
4. Ограничьте промежуточный сайт только своим домашним IP-адресом

Простой пример конфигурации NGINX:

upstream production {
    server 127.0.0.1:5000; # Default Flask address
}
upstream staging {
    server 127.0.0.1:5001;
}

server {
    server_name yourwebsite.com default_server;
    access_log /var/log/nginx/yourwebsite_access.log;
    error_log /var/log/nginx/yourwebsite_error.log;
    location / {
        proxy_pass http://app;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header  Host            $host;
        proxy_set_header  X-Real-IP       $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
     }
}

server {
    server_name staging.yourwebsite.com;
    access_log /var/log/nginx/staging_access.log;
    error_log /var/log/nginx/staging_error.log;

    allow YOUR_IP_ADDRESS;
    deny all;

    location / {
        proxy_pass http://staging;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header  Host            $host;
        proxy_set_header  X-Real-IP       $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
     }
}

Я действительно не понимаю вашего вопроса / проблемы.

Однако есть методика переноса чего-либо из разработки в производство: это называется ITIL

Это «весь текст», он предоставляет / описывает лучшие методы и процессы для того, чтобы что-то от Dev до Prod, минимизируя и контролируя риски ...