0 / 0 / 0
Регистрация: 09.02.2012
Сообщений: 54
|
|
1 | |
Контроль версий в жизни электронщика-программиста13.09.2013, 10:39. Показов 17993. Ответов 27
Метки нет (Все метки)
Доброе время суток.
Я фанат 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
|
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 под изменившиеся требования либо форк.
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
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 | |
15.09.2013, 16:31 | |
Помогаю со студенческими работами здесь
20
Контроль версий Контроль версий Контроль версий программы на Qt Контроль версий Eclipse Nuget контроль версий Контроль версий в CodeVision Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |