Рекомендации по управлению версией рабочего процесса / архитектуре для проектов аппаратного обеспечения (ECAD), документации и микропрограмм - PullRequest
0 голосов
/ 02 июля 2019

Должны ли мы использовать SVN или GIT?для следующего варианта использования

Как нам организовать систему:

1: «главное репо», содержащее все проекты и автономные драйверы, которые используются в проектах, каждый проект / драйвер являетсяразные "ветки"?

пример:

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

2: Отдельные репозитории для каждого проекта и отдельные драйверы?нам нужно будет «вытянуть» или «слить» репозиторий с драйверами в репозиторий проекта.Это важно, чтобы продемонстрировать возможность знать, какие проекты затронуты в случае ошибки в слое драйверов.

Project1Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


Project2Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


DriversRepo
|---driver1
|   \--src
|   \--includes
|---driver2
|   \--src
|   \--includes

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

Должен ли каждый драйвербыть в отдельном репо?

Мы являемся производителем встраиваемой электроники в автомобильной промышленности.Пока я не начал, команда разработчиков не использовала какую-либо систему контроля версий, все было «версионно» через папки и почтовые индексы.и аппаратная сторона вещей все еще использует этот способ управления версиями.

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

MasterSoftwareRepo
|-Documentation
|-MicroControllerMFG1
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project1
|          \--active
|             \--src
|             \--test
|             \--build
|          \--release
|             \--srev1
|             \--srev2
|             \--srev3
|          \--projectSupport
|       \--Project2
|          \--active
|          \--release
|          \--projectSupport
|       \--Project3
|-MicroControllerMFG2
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project10
|       \--Project11
|       \--Project13
|-MicroControllerMFG3
| \--FamilyOfMCUs

.......................and so on. 

Система работает ... Это не красиво и не эффективно.Поскольку мы использовали систему, скажем, 6 месяцев, и общий размер хранилища превысил 40 гигабайт.И из-за структуры мы действительно используем управление версиями, как задумано, это больше папок с историей.

Еще немного опыта, наша команда среднего размера, но команды, работающие над каждым проектом, очень малы ... 1 программное обеспечение, 1 аппаратное обеспечение, 1 механическое устройство на проект.и у каждого из нас может быть 1-2 проекта одновременно.У нас в отделе 20 человек.

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

Каковы некоторые предложения для нашего варианта использования?Мы считаем, что идея 1 репо слишком велика, но мы застряли на идее ее использования, чтобы мы могли вытянуть из драйверов.и базовая структура проекта и т. д., поэтому у нас есть полная готовность к началу.

Должен ли аппарат быть отдельным репо?Можем ли мы включить его в наш репо как филиал или как мы это сделаем?

Не используя размещенные решения, все решения должны быть размещены самостоятельно.

И да, я знаю, что это длинный пост, но я подумал, что чем больше деталей я дал, тем лучше вы можете понятьситуация и наш случай использования.

1 Ответ

0 голосов
/ 02 июля 2019

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

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

Это позволит вам хранить вашу документацию и ECAD в одном и том же хранилище, но только локально просматривать текущую / последнюю версию файлов.

Я думаю, что первый вариант хранилища будет лучшим решением в настоящее время

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

Что касается количества веток - можете ли вы выполнить все свои проверки в ветке из запроса на извлечение? или вам нужно проверить изменения в течение 1-2 месяцев, прежде чем определить, являются ли они стабильными / хорошими?

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

Если второй вариант лучше, вы можете использовать двойную структуру ветки - одну 'master' и одну 'stable' - где у вас есть основная ветка разработки, которая находится в тестировании - и финальная версия / стабильная ветка, где изменения пойдет - как только они будут проверены на линии разработки.

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

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