Проблема цикла веб-разработки SVN

Question

Организация, в которой я сейчас работаю, использует SVN для разработки PHP-приложений. Наш цикл разработки начался с простого: выполнение коммита обновляет веб-корень с помощью ловушки post-commit, чтобы сразу увидеть изменения. Тогда мы столкнулись с проблемой, связанной с тем, что функции разработки мешают исправлению ошибок и удерживают исправленные файлы от перемещения в производство, а иногда и вызывают проблемы на сервере prod.

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

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

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

На этом фоне вот мой вопрос: Какой цикл и / или схему SVN веб-разработки вы бы порекомендовали для этой ситуации? Требует ли это полного пересмотра методологии или я просто упускаю что-то простое?

Спасибо за любые идеи!

Answer 1

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

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

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

Answer 2

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

Все проекты начинаются на ветке из ствола. Без исключений.

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

За неделю до следующего выпуска; мы создаем выпускную метку (по сути, другую ветвь) и отправляем ее в QA. Если вы еще не объединили свой код со стволом, он не выйдет в следующем выпуске. (Важное примечание: этот выпуск «тег» никогда не объединяется обратно в транк.). Когда QA находит ошибки; они возвращены разработчику. Когда разработчик исправляет их; их изменения должны быть зафиксированы как в теге release, так и в транке.

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

пена, промыть, повторить ...

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

Если вы хотите получить какие-либо разъяснения по этому поводу; просто оставьте мне комментарий, и я буду обновлять по мере необходимости.

Answer 3

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

Answer 4

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

Я все делаю в ветках «Feature». Мой макет выглядит так:

branches/
    [feature branches]
    stable/
tags/
    [all of our releases]
trunk/

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

Когда приходит время выпуска, мы берем все функции, которые планируется выпустить, и объединяем их в транк. Одна ветвь функций объединяется, проверяется и, если она исправна, перемещается в стабильную ветвь. Вымойте, промойте, повторите для всех функций ветви.

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

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

Answer 5

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

Опять же, сделайте это сейчас, прежде чем ваши проекты станут более сложными.