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

Эта публикация здесь (Как вы управляете версиями базы данных в проекте среднего размера с ветвями?) заставила меня задуматься, как лучше всего работать над веб-проектом, используя ветвление и развертывание для разработки, подготовки и производства (вместе с локальными копиями).

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

Вот как мы это делаем, и это кажется довольно хрупким (в настоящее время используется svn, но с учетом перехода на git):

  1. Две «ветки» - DEV и STAGE с заданным выпуском STAGE, помеченным как TRUNK.
    • Разработчик проверяет копию TRUNK для каждого изменения и создает для него ветку.
    • Разработчик работает локально, часто проверяя код (как и голосование: рано и часто)
    • Когда разработчик почувствует себя комфортно, он не сломан полностью, объедините ветку с DEV и разверните на сайте разработки.
    • При необходимости повторите 3-4, пока изменение не будет "завершено".
    • Объединить ветку изменений с STAGING, развернуть на рабочем месте. Делаю ожидаемое финальное тестирование.
    • По прошествии некоторого времени отметьте данную ревизию STAGE как TRUNK и нажмите транк в действии.
    • Объединить изменения TRUNK обратно в DEV, чтобы синхронизировать их

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

Мысли?

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
0
3 858
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

Очевидной мыслью было бы больше «перебазировать» (чаще сливается из «родительской» среды STAGE в «дочернюю» среду «DEV» в ветку разработчика), чтобы минимизировать окончательное влияние TRUNK-> DEV, которое было бы не нужно. больше.

То есть все, что делается в STAGE, что должно быть запущено в производство за один раз (TRUNK), должно быть объединено как можно раньше в ветке DEV и private devs, в противном случае эти поздние слияния с модификацией всегда будут проблемой.

НО, если описанный выше рабочий процесс слияния слишком неудобен, я бы предложил ветку REBASE, основанную на последнем DEV сразу после выпуска (новый TRUNK). Перебазирование TRUNK-> DEV станет TRUNK-> REBASE, где все проблемы будут решены, а затем окончательное слияние DEV-> REBASE, чтобы проверить, что любой текущий разработчик совместим с новой обновленной системой. Последнее тривиальное слияние обратно из REBASE в DEV (и в частные ветки разработки) завершит процесс. Смысл ветки - изолировать усилия по разработке, которые нельзя проводить вместе с другими текущими усилиями по разработке. Если TRUNK-> DEV слишком сложен для работы с текущими DEV, его необходимо изолировать. Отсюда и предложение ветви REBASE.

И я хотел бы отметить, что второй сценарий более удобен с svn до 1.5, так как в svn1.4 или меньше история слияний не записывается, поэтому частые слияния сделать сложнее.

VonC 01.10.2008 08:21

Мы используем SVN в магазине, в котором я работаю. Пока мы занимаемся разработкой на C++, управление версиями довольно универсально. Ниже приводится наш подход, вы можете решить, что является разумным для вашего подхода.

У нас ВСЯ разработка происходит в ветке. Мы отвечаем за каждую ошибку и каждую функцию. В идеале эта ветка посвящена ТОЛЬКО одной функции, но иногда этого не должно быть.

Когда работа завершена, протестирована и "готова", мы объединяем изменения в ствол. Наше правило - ни в коем случае не допускать нарушения кода в магистрали. Если сломанный код попадет в магистраль, его исправление становится приоритетом 1.

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

Ответ принят как подходящий

Ветвление удобно, если вы ожидаете, что работа не будет завершена вовремя, и у вас нет достаточного количества тестов для непрерывной интеграции. Я склонен видеть безумную разработку в магазинах, где задачи программирования слишком велики, чтобы их можно было выполнить предсказуемо, и поэтому руководство хочет подождать непосредственно перед выпуском, чтобы определить, какие функции должны быть выпущены. Если вы выполняете такую ​​работу, вы можете рассмотреть возможность использования распределенного управления версиями, где КАЖДЫЙ рабочий каталог является естественным ответвлением, и вы получаете всю локальную регистрацию и локальную историю, которую вы можете съесть, никому не причинив вреда. Вы даже можете выполнить перекрестное слияние с другими разработчиками вне магистрали.

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

В целом, лучше означает: меньше веток, короче задачи, меньше времени на выпуск, больше тестов.

Другие вопросы по теме