Эта публикация здесь (Как вы управляете версиями базы данных в проекте среднего размера с ветвями?) заставила меня задуматься, как лучше всего работать над веб-проектом, используя ветвление и развертывание для разработки, подготовки и производства (вместе с локальными копиями).
У нас нет «релизов» как таковых: если функция достаточно велика, чтобы быть заметной, мы публикуем ее вживую (после необходимого тестирования и т. д.), В противном случае мы объединяем несколько и, когда это будет «удобно», те живут. Цель состоит в том, чтобы никогда не развертывать более одного-двух раз в месяц или около того, потому что постоянно меняющийся сайт имеет тенденцию беспокоить пользователей.
Вот как мы это делаем, и это кажется довольно хрупким (в настоящее время используется svn, но с учетом перехода на git):
Некоторые из этих шагов имеют значительную сложность, и на практике их очень сложно выполнить (TRUNK -> DEV всегда ломается), поэтому я должен представить, что есть способ получше.
Мысли?
Очевидной мыслью было бы больше «перебазировать» (чаще сливается из «родительской» среды 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 в магазине, в котором я работаю. Пока мы занимаемся разработкой на C++, управление версиями довольно универсально. Ниже приводится наш подход, вы можете решить, что является разумным для вашего подхода.
У нас ВСЯ разработка происходит в ветке. Мы отвечаем за каждую ошибку и каждую функцию. В идеале эта ветка посвящена ТОЛЬКО одной функции, но иногда этого не должно быть.
Когда работа завершена, протестирована и "готова", мы объединяем изменения в ствол. Наше правило - ни в коем случае не допускать нарушения кода в магистрали. Если сломанный код попадет в магистраль, его исправление становится приоритетом 1.
Релизы создаются, когда все функции выполнены и объединены: ветвь для релиза создается как тег. Тег позволяет нам получить шапшот, если нам нужно. Ветка позволяет нам поддерживать нашу предыдущую версию. Исправление ошибок в выпущенной версии осуществляется путем перехода к ветке этого выпуска, ответвления от нее. Когда все в порядке, изменения объединяются обратно в ветку выпуска и, при желании, полностью в магистраль.
Ветвление удобно, если вы ожидаете, что работа не будет завершена вовремя, и у вас нет достаточного количества тестов для непрерывной интеграции. Я склонен видеть безумную разработку в магазинах, где задачи программирования слишком велики, чтобы их можно было выполнить предсказуемо, и поэтому руководство хочет подождать непосредственно перед выпуском, чтобы определить, какие функции должны быть выпущены. Если вы выполняете такую работу, вы можете рассмотреть возможность использования распределенного управления версиями, где КАЖДЫЙ рабочий каталог является естественным ответвлением, и вы получаете всю локальную регистрацию и локальную историю, которую вы можете съесть, никому не причинив вреда. Вы даже можете выполнить перекрестное слияние с другими разработчиками вне магистрали.
Я предпочитаю, когда мы работаем в нестабильной магистрали с ветвями для кандидатов на выпуск, которые затем помечаются для выпуска и которые затем становятся потоком для аварийных исправлений. В такой системе очень редко бывает больше трех веток (последний выпуск, текущий выпуск-кандидат, нестабильный ствол). Это работает, если вы выполняете TDD и используете CI на нестабильной магистрали. И если вам требуется, чтобы все задачи были разбиты, чтобы вы могли доставлять код так часто, как захотите (обычно задача должна длиться от одного до двух дней и выпускаться без всех других задач, составляющих ее функцию). Так что программисты берутся за работу, проверяют магистраль, выполняют работу, синхронизируются и проверяют в любое время, когда все тесты проходят. Нестабильная магистраль всегда доступна для ветвления как кандидат на выпуск (если все тесты пройдены), и поэтому выпуск не является событием.
В целом, лучше означает: меньше веток, короче задачи, меньше времени на выпуск, больше тестов.
И я хотел бы отметить, что второй сценарий более удобен с svn до 1.5, так как в svn1.4 или меньше история слияний не записывается, поэтому частые слияния сделать сложнее.