Используя Мерзавца как управление исходным кодом для веб-разработки и нескольких среда
Мало контекста: Мы - команда 6 разработчиков, работающих веб-приложение. Начиная с запуска мы использовали CVS в качестве нашей системы управления исходным кодом на Windows Server с помощью ColdFusion w/Eclipse. Со всей шумихой вокруг Мерзавца и распределенных систем в последнее время мы думали, что проверим ее.
Как стандартное веб-приложение у нас есть наше окружение, где мы разрабатываем новые функции/исправления ошибок. Среда разработки, где мы требуем у всего начальное тестирование QA. Подготовка, куда мы отправляем, показывает/устраняет, которые уже были протестированы, эта среда должна подражать как можно больше наши рабочие серверы. Наконец все идет на переживать систему в дикой местности...
Этот процесс является довольно болезненным когда-то, когда большая часть из него сделана с FTP и что не и часто мы встречаемся с конфликтами при фиксации, так как что-то занимает больше времени чем обычно для тестирования или когда быстрое исправление ошибки требуется срочно.
Я немного смущен относительно того, как Мерзавец работал бы в этом случае, это - очевидно, не редкий сценарий, но большая часть того, что я нашел, не говорил об этом в деталях.
Если я понимаю, что правильно локальные ответвления играют значительные роли с Мерзавцем, я клонируюсь, репозиторий мерзавца сначала тогда расширяются, фиксируют что-то и фиксируют его назад все локально?
Тогда я добираюсь для фиксации его назад основному репозиторию под соединительной линией, имеющей дело с конфликтами слияний, если существует кто-либо?
Если мои предположения корректны тогда, основной вопрос - то, что происходит с подготовкой. Очевидно, некоторые показывают/устраняют, занимают больше времени для тестирования, некоторые являются более срочными, и т.д. я был бы в состоянии просто сделать что-то как получение по запросу определенных функций/ответвлений на подготовку для окончательного утверждения и затем сделать то же с живого сервера (получение по запросу, поскольку они закончены)?
Это довольно много для взятия в происхождении из среды CVS... любая справка значительно ценилась бы!
1 ответ
- Локальные ветви важны, потому что вы можете создавать их сколько угодно и легко объединять.
- Отслеживающие ветки (фактически локальная ветка, следующая за удалённой отслеживающей) гораздо более актуальны в вашем случае, так как они позволяют вам формально связать локальную ветку с удалённой для публикации (ещё одна замечательная возможность DVCS: вы можете "публиковать" коммиты в одно удалённое репо или другое)
Идея состоит в том, чтобы определить:
- пустое репо для целей толкания
- пустой dev-репо, куда все разработчики могут выкладывать свои текущие работы и/или брать работы от своих коллег (что-то вроде локального "центрального" репо, но существует множество других рабочих процессов, например, описанный на этой странице книги ProGit)
- пустой staging-репо, куда выкладывается staging-ветка с материалами для тестирования/проверки.
Команда QA может клонировать это репо, чтобы получить рабочий каталог staging, в котором они могут запускать и тестировать веб-сайт. - пустое репо на сервере в производственной среде.
Менеджер может клонировать его, а затем rsync/ftp его на реальные производственные серверы, которые будут управлять живым веб-сайтом.
Примечание: у вас не должно быть никаких DVCS на реальном производственном сервере. У вас должно быть только то, что необходимо для запуска/мониторинга производственной среды.
Основной рабочий процесс основан на проталкивании/перетаскивании веток между этими средами (репо):
- на dev и staging репо вы можете поддерживать несколько официальных публичных веток, немного похоже на то, как это делает сопровождающий Git Julio C. Hamano со своими ветками 'public', 'maint', 'next', 'pu'.
- прежде чем выкладывать что-либо в staging, вы можете перебазировать свою работу сначала поверх удаленной ветки staging, чтобы разрешить локально любой конфликт и обновить локальную работу разработчиков с любым исправлением, обнаруженным/сделанным в staging.
- push из staging в prod должен быть тривиальным (никаких конфликтов, поскольку на стороне prod repo не производится никаких изменений)
- вы можете определить хуки на staging repo и prod repo, чтобы принимать только определенные ветки, и отказаться от создания любых веток (в отличие от всех dev-репо, где вы можете определять/толкать/тянуть столько веток, сколько вам нужно)