Subversion, лучшая практика для небольшой команды из 5 разработчиков?

Question

у нас есть настройка SVN через Assembla с CI Team City. Я понимаю систему контроля версий, моя команда новичок в этом? Как мы должны продолжать работу? Прямо сейчас наша среда, не организована, как это должно быть. Я также пытаюсь заставить Трэка работать на нашу группу. Что мы должны сделать, чтобы каждый человек работал там на своей ветке? Слить изменения обратно в ствол, когда они будут сделаны? Или позволить им отработать магистраль и, надеюсь, Teamcity поймает плохие вещи?

Answer 1

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

2. Сейчас наша среда не организована так, как должна быть. Хороший менеджер конфигурации всегда будет думать об этом. Последнее, что вы хотите сделать, это дать представление о том, что вы предпочитаете процесс, а не «реальную работу», поэтому продолжайте двигаться и думать об эволюции здесь, а не о революции. Как и программное обеспечение, для определения командного процесса требуется «план» и хорошая коммуникация.

3. Я также пытаюсь заставить Трэка работать в нашей группе. Хороший ход. Изначально TRAC позволит вашим разработчикам увидеть, что происходит. Но у него также есть тикеты, этапы, пересмотр, приоритеты и куча других сбивающих с толку инструментов, которые могут сбить с толку ваших разработчиков. Итак, во-первых, используйте trac для просмотра временной шкалы svn и удобного инструмента сравнения. Вводите билеты / этапы и т. Д., Когда им удобно работать с самим набором инструментов, и будьте готовы никогда не использовать их, если им это не нужно / не нужно.

4. Что мы должны сделать, чтобы каждый человек работал там на своей ветке? Объединить изменения обратно в ствол, когда они будут сделаны? В конце концов, возможно. Но вы определили проблему, которую решит для вас ветвление / слияние? Помните, ваша команда никогда не сталкивается с подобными проблемами. Я рекомендую подождать, пока вы не столкнетесь с проблемой, а затем решить ее как команду под вашим руководством.

5. Или позволить им отработать ствол и, надеюсь, Teamcity поймает плохие вещи? Сначала да. Затем представьте все хорошее, что вы знаете о CM, когда у вас есть проблемы, не раньше.

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

Answer 2

1 - Обновление
2 - Код
3 - Тест
4 - Update'n'merge
5 - Тест
6 - совершить

Answer 3

Что мы должны сделать, чтобы каждый человек работал там в своей отрасли? Слить изменения обратно в ствол, когда они будут сделаны?

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

Или позволить им отработать на Сундуке, и надеюсь, что Teamcity будет ловить плохие вещи?

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

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

Answer 4

Я оказался в похожей ситуации, мы команда из трех человек, и я был одним из тех, кто настаивал на контроле исходного кода, хотя мой опыт работы с ним ограничен, и я учусь по ходу дела. Я нашел эту статью исключительно полезной: http://www.ericsink.com/scm/source_control.html

Если ваша команда еще не читала это, им определенно следует - это отличная отправная точка.

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

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

Вкратце: Baby Steps: -)

В конечном итоге это окупится.

Answer 5

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

примечание: это то, как мы это делаем в моей компании, и это работает довольно хорошо.

Answer 6

Вот как мы это используем:

1. Все изменения происходят в trunk
2. Что-нибудь экспериментальное? Разветвите это, работайте с этим, пока вы не будете удовлетворены. Объединить обратно к trunk.
3. Все основные релизы помечены

Answer 7

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

1. Транк всегда должен компилироваться.
2. тег для каждого выпуска
3. Все исправления и незначительные изменения должны быть выполнены на стволе.
4. Ветвь для каждого выпуска основной версии.
5. Все основные разработки выполняются в специальной ветке. Они объединяются после QA.
6. Все исправления также выполняются в каждой ветви поддерживаемых версий.

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

Если у вас нет такого рода ограничений, может быть достаточно от 1 до 3. Работа с ветками иногда бывает болезненной.

Если вам нужно запустить несколько крупных проектов параллельно, вам, возможно, придется рассмотреть DVCS, например, Mercurial или Git.