Локальный, Тестовый и Производственный контроль версий

Question

Я очень плохо знаком с контролем версий , и мне нужна помощь, если это возможно.

Мне было интересно, как лучше всего контролировать 3 среды разработки: Разработка> Тестирование> Производство

• Разработка (среда Localhost) - вся разрабатываемая работа выполняется здесь перед любой загрузкой
  • Каждый1, работающий над конкретным проектом, должен иметь клон этой папки ( каждый соавтор со своим пользователем , если возможно), и каждый толчок пользователем будет отправляться сюда, в папку разработки.
• Тестирование - Должна быть папка клона, содержащая данные, отправленные Development и автоматически синхронизируемая с поддоменом testing с использованием ftp или любого другого протокола.
• Production - это живой сайт, на котором выпускаются стабильные обновления.
  • Должен ли он быть клоном Тестирование , или тестирование при нажатии должно загрузить данные здесь?

Как насчет конфликтных проблем, когда пользователь нажимает файл / файлы, отличные от того, который другой пользователь нажал 1 минуту назад? Конечно, может быть разделение задач, и каждый должен делать определенные вещи, но что если нет, то что, если X фиксирует submit.php, а Y также фиксирует submit.php за 1 минуту до этого?

Какое программное обеспечение для контроля версий будет наиболее подходящим?

Answer 1

Если вы переводите это в терминах DVCS ( Распределенная система управления версиями ), , как Git , каждая из ваших «папок» может быть фактическим клоном вашего хранилища кода.

Это означает, что вы:

• подтолкнет от вашей локальной разработки к репо 'development'
• переместится с 'development' на 'testing' (или, что еще лучше, выполнит задание на 'тестирование', отвечающее за потянув 'development', и вызовет некоторые тесты, если таковые имеются обнаружен новый коммит
• переведет из 'testing' (если тесты в порядке) в производство

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

Answer 2

Git - это здорово, если у вас большая команда, но IMHO Subversion (SVN) проще в освоении и, тем не менее, предоставляет хороший набор основных функций, отвечающих вашим требованиям. Обычный подход к удовлетворению потребностей, о которых вы упомянули выше, заключается в создании хранилища Subversion с тремя папками, называемыми «ствол», «ветки» и «теги».

• Разработка : происходит в подкаталоге trunk.
• Предварительное тестирование : происходит в интеллектуально названном подкаталоге «веток», например 'RC1-тест'
• Поддержка стабильного выпуска : происходит в подкаталоге тегов с версиями тегов, например, '2.0'

По сути, все эти подкаталоги являются ответвлениями от вашей магистрали, которые вы можете создать с помощью команды экспорта SVN.