OparinVD 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Всем доброго дня! Начну издалека. У нас в команде появился менеджер проектов, и недавно с ним состоялась беседа, типа: - А как вы решаете merge конфликты? - А у нас нет merge конфликтов , у нас каждый делает свой ipcore, и не бывает так, что несколько разработчиков коммитят изменения в один и тот же исходник... Потом еще долго говорили о том, что каждый должен разбираться во всём проекте, а еще нужна непрерывная интеграция и т.д. Сходу я не нашел объективных аргументов "против" кроме как "я не пробовал, но осуждаю..." Понятно, что дело это индивидуальное и завистит от многих обстоятельств,... но в своем ближайшем окружении я не знаю никого, кто в проектах на ПЛИС применял бы современные методики, всё как-то по-старинке работают. Вот я и хочу понять, это просто лень и махровый ретроград внутри каждого мешают или же CI/CD - это удел web-проектов, а в нашем цеху неприменимо? Если пользуетесь, поделитесь: - какие средства для непрерывной интеграции под проекты на ПЛИС лучше подходят? (GitLab CI/CD, Jenkins и т.д) - как выглядит маршрут CI? - какой схемы ветвления git придерживаетесь? (наверно сюда до полноты картины уместно будет) - и, наконец, возможно ли работать разным разработчикам над одним куском кода? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
warrior-2001 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Несколько тем по этому вопросы было недавно на форуме. Даже опрос был. Поиском по ключевым словам найдёте без труда (GitLab, Jenkins ...) Ключевой для меня вопрос в вашем тексте - что значит 8 минут назад, OparinVD сказал: разным разработчикам над одним куском кода ? Вот я разрабатываю проект верхнего уровня, и использую кучу сторонних сложно-функциональных сблоков. В них я не лезу, однако если найдена ошибка в блоке, который уже находится в релизных проектах - делается либо версия отдельная СФ блока, либо выполняется пересборка и перепроверка всех завершённых ранее проектов (а это подчас недопустимо!). Но если уж так случилось, и коллега в отпуске, а мне нужно править его код - то я делаю ветку. И потом коллега либо соглашается с моим решением, либо исправляет сам и ветку убивает. Как-то так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 6 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Маршрут ci напрямую зависит от инструментов. Я использую Jenkins. От классического ci отличие в том, что коонвейер сборки может ломаться, и будет ломаться, особенно на ранних стадиях проекта. Схема ветвления - все пушат в мастер. Локально можно хоть сотней веток обмазатьмя, но я за это бью по рукам, потому что, если это приводит к "окукливанию" инженера в своей ветке, то это приводит к проблемам интеграции этой ветки в общий маршрут, особенно на ранних стадиях, когда многое меняется. Работать разным людям над одним куском кода - нежелательно, если только это не парное программирование (но оно и не приводит к конфликтам), но иногда это необходимо, хоть я всегда воспринимаю это как сигнал о том, что нужно большее дробление. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OparinVD 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Нас сейчас всего двое разработчиков в проекте. Делаем настолько разные куски, что объединяемся только при линковке Витисом наших кернелов. Вполне допускаю, что когда-то нацилимся на более близкие друг к другу задачи, возможно, нас даже станет больше... Но если работать разным людям над одним куском кода - нежелательно, откуда тогда вообще появляются merge конфликты? Есть еще источники появления проблемы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 6 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Так оттуда и берутся. Иногда поблема разделения труда - не решена. Например, оба добавили свои блоки в общий файл сборки, например, в Makefile. Ну, ещё бывают уникальные снежинки, которые узнали о командах, git: rebase, vommit --amend, push --force, но как работает git, и что делают эти команды - не знают, но имеют жгучую потребность ими пользоваться Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Из всех известных мне компаний, только одна-единственная подняла CI/CD для своих проектов. И то только лишь для того, чтобы при любых изменениях-нововведениях быть уверенными, что старые проекты не сваляться. При этом сам производитель занимаеться обновлением прошивок на поставляемых устройствах, а конечные продукты настолько плотно обмазаны тестбенчами, что даже страшно. С другой стороны оно и понятно, ребята делают медицинское оборудование. Там цена ошибки - человеческие жизни. Глобольно же на всех остальных конторах, разработка идёт по принципу "один модуль-один разработчик". Наверху всё может интегрировать системный инженер, отвечающий за проект или тестировщики. Merge-конфликты решает последний комитящий или по принципу поправить минорные нюансы, либо подходит к автору второго конфликта и решают вместе, кто правее. И в заключение ИМХО эффективный менеджмент лучше применять на программистиках. Разработка схем такого не любит, хотя издалека кажется, что занимаются одним и тем же: но это только кажется. Поинтересуйтесь как справляются с такими задачами разработчики PCB, там дляже Гит неприменим по понятным причинам. P.S. Делаем изменения в глобальных ветках (типа backend, dev и т.д.), на определённых этапах мерджим в кучу и пушим в мастер - так получаем ревизию и фриз. Фичи, проверки и т.п. каждый может гадить в своей ветке и оставить только нужное для мерджа в глобальную ветку. P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
count_enable 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком. Упрощает ведение документации и отслеживание изменений в проекте. Меньше багов т.к. невозможно забыть прогнать тесты. Проверка на различных железных платформах. Старый код регулярно проверяется и поддерживается в рабочем состоянии. Дисциплинирует, не даёт делать сотни веток "а попробую я это", "это не работает с квестой, временный костыль" и т.д. Можно прогонять большие наборы тестов автоматически ночью, а с утра разбирать логи. Система масштабируется как по размеру команды, так и по сложности кода. Все разрабы довольны. Наш случай это когда разрабатывается RTL, софт для встроенного проца + математика. Три независимые команды. RTL делает несколько людей. Совместная разработка не на уровне счётчиков и автоматов (хотя и делаем совместные code review), а на уровне интерфейсов между блоками. Кто-то делает блок памяти, кто-то математический блок, кто-то интегрирует внешнюю память и CI/CD гарантирует что у нас получится один проект с новейшей кодовой базой, а не три несовместимых. Так что очень рекомендую. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OparinVD 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Для pcb-шников встречал такую штуку: https://m.habr.com/ru/company/flipperdevices/blog/554548/ но сам не пробовал, т.к. далек от этого 8 minutes ago, Nick_K said: P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. В том то и дело, что у меня это в голове не укладывается. Я так и сам никогда не работал и даже у других не видел... Вот и пытаюсь понять, это я отстал от времени или действительно есть принципиальные отличия между sw и hw разработчиками. Положа руку на сердце, я не смог для себя их найти... там и там текстовые исходники, из них собирается конечный продукт... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 1 minute ago, OparinVD said: есть принципиальные отличия между sw и hw разработчиками Я скажу больше - есть огромное отличие от SW и HW. При некоторой сноровке, HW может спалить продукт или превратить в кусок пластика, чего в SW не получится при любом усердии. Принципы мышления абсолютно разные, оперируемые понятыя - абсолютно разные, тип разработки тоже разный (по сути это о Вашем вопросе). Да для разработки используются одинаковые инструменты, но на этом сходство и заканчивается. SW не будет писать тестбенч для обычного счётчика, а здесь это ровная тема (особенно если нужен счётчик с пресетом и счётом на -1 значение и т.д.). Это я условно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OparinVD 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 2 minutes ago, OparinVD said: Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон) Я не конкретно к Вашему примеру. Скорее что лет 5 так можно было легко сделать, превратить 10К$ в металлолом. Сейчас конечно и защиты побольше и синтез-имплементация поумнее с проверками разными. Но при некоторой сноровке... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OparinVD 0 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 1 hour ago, one_eight_seven said: Например, оба добавили свои блоки в общий файл сборки, например, в Makefile. Во! Про файлы сборки-то я и забыл, на них мы вполне пересекаемся... сюда же наверно и какие-то rtl-топлевелы могут добавиться. В общем и целом тогда понятно, спасибо. 40 minutes ago, count_enable said: Мы построили CI/CD систему с тестированием коммитов на железе а тест-бенчи для rtl у Вы на CI-сервере запускаете или локально? или наверно тут есть смысл делить модульные тесты и некий общий функциональный тест-бенч Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 1 hour ago, Nick_K said: Я скажу больше - есть огромное отличие от SW и HW. SW гораздо опаснее, так как оно гораздо больше (тупо по количеству строк кода) из мировой практики - вспомнилось как израильтяне поломали иранские центрифуги софтом. из личного опыта - несколько раз было, что обкирпичивались пользовательские устройства от неправильного софта, а от прошивки ПЛИС такого ни разу не было ----------------- по теме - мы мёржим RTL с разных веток - мое мнение - важно правильное тестирование (с хорошим покрытием), а не всякие сложные правила писания кода Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 13 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 3 часа назад, count_enable сказал: Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком. Очень интересно! Сразу куча вопросов: До какого уровня CI дотягивает проект? Всякий раз - до железа, или до симулятора? Если до железа, как часто происходит CI? Если это ночные билды, то хватает ли времени на полный имплемент с таймингами? А если тайминг в билде до железа за отведенное время не вытягивается, это фейл? Тестирование коммитов на железе - значит, в системе имеется автомат тестирования железа, который в том числе управляет питанием аппаратуры, прошивкой, автозапуском тестов? Опять-таки, тестирование на железе предполагает наличие автоматических тестовых стендов для всего создаваемого под CI/CD оборудования? Это в софте не страшно - если прилетает коммит в проект, который обновляли три года назад, CI его исправно отработает. А в железе это значит годы держать подключенный стенд в рабочем состоянии. До какой точки доходит CD (и как часто это происходит)? Полный релизный набор выходных файлов и документов после каждого коммита? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 6 14 сентября, 2021 Опубликовано 14 сентября, 2021 · Жалоба 10 hours ago, Nick_K said: P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. На самом деле странный вопрос. А как вы себе представляете раздельную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. На находите, что смысл никак не меняется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться