Как перенести файлы в производство?

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

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

Как я могу автоматизировать процесс передачи файлов в производство? Разве плохо иметь производственные файлы под контролем версий? Таким образом, отправка в благословенный репозиторий будет означать развертывание. Но что происходит, когда возникают конфликты слияния? Будет ли работать производственный сервер, пока он не будет решен?

Проще говоря:
сам процесс подталкивания должен быть полностью автоматическим. Независимо от того, есть ли у вас какой-то нестандартный скрипт или вы просто вытаскиваете из «счастливого» репо в производственную среду. Это зависит от вас. Вам просто нужно что-то автоматизировать, потому что автоматизированные процессы можно сделать надежными (в отличие от загрузки файлов вручную и тому подобное).

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

Это звучит немного медленно, в том смысле, что петля обратной связи является относительно большой. Но для правильного тестирования важно сделать фиксированный снимок, который затем проверяется в течение 24-48 часов (или, может быть, дольше, в зависимости от размера проекта). Противоположным является сценарий, в котором вы обнаружите множество ошибок сразу после нажатия и попытаетесь исправить их с помощью некоторых быстрых исправлений, которые вводят новые ошибки.
Лучше сделать релиз с известными ошибками (приемлемой серьезности), чем с неизвестными ошибками (неизвестной серьезности).

Я многое узнал о развертывании, посмотрев, как работает Capistrano. В то время я работал с RoR, так что это был логичный выбор, и хотя я так и не смог заставить себя вести себя в проекте, над которым я работал, способ, которым он выполняет автоматические обновления, был очень полезен.

Вы можете оказаться в ситуации, когда вы можете использовать его напрямую даже - он не обязательно привязан к Rails - но если нет, то, как он ведет себя, безусловно, полезно.

В зависимости от используемой вами платформы, существует множество инструментов, которые могут иметь смысл использовать для автоматизации производственных выпусков. Я работаю в магазине .NET, поэтому мы использовали NAnt (хотя MSBuild - лучший вариант в настоящее время). На Java есть Ant и, возможно, другие вещи. У Руби есть такие вещи, как Рейк. Кроме того, существуют платформы непрерывной интеграции, такие как TeamCity и Hudson, которые также можно использовать для управления выпусками.

Я никогда не видел и не слышал о том, чтобы иметь код продукта непосредственно в отдельном репозитории с исходным кодом, но это, безусловно, может сработать. Как сказал back2dos, ключом является автоматизация. У нас есть наши сценарии сборки, разработанные для проверки из исходного кода, сборки и отправки в промежуточную среду для тестирования. Затем, когда нам нравится, как работает постановка, скрипты копируются из QA в Prod.

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