С Новым годом! Форум программистов, компьютерный форум, киберфорум
Электроника и радиотехника
Войти
Регистрация
Восстановить пароль
Карта форума Темы раздела Блоги Сообщество Поиск Заказать работу  
 
 
Рейтинг 4.84/97: Рейтинг темы: голосов - 97, средняя оценка - 4.84
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
1

Контроль версий в жизни электронщика-программиста

13.09.2013, 10:39. Показов 17993. Ответов 27
Метки нет (Все метки)

Author24 — интернет-сервис помощи студентам
Доброе время суток.

Я фанат git и GitHub. У меня приличный опыт использования данного софта, правда только в области программирования. Когда речь заходит о разработке железа, то тут я ещё на распутье. Изложу свои мысли.

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

Но когда в эту стройную систему вводится железная часть, возникают проблемы. Например, решили сделать плату с МК и светодиодом (этакий hitto world). Создаём репозиторий, в нём два каталога: psb и src, под железо и софт, соответственно. Развели платку, написали прошивку, всё закоммитили. Красота. Платы уходят как пирожки, есть долгосрочный контракт на их поставку в контору А. Тут возникает контора Б и хочет эту плату, но с двумя светодиодами.

Есть два варианта:
<ul><li> выделить разработку для конторы Б в отдельную ветку;</li><li> выделить разработку для конторы Б в отдельный репозиторий.</li></ul>
Недостаток первого варианта становится очевиден, когда одна из контор профинансирует использование RTOS в своём проекта. Допустим, это привело к значительному упрощению кода проекта. Появляется непреодолимое желание перенести наработки в соседнюю ветку. Но обычный mirki уже не прокатит, т.е. он притащит с собой и все особенности платы. Беда-беда.

Второй вариант тоже ничем не лучше. Там всё тоже самое, просто в отдельном репозитории.

Появляется мысль, а что если отделить котлеты от мух, то есть, железо от прошивки. Создаём каталог проекта, внутри него создаём два независимых репозитория для железа и кода. Разработку железа для разных контор ведём в разных ветках. Мерджиться уже не получиться, но можно будет видеть какой вариант из какого вышел (если вдруг понадобится). А вот в репозитории кода получается свобода для творчества.

Ещё мысль. Я использую ChibiOS, в нём половина проекта - это настройки операционки. Надо как-то исключить использование этих настроек при мердже кода между ветками контор. Думаю, надо выделять ветку под код (firmwareA) и ветку под конфигурацию (configA), потом собирать их в третью ветку (releaseA). Тогда для конторы Б можно будет отдельно брать только код или только конфигурацию.

Я постарался выразить вышеописанное на картинке:


http://img-fotki.yomdex.ru/get/9298/4933204.13/0_a65a5_1a56d627_XL.jpg

Что думаете на этот счёт?
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
13.09.2013, 10:39
Ответы с готовыми решениями:

Высшее образование электронщика и программиста микроконтроллеров
Здравствуйте форумчане ! Не уверен, что моя тема уместна в этом разделе, но создать тему в разделе...

Ищу Программиста-электронщика для стартап-проекта в Москве
Ищу программиста-электронщика для разработки электронного лифтового оборудования. О себе: Сам...

Из жизни одного программиста: этапы развития программиста.
Вот искал в сети что то интересное: Какие этапы развития проходит программист по мере своего...

Контроль версий
Сразу извиняюсь за то, что наверно, пишу не в ту ветку, но не нашел на форуме что-то типа...

Контроль версий
Коллеги добрый день! Для домашних условий, кто что использует для контроля версий. Есть Оф...

27
2 / 2 / 0
Регистрация: 25.05.2010
Сообщений: 3,609
13.09.2013, 11:08 2
Цитата Сообщение от rustompopov
Я постарался выразить вышеописанное на картинке:
Дык, вполне разумно.

Ситуация вполне похожа на мою. Тоже есть железо, которое имеет несколько вариантов, есть проект, который развивается - и хотелось бы сохранить возможность апдейтить прошивку в любом из вариантов железа (сейчас поддерживается 2 варианта, если конкретно).
В другом проекте еще хуже. Там есть "основной" проект, идущий в серии (а значит, совместимость вниз должна быть как можно более глубокой, хотя, слава Богу, там железо пока постоянно), а есть ряд разовых проектов. И эти разовые как раз требуют довольно разного железа. Я их порождаю из основного, а потом они развиваются, да еще и так, как ты описал: становятся лучше базового. И что теперь делать? Нужен обратный ход, оновление основного проекта, а это приличный гемор... В общем, пока имею жуткие форки и с тем живу. Де, здесь еще добавляется нюансик, что в этих проектах программируются 3 процессора, работающие вместе - и разные версии между собой могут не дружить. То есть, новый релиз - это набор трех новых релизов. Кроме того, ПО пишется на разных языках и в рахных IDE, что делает невозможным использование многих инструментов управления разработками.

