Обмен кодом между решениями в TFS

Question

У меня есть несколько различных приложений, которые мне нужны для совместного использования кода между сокращением обслуживания. Я попытался многое прочитать в stackoverflow и в Интернете в целом, и это довольно распространенная проблема; Я не нашел ответа, который мне нравится.

Наша ветвящаяся структура TFS выглядит следующим образом. У нас есть три филиала: «Разработка, производство и производство». В отделении развития все активное развитие сделано, когда мы закончили разработку новых функций, мы объединим его с Main, а затем и с производством. Производственный филиал всегда является кодом, запущенным на серверах. Если мы обнаруживаем ошибки, которые должны быть исправлены до следующей итерации. Изменения выполняются в основном и объединены с Production при развертывании. Приложения, которые должны совместно использовать код, не имеют общей иерархии ветвлений или общего графика итераций. На самом деле одно из приложений проходит один раз в 1-м итерации один раз в год. (Я знаю, что это немного отличается от обычного способа сделать это

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

Binary обмена:.. Одним из общих Я обнаружил, что разветвление скомпилированного двоичного файла в папку под ветвью разработки. Моя проблема заключается в том, что если мы обнаруживаем ошибки в общем коде, которые должны быть исправлены быстро, соответствующий код компилируется. И если мы где исправить ошибки, которые мы получили бы все изменения, сделанные с общей кодовой базой.

Совместное использование проекта: Моя основная проблема заключается в том, как это можно сделать е приемлемым образом. Моя первоначальная идея заключалась в том, чтобы начать новую итерацию, объединить изменения с основной веткой с общим кодом для ее обновления. Объединение основного раздела с веткой разработки для обновления ветки разработки с изменениями в результате исправления ошибок. И добавьте новую версию обновления общего кода в ветку разработки. Но из того, что я понимаю, это не поддерживается TFS, потому что я создавал бы вложенные ветви.

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

Answer 1

Спасибо всем за вашу помощь, потому что некоторые из вас внесли свой вклад в мое окончательное решение. Я решил опубликовать то, что я здесь сделал.

То, что я в конечном итоге делает был как Binary обмен и код обмена

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

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

Answer 2

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

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

Однако это также означает, что если только один из двух проектов, зависящих от общего кода, нуждается в исправлении ошибки, только этот проект должен принять новую версию.

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

Итак, чтобы быть ясным, мое предложение было бы создать новый проект TFS для общего кода, дать ему всю любовь, которую вы показываете стороннему проекту (его собственная сборка, NuGet и т. Д.), А затем возьмите сборку сборки в библиотечную папку для проектов, которые хотят ее использовать.

Надеюсь, это поможет.

Answer 3

Хотя вопрос не совсем то же самое, я думаю, что ответ может быть на тех же строках, что и this one.