Как разработчики используют управление исходным кодом, я пытаюсь найти самый эффективный способ сделать управление исходным кодом в маленькой dev среде
Я работаю в группе из 4 разработчиков .NET. Мы редко работаем над тем же проектом одновременно, но это действительно время от времени происходит. Мы используем TFS для управления исходным кодом. Моим новым примером является проект, который я просто поместил в производство вчера вечером, которое включало 2 сервиса WCF и фронтэнд веб-приложения. Я работал из ответвления, названного "напоминанием", потому что приложение является совершенно новым и никогда не выходило в свет. Теперь, когда проект жив, я должен отклониться ответвление напоминания для функций, ошибок, и т.д...
Таким образом, что лучший способ состоит в том, чтобы сделать это?
Я простой создаю новое ответвление и вид архива старое ответвление и никогда не использую его снова?
Я отклоняюсь и затем объединяюсь, мое ответвление возвращается в ответвление напоминания, когда я хочу развернуться к производству?
И что относительно файла и версии блока. Они в настоящее время в 1.0.0.0. Когда они изменяются и почему? Если я исправляю небольшую ошибку, которую изменяет число если таковые имеются? Если я добавляю опцию, которую изменяет число если таковые имеются?
То, что я ищу, - то, что Вы нашли, чтобы быть лучшим способом эффективно справиться с управлением исходным кодом. Большинство мест я работал всегда, кажется, ударяет по головам с системой управления исходным кодом в на пути или другом, и я был бы точно так же, как для обнаружения то, что Вы нашли, что работает лучшее.
6 ответов
Хорошей практикой является наличие отдельная ветка для поддержки каждой выпущенной версии и еще одна для продолжения разработки. Таким образом, вы всегда можете выпускать выпуски с исправлениями ошибок для старых версий независимо от новых функций, над которыми вы работаете в основной ветке.
В долгосрочной перспективе лучше оставить основную ветвь в качестве ветки разработки и создать отдельную ветку поддержки для каждого конкретного выпуска; это сокращает пути к ветвям. (Я работал над проектом, в котором путь к фактической рабочей ветке был примерно таким: main / release_1.0 / release_1.1 / release_1.5 / release_2.0 / release_2.1 ...вы не хотите идти по этому пути: -)
Конечно, вам нужно периодически объединять любые исправления, сделанные в ветке (ах) поддержки, обратно в основную ветку - по крайней мере, перед созданием следующего выпуска. По моему опыту, категорически не рекомендуется оставлять слияния до последней минуты - чем позже вы сливаетесь, тем больше разницы между двумя ветвями, и тем выше вероятность возникновения проблем. Инструменты автоматического слияния сдаются, если сложность изменений для слияния превышает определенный порог ... а ручное слияние не приносит удовольствия.
Управление версиями может быть в значительной степени вопросом личных предпочтений. В небольшом проекте вам может понравиться схема версий major.minor , в более крупном проекте вам может потребоваться более тонкий контроль с использованием номеров версий патчей и / или сборки.
Вам необходимо разработать политику версий, а затем придерживаться ее. Например. если вы используете схему версий major.minor , увеличьте младшую версию для выпусков с исправлениями ошибок и основную версию для новых выпусков функций.
Публикую свой ответ на предыдущий вопрос. YMMV, но это обзор нашего текущего процесса разработки (у нас здесь около 10 разработчиков, и мы используем SVN для управления версиями):
Вот наш типичный цикл разработки; мы «псевдо-гибкие»; и работать с двухнедельным циклом выпуска.
Все проекты начинаются на ответвлении от ствола. Без исключений.
После завершения проекта и завершения проверки кода разработчику дается зеленый свет на слияние этой ветви с основной ветвью. Сюда; ни один код, который не был тщательно проверен, не попадает в ствол. Мы используем CruiseControl для непрерывной интеграции, поэтому после фиксации в основной строке, если какие-либо тесты не пройдут, разработчик несет ответственность за их исправление. Эти исправления находятся в багажнике.
За неделю до следующего выпуска; мы создаем «тег» выпуска (по сути, другую ветку) и отправляем его QA. Если вы еще не слили свой код обратно в магистраль, он не выйдет в следующем выпуске. (Важное примечание: этот "тег" выпуска никогда не объединяется с основной веткой. Когда-либо.) Поскольку QA находит ошибки; они возвращаются разработчику. Когда разработчик их исправляет; их изменения должны быть зафиксированы как в теге выпуска, так и в стволе.
Когда наступит день релиза; мы выпускаем все на этом теге. В случае исправлений после выпуска; мы следуем тем же принципам, что и в цикле контроля качества, таким образом, если кто-то присоединяется к новому проекту в основной ветке после того, как тег выпуска был вырезан; он не будет случайно выпущен вместе с аварийным исправлением.
Вспенить, промыть, повторить ...
Это может не отвечать на ваш вопрос сам по себе; но, надеюсь, это послужит хорошей внешней точкой зрения на то, как вы, возможно, захотите настроить процесс разработки. Это был не наш первоначальный процесс, а то, что мы придумали за последние год или два, и, по моему опыту, это на дрожжах впереди того, как мы делали это раньше.
Если вам нужны пояснения по этому поводу; просто оставьте мне комментарий, и я буду обновлять его по мере необходимости.
В этой книге не рассматривается конкретно TFS, но она может быть полезна, чтобы получить некоторую справочную информацию об использовании контроля версий на практике и о том, как применять различные «техники», такие как ветвление.
Pragmatic Version Control http://oreilly.com/catalog/9780977616657
Это одна из лучших статей по ветвлению/слиянию, которые я читал. Она основана на SVN, но может быть применена к TFS.
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html
Вот отличная ссылка от рейнджеров VSTS из Microsoft по некоторым стратегиям ветвления системы управления версиями. У него есть несколько различных вариантов в зависимости от размера вашей команды и желаемого уровня контроля.
Отметьте/разделите каждый выпуск и оставьте его нетронутым. У нас есть ветка разработки и ветка поддержки. Пусть поддержка/исправления ошибок работают в ветке поддержки, а новые функции разрабатываются в ветке разработки. Вы можете выпускать промежуточные релизы исправлений ошибок для производственного программного обеспечения по мере продвижения, не внедряя новый код из ветки разработки, это и есть незначительные повышения версии, например, переход от 1.0 к 1.1 или 1.01 и т.д. Затем, когда цикл разработки заканчивается, и вы готовы к выпуску релиза, вы объединяете ветки dev и support для создания релиза с новыми возможностями + исправлениями ошибок, это и есть основные релизы, например, 1.x - 2.x или 1.2x - 1.3x. Очень важно тщательно документировать все фиксации исправлений в ветке поддержки. Таким образом, перед слиянием веток поддержки и разработки вы сможете проверить каждую по отдельности, чтобы понять, какое влияние она окажет на ветку разработки, например, является ли исправление ошибки в ветке поддержки исправлением чего-то, что было полностью переписано в ветке разработки и поэтому должно быть полностью исключено из следующего крупного релиза.