SVN в распределенной разработке - лучшая практика? - PullRequest
1 голос
/ 30 марта 2012

Каковы практически проверенные структуры SVN для распределенных систем, разработанные несколькими независимыми поставщиками?

Предположим, система с, например, три уровня (UI, Service, Data) и контракты на обслуживание между ними: каждый уровень состоит из нескольких компонентов, которые разрабатываются разными поставщиками, которые не привязаны к конкретному уровню, например, поставщик A разрабатывает компоненты для пользовательского интерфейса и уровня обслуживания, а поставщик B разрабатывает компоненты для уровня обслуживания и данных.

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

-> Как правильно структурировать SVN в такой настройке?

По поставщику? По слою? И то и другое? ...?

Ответы [ 3 ]

3 голосов
/ 30 марта 2012

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

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

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

Кстати, Git лучше SVN.

2 голосов
/ 30 марта 2012

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

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

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

1 голос
/ 30 марта 2012

Если эти поставщики действительно независимы, я бы не советовал хранить все эти компоненты в одном репозитории SVN.Я бы предпочел предоставить поставщикам отдельные репозитории SVN и контролировать контракты и взаимодействия посредством четко определенного процесса выпуска в / из общего репозитория артефактов (подобных Maven).Например, Nexus имеет возможность ограничения, какие артефакты доступны для пользователя и позволяет контролировать чтение / запись.

...