Продвижение кода с помощью Git

Question

Я пытаюсь понять, как я могу использовать git для нескольких сред (dev-> test-> prod) с продвижением кода.Я немного читал о ветвлении, но не очень понимал, как это может решить мою проблему, поскольку у меня должна быть возможность запускать все среды одновременно и отдельно друг от друга.

Буду очень благодарен за какое-то практическое руководство.

Answer 1

Кажется, это довольно распространенная тема, чтобы иметь этот трехуровневый рабочий процесс.Вот как мы это сделали.Мы магазин Ruby, поэтому здесь тоже есть упоминание о тестировании.

Мы все работаем над отдельными "историями" (из Pivotal Tracker) отдельно друг от друга.Это означает, что если бы мы все выполняли ветку master , то мы бы постоянно наступали друг другу на ноги.Чтобы решить эту проблему, каждый из нас создает новую ветвь (на основе последней master ) для этой конкретной части работы.

Когда мы завершим эту часть работы, мы запустим тестымы сами, и если они проходят, они объединяются с веткой master , где тесты запускаются снова, чтобы убедиться, что не было никаких поломок.Если это так, мы пытаемся использовать git bisect, чтобы выяснить, что это было, и это работает в 99% случаев.

В большинстве случаев (потому что мы действительно классные *) тесты проходят успешно,Когда все тесты пройдут в основной ветке, мы развернем наш промежуточный сервер.Итак, я думаю, это означает, что master является staging ответвлением.Когда эта функция (или, более вероятно, функции) была одобрена, мы объединяем эти изменения в ветку production и затем перемещаем эту ветвь на рабочую площадку.

С этой настройкойотдельные разработчики могут иметь работающую копию приложения для себя, команда QA получает рабочую копию, чтобы перейти к ней, когда у них есть время (это «самая веселая» часть моей работы, собирать людей - это какскотоводство) и в реальном мире есть идеальный сайт.

В теории все равно.Люди делают ошибки.

Answer 2

В моем случае, git push для публикации файлов с dev на тестовый сервер. Затем мы выполняем ежедневные (или еженедельные) сборки (используя phing ) для экспорта приложения на рабочий сервер (там нет git-репо) или публикуем tarball с исходным кодом для загрузки.

Рабочий процесс зависит от конкретных переменных вашего проекта.

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

Естественным способом одновременного изменения всех опций является также изменение репо, поэтому нажимайте между репо dev / test / production.

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

Answer 3

DVCS вводит другое измерение для управления версиями :
«Публикация» (push / pull)

Продвижение кода раньше делалось исключительно через ветви или через ярлыки.

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

Но с DVCS вы можете просто перенести кодовую базу в выделенный репозиторий и считать этот клон «тестовой» средой продвижения.
Обычно вы сначала делаете ребаз вашего текущегоработать над удаленным продвигаемым кодом для локального разрешения любых конфликтов.И тогда вы нажмете (ускоренное слияние на удаленной стороне).

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