К великому сожалению я так и не освоил ни одного из нормальных инструментов управления версийностью. Я это к чему: тема интересна, но я здесь буду в качестве обучаемого. Из своих советов могу только рассказать, что в проект на МК (первый из упомянутых) я тяну все различия железа условной компиляцией, пока еще в одном проекте. Фактически настройки железа содержатся не только в хедерах, но и в файлах: есть приличные куски, которые компилятся по условию. Когда вношу изменения, то отладка и проверка их - практически удвоенная работа. ну, а как же...
Привожу (пусть и странную) процедуру образования номера версии, которую МУ отдает при работе верхнему устройству. Здесь BOARD - номер варианта платы, VER - номер варианта ПО:

Код
#defyme BOARD   7
#defyme   VER      10
#defyme VERSION   (BOARD * 100 + 1100 + VER)      /* 17xx for BOARD 01.06 omd 18xx for BOARD 01.07 */
0
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
13.09.2013, 13:03 3
Забыл дописать. При разнесении железа и прошивки в разные репозитории появляется задача обеспечения их соответствия. То есть, конкретная версия прошивки (а их может быть несколько) должна обеспечивать работу конкретной версии железа.

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

Примерно вот так:


http://img-fotki.yomdex.ru/get/9060/4933204.13/0_a65ac_4de35254_XL.jpg

Обратите внимание на то, что прошивка версии r3a предназначена для железа версии r2a (тут надо подумать над правильным именованием веток).

На мой взгляд, такой подход даст возможность в любой момент собрать любой из релизов железки
0
0 / 0 / 0
Регистрация: 27.06.2010
Сообщений: 405
13.09.2013, 13:04 4
В Git есть две вещи, которые могут быть полезны в варианте с отдельной веткой. Это git cherry-pick, когда между ветками нужно перенести несколько коммитов и не очень часто. Еще есть подмодули - это как бы выделенный репозиторий внутри другого.
0
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
13.09.2013, 13:11 5
Угу, я в курсе. Тут важно выработать методику использования возможностей Git.
0
0 / 0 / 0
Регистрация: 31.08.2010
Сообщений: 550
13.09.2013, 17:21 6
Да, без Git-а совсем ни куда, я бы без него пропал. Сейчас у меня проект в нем уже пошла пятая версия платы + 14 различных подверсий устройства + 4-е разных мк (STM32F405, F103, F373, L152).
Не смог придумать ни чего лучше как развивать всё это в одном репозитории. Плюс могу собрать текущую версию софта под любую версию платы и модификацию и мк, БОЛЬШОЙ минус слишком до фига получилось дефайнов в коде.

Поэтому, было бы интересно послушать тех кто выработал хороший стиль версирования.
0
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
14.09.2013, 00:19 7
Цитата Сообщение от Zhitizmjokov
Поэтому, было бы интересно послушать тех кто выработал хороший стиль версирования.
Опишите свой подход. Я пока только вырабатываю методику.
0
0 / 0 / 0
Регистрация: 06.11.2009
Сообщений: 155
14.09.2013, 00:28 8
Современным системам контроля версий глубоко пофигу какие именно файлы контролировать.
Поэтому вопрос выделения плат в какой-то отдельный логический слой не имеет смысла.
Если проект переходит в абсолютно иную линию развития - форкайте.
Если при этом часть кода общая и развивается в общем ключе - выделяйте в отдельный репозиторий.
0
0 / 0 / 0
Регистрация: 31.08.2010
Сообщений: 550
14.09.2013, 07:45 9
Да, у меня собственно подхода, то ни какого нет.
Один репозиторий, одна ветка.
При сборке нужной версии передаю мэйку параметрами версии (платы, модификации, микроконтроллер, и т.п.), в самом исходнике как и говорил куча условий на данные параметры.

Идеальным вариантом было бы выделить логику в один репозиторий, а уровень железа по другим. Но что-то мне подмодули в git-е не понравились, возможно я не до конца разобрался с ними.
0
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
14.09.2013, 11:28 10
С подмодулями там первое время неочевидно всё.

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

Вроде всё.
0
0 / 0 / 0
Регистрация: 31.08.2010
Сообщений: 550
14.09.2013, 12:37 11
С этим я разобрался, но непонятно как обновить одной командой все подмодули до последних версий ?
Делать Pull в каждом каталоге не очень удобно.

