Как вы поддерживаете код разработки и производственный код?

Ответ 1

Все зависит от последовательного характера управления выпуском

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

• слишком сложный и нуждается в уточнении
• не готов вовремя
• интересный, но не для следующей версии

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

Когда дело доходит до производственного кода, вам также необходимо управлять ветвями патчей, имея в виду, что:

• первый набор патчей может начаться до первого выпуска в производство (что означает, что вы знаете, что вы пойдете в производство с некоторыми ошибками, которые вы не можете исправить вовремя, но вы можете инициировать работу для этих ошибок в отдельной ветке)
• у других патч-ветвей будет роскошь начинаться с четко определенной производственной маркировки

Когда дело доходит до ветки dev, у вас может быть один багажник, если у вас нет других усилий по разработке, которые вам нужно сделать параллельно, например:

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

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

Чтобы ответить Ville M. комментарий:

• Имейте в виду, что dev branch doe не означает "одна ветвь для разработчика" (что вызовет "слияние безумия", поскольку каждый разработчик должен будет объединить работу другого, чтобы увидеть/получить свою работу), но один разработчик отрасль на развитие.
• Когда эти усилия нужно объединить обратно в багажник (или любую другую "основную" или ветвь освобождения, которую вы определяете), это работа разработчика, а не - повторяю, NOT - диспетчер SC (кто не знает как решить любое конфликтное слияние). Руководитель проекта может контролировать слияние, что означает, что он запускается/заканчивается вовремя.
• кто бы ни выбрал для фактического слияния, самое главное:
  • иметь модульные тесты и/или среду сборки, в которой вы можете развернуть/проверить результат слияния.
  • чтобы определить тег до начала слияния, чтобы иметь возможность вернуться к предыдущему состоянию, если указанное слияние оказывается слишком сложным или довольно длинным для решения.

Ответ 2

Мы используем:

• ветвь развития исключительно

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

• релиз ветки

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

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

Иногда мы также имеем ветки для одного разработчика, работающего над новой и недоработанной технологией, или для создания доказательства концепции. Но обычно это делается только в том случае, если изменения затрагивают многие части кодовой базы. Это происходит в среднем каждые 3-4 месяца, и такая ветвь обычно реинтегрируется (или отменяется) в течение месяца или двух.

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

На раннем этапе регистрации:

Если вам требуется только PERFECT CODE, но на самом деле ничто не должно быть проверено. Никакой код не является совершенным, и для проверки качества и проверки его он должен находиться в ветвь разработки, чтобы можно было создать новый исполняемый файл.

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

Время от времени неизбежный комбинированный код и проверка данных делают программу непригодной до тех пор, пока новый код не будет построен. Самое меньшее, что мы делаем, это добавить "ПОДОЖДИТЕ ДЛЯ СТРОГО" в комментарии о регистрации и/или отправить электронное письмо.

Ответ 3

Для чего это стоит, так мы это делаем.

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

Это означает, что важно сохранить туловище в неопределенном рабочем состоянии, так как это вполне возможно, чтобы полностью сломать его. На практике это случается нечасто и редко является значительной проблемой.

Для выпускной версии, мы выстраиваем соединительную линию, перестаем добавлять новые функции и работаем над исправлением ошибок и тестируем ветку (регулярно сливаясь обратно в багажник), пока она не будет готова к выпуску. В этот момент мы делаем окончательное слияние в багажник, чтобы убедиться, что все там, и затем отпустите.

После этого обслуживание может быть выполнено в ветки выпуска, и эти исправления могут быть легко объединены обратно в магистраль.

Я не утверждаю, что это идеальная система (и у нее все еще есть некоторые дыры - я не думаю, что наше управление выпуском еще достаточно сложное), но она работает достаточно хорошо.

Ответ 4

Почему никто не упоминает об этом? http://nvie.com/posts/a-successful-git-branching-model/

Это для меня конечная модель ветвления!

