Использование контроля исходного кода GIT в среде веб-разработки
В настоящее время я использую GIT с исходным деревом для управления исходным кодом для веб-системы php.
Мой предыдущий опыт работы с GIT связан с отсутствием веб-среды, и я понимаю использование филиалов и удаленных устройств и т. Д.
Но я немного запутался, когда дело доходит до настройки этого для веб-разработки.
Сценарий.
У меня есть живой поддомен
live.mysite.com
У меня есть поддомен dev
dev.mysite.com
Я создаю ветки на сайте разработчиков для историй.
Оформить заказ сотрудникам ветки истории с сайта разработчика, завершить и зафиксировать.
Затем каждая история проверяется тестером и тестируется, после завершения история объединяется с мастером разработки, и в конечном итоге она объединяется с живой.
Это очень широкий обзор, и моя путаница связана с доменами. допустим, у меня есть 10 сотрудников. Им нужно будет просмотреть изменения, которые они делают с любой разработкой. Использование вышеуказанного метода не сработает, поскольку все сотрудники будут развертываться на сайте разработчика.
Чтобы обойти это, я создавал поддомен для каждого сотрудника.
rob.mysite.com
dave.mysite.com
Теперь каждый из них может самостоятельно работать в своем домене и при необходимости подключаться к различным пультам. т.е.
внести изменения на rob.mysite.com
толчок робота дев
нажмите Dev, чтобы жить и т.д.
Хотя такого рода работы, я чувствую, это не правильно.
Это почти ломает весь смысл ветвей, поскольку весь персонал будет ветвиться оттуда в собственном хранилище.
Это правильно, и мне всего несколько шагов или я совсем не в себе?
Решение
Прежде всего, похоже, что сотрудникам нужна среда местного развития. Разработчики не должны выдвигать какие-либо изменения, чтобы протестировать их. Это сильно тормозит развитие.
Общий рабочий процесс может выглядеть так:
- Выберите истории для работы.
- Развивайте свою особенность.
- При необходимости создайте для него ветку, основанную на основной ветке или ветке разработки. Так называемая ветвь функций. Технически, если разработчик фиксирует локально, это уже ветвь.
- По желанию, внесите изменения в удаленную копию ветви функций, если вы хотите сделать резервную копию своей работы.
- Проверьте, работают ли ваши изменения в локальной среде разработки, и запустите тесты.
- Если тесты зеленого цвета, объедините ветвь компонента с веткой master / development.
- Разверните master / development в промежуточной среде и протестируйте его.
- Если тесты хороши, объедините мастер в живую и разверните, чтобы жить.
Вы могли заметить, что это не сильно отличается от вашего подхода. Все изменения будут внесены в одну промежуточную среду. Тем не менее, это хорошая вещь. Вы обнаружите несовместимость между функциями, а не в прямом эфире.
Я хотел бы рекомендовать узнать больше о Непрерывная интеграция а также Непрерывная доставка.
Другие решения
Других решений пока нет …