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

Я работаю в группе из 4 разработчиков .Net. Мы редко работаем над одним и тем же проектом одновременно, но это время от времени. Мы используем TFS для управления исходным кодом. Самый последний пример - это проект, который я только что разместил в производстве прошлой ночью, который включал 2 службы WCF и интерфейс веб-приложения. Я работал в филиале под названием "prod", потому что приложение совершенно новое и никогда не видел свет дня. Теперь, когда проект в прямом эфире, мне нужно разветкить ветвь prod для функций, ошибок и т.д.

Так что лучший способ сделать это?

Я просто создаю новую ветку и сортирую архив старой ветки и никогда не использую ее снова?

Отключить ли я, а затем объединить изменения ветвлений обратно в ветвь prod, когда я хочу развернуть их на производство?

А как насчет версии файла и сборки. В настоящее время они составляют 1.0.0.0. Когда они меняются и почему? Если я исправлю небольшую ошибку, какое число изменится, если оно есть? Если я добавлю функцию, число которой изменится, если оно есть?

То, что я ищу, - это то, что вы нашли лучшим способом эффективного управления источником. Большинство мест, в которых я работал, всегда, кажется, пускают головы с системой управления источниками, так или иначе, и я просто хотел бы узнать, что вы нашли, что работает лучше всего.

Ответы

Ответ 1

Хорошей практикой является наличие отдельной ветки для поддержки каждой выпущенной версии, а другая для продолжения разработки. Таким образом, вы всегда можете создавать выпуски исправлений ошибок для более старых версий независимо от новых функций, над которыми вы работаете в основной ветке.

В долгосрочной перспективе лучше сохранить основную ветку в качестве ветки разработки и создать отдельную ветвь поддержки для каждой конкретной версии; это сокращает ваши ветки ветвей. (Я работал над проектом, где путь к фактической рабочей ветки был чем-то вроде main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1... вы не хотите спускаться по этой полосе: -)

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

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

Вам нужно разработать политику версий, а затем придерживаться ее. Например. если вы используете схему версии major.minor, добавьте второстепенную версию для выпусков исправлений и основную версию для новых выпусков функций.

Ответ 2

Вот отличная ссылка рейнджеров VSTS от Microsoft по некоторым стратегиям по ветвлению управления версиями. Он имеет несколько различных опций в зависимости от размера вашей команды и желаемого уровня контроля.

http://branchingguidance.codeplex.com/

Ответ 3

Отметьте/отпустите каждую версию и оставьте ее нетронутой. У них есть ветвь развития и ветвь поддержки. У вас есть исправления поддержки/ошибок в ветке поддержки, а затем новые функции, разработанные в ветки dev. Вы можете создавать промежуточные исправления ошибок в программном обеспечении производства, когда вы идете вперед, не вводя новый код из ветки dev, это ваши незначительные приращения версии, например. начиная с 1.0 до 1.1 или 1.01 и т.д. Затем, когда цикл разработки заканчивается, и вы готовы сделать выпуск, вы объединяете ветки dev и support для создания выпуска с новой функцией + исправления ошибок, это ваши основные релизы, например. 1.x - 2.x или 1.2x - 1.3x. Очень важно, чтобы все исправления ошибок фиксировались в ветки поддержки. Таким образом, прежде чем объединить ветки поддержки и dev, вы можете проверить каждый отдельно, чтобы увидеть, какое влияние на ветвь dev будет, например. является исправлением ошибки для ветки поддержки исправления для того, что было полностью переписано в ветки dev, и поэтому должно быть полностью исключено из следующего основного выпуска.

Ответ 4

Я возвращаю свой ответ из предыдущего вопроса. YMMV, но это обзор нашего текущего процесса разработки (здесь у нас около 10 разработчиков, а SVN - для управления исходным кодом):

Здесь наш типичный цикл разработки; мы "psuedo agile"; и запускается в течение 2-недельного цикла выпуска.

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

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

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

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

Налейте, промойте, повторите...

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

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

Ответ 5

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

Прагматическая версия управления http://oreilly.com/catalog/9780977616657