[OparinVD 0]

Всем доброго дня!

Начну издалека. У нас в команде появился менеджер проектов, и недавно с ним состоялась беседа, типа:
- А как вы решаете merge конфликты?
- А у нас нет merge конфликтов , у нас каждый делает свой ipcore, и не бывает так, что несколько разработчиков коммитят изменения в один и тот же исходник...

Потом еще долго говорили о том, что каждый должен разбираться во всём проекте, а еще нужна непрерывная интеграция и т.д. Сходу я не нашел объективных аргументов "против" кроме как "я не пробовал, но осуждаю..." Понятно, что дело это индивидуальное и завистит от многих обстоятельств,... но в своем ближайшем окружении я не знаю никого, кто в проектах на ПЛИС применял бы современные методики, всё как-то по-старинке работают. Вот я и хочу понять, это просто лень и махровый ретроград внутри каждого мешают или же CI/CD - это удел web-проектов, а в нашем цеху неприменимо?

Если пользуетесь, поделитесь:

- какие средства для непрерывной интеграции под проекты на ПЛИС лучше подходят? (GitLab CI/CD, Jenkins и т.д)

- как выглядит маршрут CI?

- какой схемы ветвления git придерживаетесь? (наверно сюда до полноты картины уместно будет)

- и, наконец, возможно ли работать разным разработчикам над одним куском кода?

[warrior-2001 0]

Несколько тем по этому вопросы было недавно на форуме. Даже опрос был. Поиском по ключевым словам найдёте без труда (GitLab, Jenkins ...)

Ключевой для меня вопрос в вашем тексте - что значит

8 минут назад, OparinVD сказал:

разным разработчикам над одним куском кода

?

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

Но если уж так случилось, и коллега в отпуске, а мне нужно править его код - то я делаю ветку. И потом коллега либо соглашается с моим решением, либо исправляет сам и ветку убивает.

Как-то так.

[one_eight_seven 3]

Маршрут ci напрямую зависит от инструментов. Я использую Jenkins.

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

Схема ветвления - все пушат в мастер. Локально можно хоть сотней веток обмазатьмя, но я за это бью по рукам, потому что, если это приводит к "окукливанию" инженера в своей ветке, то это приводит к проблемам интеграции этой ветки в общий маршрут, особенно на ранних стадиях, когда многое меняется.

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

[OparinVD 0]

Нас сейчас всего двое разработчиков в проекте. Делаем настолько разные куски, что объединяемся только при линковке Витисом наших кернелов. Вполне допускаю, что когда-то нацилимся на более близкие друг к другу задачи, возможно, нас даже станет больше... Но если работать разным людям над одним куском кода - нежелательно, откуда тогда вообще появляются merge конфликты? Есть еще источники появления проблемы?

[one_eight_seven 3]

Так оттуда и берутся. Иногда поблема разделения труда - не решена. Например, оба добавили свои блоки в общий файл сборки, например, в Makefile.

Ну, ещё бывают уникальные снежинки, которые узнали о командах, git: rebase, vommit --amend, push --force, но как работает git, и что делают эти команды - не знают, но имеют жгучую потребность ими пользоваться

[Nick_K 0]

Из всех известных мне компаний, только одна-единственная подняла CI/CD для своих проектов. И то только лишь для того, чтобы при любых изменениях-нововведениях быть уверенными, что старые проекты не сваляться. При этом сам производитель занимаеться обновлением прошивок на поставляемых устройствах, а конечные продукты настолько плотно обмазаны тестбенчами, что даже страшно.

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

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

И в заключение ИМХО эффективный менеджмент лучше применять на программистиках. Разработка схем такого не любит, хотя издалека кажется, что занимаются одним и тем же: но это только кажется. Поинтересуйтесь как справляются с такими задачами разработчики PCB, там дляже Гит неприменим по понятным причинам.

P.S. Делаем изменения в глобальных ветках (типа backend, dev и т.д.), на определённых этапах мерджим в кучу и пушим в мастер - так получаем ревизию и фриз. Фичи, проверки и т.п. каждый может гадить в своей ветке и оставить только нужное для мерджа в глобальную ветку.

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

[count_enable 0]

Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком.

• Упрощает ведение документации и отслеживание изменений в проекте.
• Меньше багов т.к. невозможно забыть прогнать тесты.
• Проверка на различных железных платформах.
• Старый код регулярно проверяется и поддерживается в рабочем состоянии.
• Дисциплинирует, не даёт делать сотни веток "а попробую я это", "это не работает с квестой, временный костыль" и т.д.
• Можно прогонять большие наборы тестов автоматически ночью, а с утра разбирать логи.
• Система масштабируется как по размеру команды, так и по сложности кода. Все разрабы довольны.