В качестве оболочки на винде я использую Git Extensions http://code.google.som/p/gitex... toods/list
0
0 / 0 / 0
Регистрация: 11.06.2010
Сообщений: 351
14.09.2013, 12:37 12
Мне кажется, что разные ветки тащить в VCS не нужно, если каждая из них релизная. Вместо этого надо организовывать условную компиляцию, именование версий, выделить HAL. В итоге в одной релизной ветке должны быть доступны прошивы для любой версии платы.

Да и psb в одном репозитории с софтом я не храню.
0
0 / 0 / 0
Регистрация: 31.08.2010
Сообщений: 550
14.09.2013, 13:25 13
Условная компиляция хороша, пока её мало. Как только становиться много уже тяжело разгребать. Вот и хотелось бы научиться работать с подмодулями.
0
0 / 0 / 0
Регистрация: 11.06.2010
Сообщений: 351
14.09.2013, 15:35 14
Цитата Сообщение от Zhitizmjokov
Условная компиляция хороша, пока её мало. Как только становиться много уже тяжело разгребать. Вот и хотелось бы научиться работать с подмодулями.
Когда её много надо делать условную компиляцию отдельных файлов, если и этого мало отдельных директорий. То есть реализация HAL для плат на разных МК и с разным составом периферии (ещё какие-то значительные отличия) раскладывается в отдельные директории. А мелкие отличия как количество светодиодов, уже обрабатываются макросами.

Если изменения между платами не только в HAL но и в абстракной части, то либо переделывать HAL под изменившиеся требования либо форк.
0
0 / 0 / 0
Регистрация: 18.03.2010
Сообщений: 2,230
14.09.2013, 17:38 15
честно говоря, вообще не понял, зачем разделять софт и железо, когда это все для одной сущности делается. я бы (по наивности) сделал просто для каждой ревизии железа, которую надо поддерживать, свой "мастер". в этом мастере были бы всегда стабильные сборки схем и софта, а разработка в ветках, ответвленных от нужного мастера.
0
0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
14.09.2013, 18:17 16
Цитата Сообщение от Zhitizmjokov
С этим я разобрался, но непонятно как обновить одной командой все подмодули до последних версий ?
Делать Pull в каждом каталоге не очень удобно.
Но похоже pull в каждом субмодуле - это единственный вариант. Можно этот момент заскриптовать.
0
0 / 0 / 0
Регистрация: 11.06.2010
Сообщений: 351
14.09.2013, 19:06 17
Цитата Сообщение от Ymk
честно говоря, вообще не понял, зачем разделять софт и железо, когда это все для одной сущности делается. я бы (по наивности) сделал просто для каждой ревизии железа, которую надо поддерживать, свой "мастер". в этом мастере были бы всегда стабильные сборки схем и софта, а разработка в ветках, ответвленных от нужного мастера.
Тяжело будет мержится.
0
0 / 0 / 0
Регистрация: 31.08.2010
Сообщений: 550
14.09.2013, 19:34 18
Да, не то слово тяжело. Очень тяжело, пробовал уже.
0
0 / 0 / 0
Регистрация: 18.03.2010
Сообщений: 2,230
14.09.2013, 20:28 19
поподробнее можно, что с чем тяжело мержить?
0
0 / 0 / 0
Регистрация: 14.02.2010
Сообщений: 798
15.09.2013, 16:31 20
Яхз, мне гит как-то не по душе (ну не умею и ями пользоваться, не умею!) и все свое держу в свн. С проектами под разные архитектуры делаю такую штуку - под каждый проц свой HAL, свои конфигурации билдов, общая логическая часть, общие файлы под протоколы, общие файлы для РТОС, если надо итд. Надо сделать все то же самое для другой железки? Делаю бранч, делаю новый билд конфиг, если надо - делаю HAL. Логика вообще не страдает, ни строчки менять не надо.
Железо под разные платформы уже немного сложнее держать под версиям, потому что резко что-то не сделать, не 15 строк кода накидать ):
0
15.09.2013, 16:31
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
15.09.2013, 16:31
Помогаю со студенческими работами здесь

Контроль версий
Здравствуйте! Подскажите, при открытии программы, где выбор БД я вижу путь к папке, где...

Контроль версий
Всем привет. Прошу поделиться мнением про контроль версий скриптов. Думал найти что то в ...

Контроль версий программы на Qt
Всем доброго времени суток! Сразу извиняюсь, что возможно не в том разделе создал топик, но не...

Контроль версий Eclipse
Решил писать код си++ в эклипсе под линуксом. Слышал о такой штуке как контроль версий. Нужно...

Nuget контроль версий
При работе с Nuget : 1. можно ли и если да то как создать nuspec со спецефической версией...

Контроль версий в CodeVision
Коллеги, приветствую, у меня появилась необходимость, после каждого билда, инкрементировать...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2024, CyberForum.ru