Итак, сразу опишу нашу ситуацию и потом объясню почему дал этой статье такое глупое название :-)
Наша команда из 4х человек работает на одном проекте (пока не буду говорить, что за проект, надеюсь, напишу о нем позже)
У нас было 3 SVN ветки: Production (стабильная ветка, которая обслуживает запросы пользователей), Staging (промежуточная ветка), Trunk (девелоперская ветка).
В ходе итерации (работаем мы по скраму, Scrum), программисты коммитят в одну девелоперскую ветку (Trunk), после этого изменения и фитчи, накопленные, в ходе итерации переносятся на Staging ветку с помощью команды svn merge, где их тестируют и проверяют наши QA. Далее, чтобы не делать очередной мердж на продакшн (из Staging в Stable) с последующим паническим тестом на продакшене после мерджа. Все что я делал — это менял конфиги на нашем вебсервере.
После релиза:
Т.е. в конце итерации Stable и Staging менялись местами. Stable становился невидимым для пользователей, а бывший Staging — становился продакшеном, т.е именно на него заходят пользователи.
Так мы избавились от одного лишнего мерджа… Но этого нам показалось мало :-) Нет ничего более непредсказуемого, чем инженерная мысль…
Мы решили убрать и второй мердж, точней оставшийся.
Итак, условие задачи: мы имеем девелоперскую ветку, которая всегда содержит последние изменения и две ветки, каждая из которых поочередно выполняет роль продакшена.
Во время последнего мерджа с девела на стэйджинг мы столкнуль с большими проблемами, из-за того, что мы все используем разные операционные системы (Arch linux, Mac OS, Windows Vista), разные IDE (Eclipse, Net Beans, Notepad++, VIM :-)) ) И даже разные настройки внутри одинаковых редакторов (сейчас я собираюсь написать спецификацию о единых настройках редакторов). В связи с этим везде использовались разные символьные последовательности для перевода каретки, некоторые редакторы заменяют табы пробелами и т.д.
В связи с этим, во время мерджа мы не получили конфликтов, SVN все смерджил!!! Фактически одинаковые куски кода. И пришлось вручную все вычекивать, чтобы привести сорцы к желаемому виду.
Но в какой-то момент наши нервы не выдержали! И я просто дропнул staging ветку (svn delete staging), а потом мы просто скопировали текущую девелоперскую ветку (trunk) во вновь созданную (с помощью команды svn copy trunk staging). Все что оставалось сделать это поправить конфиги во вновь созданной ветке, и это все.
Поэтому как такового мерджа нет. В конце каждой итерации удаляется промежуточная ветка (svn delete staging)
И создается новая (svn copy trunk staging). И коммитятся конфиги к ней.
Единственное, что меня беспокоило, что размер репозитория будет быстро расти. Но… насколько я помню, SVN использует Bubble-up метод в частности и для создания ветвей, поэтому вновь созданная ветвь — всего лишь ссылки на уже существующую базовую. А изменения — это дифы с этой базовой ветви.
Поэтому и относительно размера репозитории я вполне спокоен.
Вот сейчас сижу пишу эту статью, а QA тестирует на staging наш проект :-)))
Интересно услышать ваши мнения по поводу такого подхода.
З.Ы.
На самом деле меня даже больше интересовали мнения по поводу мерджа в Git
Например, из слов Линуса Торвальдса: «Я знаю несколько компаний, которые внутри используют git, не подозревая об этом, потому что они все еще держат свои главные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо выполняет слияния. Так что вы можете взять дерево веток из Subversion, импортировать в git, позволить git сделать слияние, что было бы основной головной болью в Subversion, зафиксировать изменения и фактически экспортировать их назад в Subversion, и никто другой даже не узнает, что вы использовали git. Немного грустно, но я слышал о многих, работающих в компаниях в точности по этому сценарию.....»
Git Google Talk
Наша команда из 4х человек работает на одном проекте (пока не буду говорить, что за проект, надеюсь, напишу о нем позже)
У нас было 3 SVN ветки: Production (стабильная ветка, которая обслуживает запросы пользователей), Staging (промежуточная ветка), Trunk (девелоперская ветка).
В ходе итерации (работаем мы по скраму, Scrum), программисты коммитят в одну девелоперскую ветку (Trunk), после этого изменения и фитчи, накопленные, в ходе итерации переносятся на Staging ветку с помощью команды svn merge, где их тестируют и проверяют наши QA. Далее, чтобы не делать очередной мердж на продакшн (из Staging в Stable) с последующим паническим тестом на продакшене после мерджа. Все что я делал — это менял конфиги на нашем вебсервере.
$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}
$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}
После релиза:
$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}
$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}
Т.е. в конце итерации Stable и Staging менялись местами. Stable становился невидимым для пользователей, а бывший Staging — становился продакшеном, т.е именно на него заходят пользователи.
Так мы избавились от одного лишнего мерджа… Но этого нам показалось мало :-) Нет ничего более непредсказуемого, чем инженерная мысль…
Мы решили убрать и второй мердж, точней оставшийся.
Итак, условие задачи: мы имеем девелоперскую ветку, которая всегда содержит последние изменения и две ветки, каждая из которых поочередно выполняет роль продакшена.
Во время последнего мерджа с девела на стэйджинг мы столкнуль с большими проблемами, из-за того, что мы все используем разные операционные системы (Arch linux, Mac OS, Windows Vista), разные IDE (Eclipse, Net Beans, Notepad++, VIM :-)) ) И даже разные настройки внутри одинаковых редакторов (сейчас я собираюсь написать спецификацию о единых настройках редакторов). В связи с этим везде использовались разные символьные последовательности для перевода каретки, некоторые редакторы заменяют табы пробелами и т.д.
В связи с этим, во время мерджа мы не получили конфликтов, SVN все смерджил!!! Фактически одинаковые куски кода. И пришлось вручную все вычекивать, чтобы привести сорцы к желаемому виду.
Но в какой-то момент наши нервы не выдержали! И я просто дропнул staging ветку (svn delete staging), а потом мы просто скопировали текущую девелоперскую ветку (trunk) во вновь созданную (с помощью команды svn copy trunk staging). Все что оставалось сделать это поправить конфиги во вновь созданной ветке, и это все.
Поэтому как такового мерджа нет. В конце каждой итерации удаляется промежуточная ветка (svn delete staging)
И создается новая (svn copy trunk staging). И коммитятся конфиги к ней.
Единственное, что меня беспокоило, что размер репозитория будет быстро расти. Но… насколько я помню, SVN использует Bubble-up метод в частности и для создания ветвей, поэтому вновь созданная ветвь — всего лишь ссылки на уже существующую базовую. А изменения — это дифы с этой базовой ветви.
Поэтому и относительно размера репозитории я вполне спокоен.
Вот сейчас сижу пишу эту статью, а QA тестирует на staging наш проект :-)))
Интересно услышать ваши мнения по поводу такого подхода.
З.Ы.
На самом деле меня даже больше интересовали мнения по поводу мерджа в Git
Например, из слов Линуса Торвальдса: «Я знаю несколько компаний, которые внутри используют git, не подозревая об этом, потому что они все еще держат свои главные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо выполняет слияния. Так что вы можете взять дерево веток из Subversion, импортировать в git, позволить git сделать слияние, что было бы основной головной болью в Subversion, зафиксировать изменения и фактически экспортировать их назад в Subversion, и никто другой даже не узнает, что вы использовали git. Немного грустно, но я слышал о многих, работающих в компаниях в точности по этому сценарию.....»
Git Google Talk
