Как Вы осуществляете "deploy" на "production"?
Вопрос к разработчикам или команде разработчиков, возможно что это касается и студий, разрабатывающие и поддерживающие сайты клиентов.
Допустим, Вы работаете с определенным проектом, соответственно у Вас настроено именно под свои нужны «development» окружение (веб-сервер, сервер БД и пр.). Где-то на отдельном сервере (может быть совсем удаленном) работает тот же самый проект, но уже в окружении «production», предназначенный для конечного пользователя. Вы определенно работаете с системой контроля версий (svn, git, etc.). В конкретный момент времени в dev-окружении выполнена определенная задача (зафиксирована стабильная ревизия). И необходимо выполненную работу перенести в «production».
Вопрос в том, какими инструментами Вы пользуетесь.
У нас довольно примитивная система. Проект на Django, хранится в mercurial, есть две ветки: staging и production. Все изменения (за исключением совсем срочных багфиксов) по умолчанию идут в staging. При релизе изменения из staging пушатся в production, на сервере самописный shell скрипт выполняет pull и перезапускает сервер. Скрипт запускается вручную.
Еще используется buildout, который управляет всеми зависимостями проекта, два конфигурационных файла. В окружении разработчиков используется конфигурация, в которую включены django-debug-toolbar, в которой определены безопасные умолчания (например, использование песочницы PayPal вместо настоящего аккаунта PayPal, и т.п.). На сервере используется конфигурация без средств отладки.
maven'ом пользуюсь, там настроены три профиля — dev, staging, production, соответственно, при сборке указывается нужный.
В плане веток и прочего — используется Maven Release Plugin.
Это если очень коротко.
Извините, но совсем непонятно, что вы хотите услышать в ответ на свой вопрос. Ведь средства деплоя очень тесно связаны с платформой, на которой построено приложение, от серверной ОС и от веб-сервера, который используется в продакшене. Для каждой технологии — свои средства.
У нас, к примеру, ASP.NET приложение, для автоматического build'а которого написан NANT-скрипт. Этот скрипт также апдейтит базу данных и деплоит приложение на IIS.
Но какая польза вам от этой информации, если у вас приложение на PHP или Python'е, и все крутится под апачем и линуксом?
Польза в том, что я помимо названия инструмента смогу примерно понять, как это работает на .NET платформе. А предпочтение у меня linux + php. Может быть и свой велосипед напишу.
Вопрос был «Как вы заливаете на продакшн», кто сказал, что я заливаю все коммиты? Если надо заливать — включаю опцию, не надо — выключаю. Эта опция прямо в окошке коммита в PHPStorm:
Весь код коммитится в SVN, при этом каждый коммит относится к определенной задаче в Redmine.
По мере тестирования и закрытия задач, с помощью Hudson (Jenkins) и ant-a делается сборка, и накатывается на предпродакт. А оттуда уже, в случае успеха, на продакт. Каждая версия (сборка) содержит diff, с помощью которого можно накатить/откатить патч.
Схема сложная, но она работает. До этого был полный бардак.
Простой
Средний
