WedX - журнал о программировании и компьютерных науках

рабочий процесс git + предварительная подготовка

Нужна помощь в организации веток и рабочего процесса.
Предварительные условия: 10 разработчиков с git, 0 юнит-тестов, 10^5 строк кода.

В нашем репозитории есть ветка master, которая действует как production.
Каждая функция разрабатывается в отдельной ветке, которая также создает новый домен (branch.qa.com).

Когда это будет сделано, команда QA просматривает изменения на branch.qa.com, а затем объединяется с мастером и автоматически отправляется на рабочий сервер.

Проблема:
в ветке А может быть css изменений. Он загружается в A.qa.com и проверяется.
Тем временем разработчик разветвляет ветку B из master и работает над ней, модифицируя ту же css.

Оба изменения кажутся законными для своих веток, но может случиться так, что изменение в B на самом деле сломает что-то в A.

Объединение A с master будет в порядке. Тогда слияние B с master плохо повлияет на изменения, сделанные A.

Как вы исключаете такие ситуации? Как включить pre production?

git git-flow workflow
06.03.2013

  • недавно переключился на рабочий процесс git rebase, кажется, хорошо работает на работе, поскольку гарантирует, что master только когда-либо перематывается вперед, возможно, стоит проверить. 06.03.2013
  • Из любопытства, как вы управляете Каждая функция разрабатывается в отдельной ветке, которая также создает новый домен? 16.11.2016
  • @kursus, это было давно, но на сервере git был хук, при фиксации он запускал скрипт, который добавлял виртуальный хост в конфиг nginx, если он не был добавлен ранее, вытаскивал код куда-нибудь и указывал на него серверу . 17.11.2016

Ответы:


1

Если вы следуете git-flow, у вас есть отдельная ветка develop, из которой ответвляются все новые функции, а затем объединяются обратно после их завершения.

Затем из ветки develop вы создаете временные ветки release, которые тестируются (и, возможно, при необходимости исправляются), а затем объединяются с вашей веткой master/production.

Таким образом, ветвь develop на самом деле заканчивается как ветвь pre production.

Если затем вы позволите своему отделу контроля качества выполнить проверку функций, прежде чем он будет объединен обратно в develop, и все переходы к release и master, я полагаю, вы получите то, что хотите, в своей текущей структуре отдела.

Диаграмма здесь: https://nvie.com/posts/a-successful-git-branching-model/

В качестве дополнительного примечания: в настоящее время мы внедряем git-flow вместе с проверкой кода через gerrit, что даст нам платформу для обработки всего этого — хотя в нашем случае разработчики и QA-команда — одни и те же люди (хотя и с добавленным Jenkins CI с автоматическим тестированием).

06.03.2013
  • Спасибо за ответ. Как вы предлагаете перенести изменение с develop на master? QA завершили проверку branch.qa.com, подошли к разработчику и попросили его объединить его с develop. Затем они проводят еще один цикл контроля качества на develop.qa.com. Когда они подтвердят, они снова побеспокоят разработчика, чтобы он объединил develop в master. Сложно автоматизировать. 06.03.2013
  • Я мог бы представить себе использование gerrit, чтобы позволить QA просматривать и проверять функции, прежде чем они будут объединены в develop, а затем выполнить окончательный тест перед объединением ветки release в master? Это должно хотя бы в какой-то степени автоматизировать процесс. 06.03.2013

    • 2

    Вы можете взглянуть на эту ссылку https://nxvl.blogspot.com/2012/07/a-continous-delivery-git-branching-model.html

    Думаю, в вашей организации отсутствует ветка "develop".

    подготовительная стадия может быть ветвью "develop", а производство - ветвью "master".

    Вы не можете напрямую объединить свою ветку "master" без дальнейшего тестирования из-за возможного конфликта между ветвями (здесь конфликт - это не только "конфликт git", но и конфликт алгоритма)

    06.03.2013
  • Ага. Это точно моя проблема. Таким образом, вы предлагаете два сеанса контроля качества. Первый находится в одной независимой ветке функций, второй - в ветке develop после слияния? 06.03.2013
  • необходимо два сеанса контроля качества. Во-первых, для вашей ветки, чтобы убедиться, что все в порядке, а во-вторых, в ветке разработки, где все объединено, чтобы убедиться, что у вас нет никаких взаимодействий между вашими ветвями. 06.03.2013
    • Новые материалы
    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..
    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..
    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..
    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..
    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..
    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..
    ИИ в аэрокосмической отрасли
    Каждый полет – это шаг вперед к великой мечте. Чтобы это происходило в их собственном темпе, необходима команда астронавтов для погони за космосом и команда технического обслуживания..
    Для любых предложений по сайту: wedx@cp9.ru