Наш случай это когда разрабатывается RTL, софт для встроенного проца + математика. Три независимые команды. RTL делает несколько людей. Совместная разработка не на уровне счётчиков и автоматов (хотя и делаем совместные code review), а на уровне интерфейсов между блоками. Кто-то делает блок памяти, кто-то математический блок, кто-то интегрирует внешнюю память и CI/CD гарантирует что у нас получится один проект с новейшей кодовой базой, а не три несовместимых.

Так что очень рекомендую.

 

[OparinVD 0]

Для pcb-шников встречал такую штуку: https://m.habr.com/ru/company/flipperdevices/blog/554548/ но сам не пробовал, т.к. далек от этого

8 minutes ago, Nick_K said:

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

В том то и дело, что у меня это в голове не укладывается. Я так и сам никогда не работал и даже у других не видел... Вот и пытаюсь понять, это я отстал от времени или действительно есть принципиальные отличия между sw и hw разработчиками. Положа руку на сердце, я не смог для себя их найти... там и там текстовые исходники, из них собирается конечный продукт...

[Nick_K 0]

1 minute ago, OparinVD said:

есть принципиальные отличия между sw и hw разработчиками

Я скажу больше - есть огромное отличие от SW и HW. При некоторой сноровке, HW может спалить продукт или превратить в кусок пластика, чего в SW не получится при любом усердии. Принципы мышления абсолютно разные, оперируемые понятыя - абсолютно разные, тип разработки тоже разный (по сути это о Вашем вопросе).

Да для разработки используются одинаковые инструменты, но на этом сходство и заканчивается. SW не будет писать тестбенч для обычного счётчика, а здесь это ровная тема (особенно если нужен счётчик с пресетом и счётом на -1 значение и т.д.). Это я условно.

[OparinVD 0]

Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)

[Nick_K 0]

2 minutes ago, OparinVD said:

Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)

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

Но при некоторой сноровке... 

[OparinVD 0]

1 hour ago, one_eight_seven said:

Например, оба добавили свои блоки в общий файл сборки, например, в Makefile.

Во! Про файлы сборки-то я и забыл, на них мы вполне пересекаемся... сюда же наверно и какие-то rtl-топлевелы могут добавиться. В общем и целом тогда понятно, спасибо.

 

40 minutes ago, count_enable said:

Мы построили CI/CD систему с тестированием коммитов на железе

а тест-бенчи для rtl у Вы на CI-сервере запускаете или локально? или наверно тут есть смысл делить модульные тесты и некий общий функциональный тест-бенч 

[yes 5]

1 hour ago, Nick_K said:

Я скажу больше - есть огромное отличие от SW и HW.

SW гораздо опаснее, так как оно гораздо больше (тупо по количеству строк кода)

из мировой практики - вспомнилось как израильтяне поломали иранские центрифуги софтом.

из личного опыта - несколько раз было, что обкирпичивались пользовательские устройства от неправильного софта, а от прошивки ПЛИС такого ни разу не было

-----------------

по теме - мы мёржим RTL с разных веток - мое мнение - важно правильное тестирование (с хорошим покрытием), а не всякие сложные правила писания кода  

[Flood 12]

3 часа назад, count_enable сказал:

Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком.

Очень интересно! Сразу куча вопросов:

1. До какого уровня CI дотягивает проект? Всякий раз - до железа, или до симулятора?
2. Если до железа, как часто происходит CI? Если это ночные билды, то хватает ли времени на полный имплемент с таймингами?
3. А если тайминг в билде до железа за отведенное время не вытягивается, это фейл?
4. Тестирование коммитов на железе - значит, в системе имеется автомат тестирования железа, который в том числе управляет питанием аппаратуры, прошивкой, автозапуском тестов?
5. Опять-таки, тестирование на железе предполагает наличие автоматических тестовых стендов для всего создаваемого под CI/CD оборудования? Это в софте не страшно - если прилетает коммит в проект, который обновляли три года назад, CI его исправно отработает. А в железе это значит годы держать подключенный стенд в рабочем состоянии.
6. До какой точки доходит CD (и как часто это происходит)? Полный релизный набор выходных файлов и документов после каждого коммита?

[one_eight_seven 3]

10 hours ago, Nick_K said:

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

На самом деле странный вопрос. А как вы себе представляете раздельную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

На находите, что смысл никак не меняется?