Продвижение кода с помощью Git
Я пытаюсь понять, как я могу использовать git для нескольких сред (dev->test->prod) с продвижением кода. Я немного читал о ветвлении, но не очень понимал, как это может решить мою проблему, поскольку у меня должна быть возможность запускать все среды одновременно и отдельно друг от друга.
Буду очень благодарен за какое-то практическое руководство.
3 ответа
Кажется, это довольно распространенная тема для этого трехуровневого рабочего процесса. Вот как мы это сделали. Мы магазин Ruby, поэтому здесь есть упоминание о тестировании.
Мы все работаем над отдельными "историями" (из Pivotal Tracker) отдельно друг от друга. Это означает, что если бы мы все посвятили себя основной ветке, то мы бы постоянно наступали друг другу на ноги. Чтобы решить эту проблему, каждый из нас создает новую ветвь (на основе последнего мастера) для этой конкретной части работы.
Когда мы завершаем этот кусок работы, мы сами запускаем тесты, и если они проходят, они снова объединяются с основной веткой, где тесты запускаются снова, чтобы убедиться, что не было никаких поломок. Если было, мы пытаемся использовать git bisect выяснить, что это было, и это работает в 99% случаев.
Большую часть времени (потому что мы действительно классные *) тесты проходят. Когда все тесты проходят в основной ветке, мы развертываем наш промежуточный сервер. Итак, я думаю, это означает, что мастер является промежуточной ветвью. Когда эта функция (или, более вероятно, функции) была одобрена, мы объединяем эти изменения в производственную ветвь и затем перемещаем эту ветвь в рабочую.
С этой настройкой все разработчики могут иметь работающую копию приложения для себя, команда QA получает рабочую копию, чтобы перейти на нее, когда у них есть время (это "самая забавная" часть моей работы, сбор люди как пастушьи кошки) а в реальном мире идеальный сайт.
Во всяком случае, в теории. Люди делают ошибки.
DVCS вводит другое измерение для управления версиями:
"Публикация" (push/pull)
Продвижение кода раньше делалось исключительно через филиалы или через ярлыки.
Для среды с несколькими вкладами лучше всего работают отдельные локальные ветви, такие как Райан.
Но с DVCS вы можете просто перенести кодовую базу в отдельный репозиторий и считать этот клон "тестовой" средой продвижения.
Обычно вы сначала перезагружаете свою текущую работу поверх удаленного продвигаемого кода, чтобы локально разрешить любой конфликт. И тогда вы нажмете (ускоренное слияние на удаленной стороне).
Так что это еще один инструмент, который вы можете использовать для продвижения кода (все еще используя ветки или метки: как правило, "производство" лучше всего идентифицируется веткой).
Я в моем случае, git push предназначен для публикации файлов с dev на тестовый сервер. Затем мы выполняем ежедневные (или еженедельные) сборки (используя phing), чтобы экспортировать приложение на рабочий сервер (там нет git-репо) или публикуем tarball с исходным кодом для загрузки.
Рабочий процесс зависит от конкретных переменных вашего проекта.
Переключение серверов - это не только дифференциация версий кода, но и базы данных, среды, конфиги и пользователи.
Естественным способом одновременного изменения всех опций является также изменение репо, поэтому нужно переключаться между репо dev / test / production.
Но вы можете написать свои собственные git-хуки, отвечающие за все эти ключи. Есть много вариантов крючков, которые вы можете выбрать. Ветвь - это просто фиксация, поэтому вы можете использовать ловушку после фиксации, экспортировать только определенные теги или экспортировать содержимое определенной ветви.