Если вы маленький проект, не используйте все время в разных ветвях (возможно, вы можете пропустить ветки функций для небольших функций). Но в противном случае это способ сделать это!

Ответ 5

Код разработки для веток, код Live, помеченный в Trunk.

Не нужно быть правилом "совершить только совершенный код" - все, что пропустит разработчик, должно получить в четырех местах: обзор кода, тестирование веток, тестирование регрессии, окончательное тестирование QA.

Здесь более подробное пошаговое объяснение:

• Выполняйте все разработки на ветке, регулярно проводя, когда идете.
• Независимый кодекс Обзор изменений после завершения всей разработки.
• Затем передайте ветку в Testing.
• Как только тестирование завершено, слейте код в ветку Release Candidate.
• Отказоустойчивая ветвь Release проверяется после каждого отдельного слияния.
• Окончательное тестирование QA и UA выполняется на RC после того, как все ветки dev объединены.
• Как только QA и UAT будут переданы, слияние разделительной ветки в ветку MAIN/TRUNK.
• Наконец, пометьте Trunk в этой точке и разверните этот тег в Live.

Ответ 6

dev идет в trunk (svn style) и релизы (производственный код) получают свои собственные ветки

Это "модель по отдельности" (рисунок 3 в Значение ветвящихся моделей/!\pdf)

Ответ 7

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

В код производства не вводится код, прежде чем он будет тщательно проверен (с помощью QA и обозревателей кода).

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

Ответ 8

О да, еще одна вещь - мы сохраняем непроизводственный код (т.е. тот, который НИКОГДА не будет выпущен - например, скрипты инструментов, утилиты тестирования) в cvs HEAD. Обычно он должен быть четко обозначен, поэтому никто "случайно" его не выпускает.

Ответ 9

Я уже ответил на аналогичный вопрос (или ну, вопрос в том же пространстве/направлении), поэтому вы можете проверить этот вопрос: Какие хорошие стратегии разрешить установку исправленных приложений?

Ответ 10

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

Для магистрали единственное правило заключается в том, что фиксация не должна ничего сломать. Чтобы управлять wip-кодом и непроверенным кодом, мы просто добавляем соответствующие, если статусы позволяют легко включать и выключать.

В принципе, можно было бы в любой момент разветкить магистраль и поставить ее в производство.

Ответ 11

Я использую git, и у меня есть 2 ветки: master и maint

• master - код разработки
• maint - производственный код

когда я выпускаю код для производства, я помещаю его в тег, и я объединю мастер в ветку maint. Я всегда развертываю из ветки maint. Патчи из ветки разработки Я вишу - выберите их в филиал и разворачивайте патчи.

Ответ 12

У нас есть ветвь "release", которая содержит то, что в настоящее время производится или будет развернуто в ближайшее время (уже пройденное большинство QA)

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

Изменения получают совершенные разработчиками проекта в свой собственный проект. Периодически выпуск снова объединяется в ветвь разработки.

После того, как рабочие пакеты на ветке все QA'd (unit test, системный тест, просмотр кода, проверка QA и т.д.), ветвь объединяется в ветвь релиза. Новые сборки построены из ветки релиза, и окончательная проверка происходит в этой версии.

Процесс в основном работает до тех пор, пока проблема не будет обнаружена после завершения слияния. Если WP становится "застрявшим" после его объединения, он удерживает все после него до тех пор, пока не будет исправлено (мы не сможем сделать еще один релиз до тех пор, пока не будет выпущен застреленный).

Он также несколько гибкий - очень тривиальное изменение может произойти непосредственно на ветки релиза, если оно было выпущено в очень короткий временной шкале (например, 1-2 дня или около того).

Если изменение по какой-либо причине было напрямую связано с производством (критическая проблема с производительностью, влияющая на клиенту, которая требовала немедленного изменения кода для исправления), эти изменения будут возвращены в BRANCH_RELEASE. Это почти никогда не бывает.

Ответ 13

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