[Stanislav_S 0]

Такой вопрос - коллеги как вы организовываете типовой проект РЭА? Какими методиками для ведения пользуетесь?

Приведу свой пример - типовой проект - железо + софт + документация. Проект для железа ведется отдельно в отдельной папке, проект для софта отдельно, документация обычно с железом. Потом все вручную собирается в архив и идет в бэкап/релиз. Есть соглашения о названиях проектов для софта и железа и для версий. В общем конечно, можно сказать, что "каменный век", никакой автоматизации - все держится на моей памяти, что чему и где соответствует. Естественно память лучше не становится - если о проекта двух трехлетней давности, и есть воспоминания. то дальше уже нет. Приходится тратить много времени на "вспоминание" где и что я делал и как и зачем. Вообщем хочется изменить эту систему, поскольку так уже не получается. да и 21 век на дворе. Собственно и интересует какие есть методики и "экосистемы" для ведения и работы с проектами. Конечно для софтовой части немного проще, в конце концов есть git и прочие инструменты, но вот интересует более комплексный подход. 

[ViKo 1]

Я тоже создаю папку для проекта, и в ней отдельные папки для схем и плат, программы, документации. И веду отдельный документ-файл info, в котором описываю всё, параметры ТЗ, комплектацию, вопросы по схемам, платам, программам, журнал работы. 

[Corvus 1]

Отдельные папки для железа, софта и документов. Схемы и код в репозитории.

Задачи в jira, документация в confluence.

Недавно подсел на notion для сбора всякой всячины, которая может быть полезна для проекта, списков to-do и прочих напоминалок.

[AlexandrY 3]

51 minutes ago, ViKo said:

Я тоже создаю папку для проекта, и в ней отдельные папки для схем и плат, программы, документации. И веду отдельный документ-файл info, в котором описываю всё, параметры ТЗ, комплектацию, вопросы по схемам, платам, программам, журнал работы. 

Вопрос только в том как хранить версии такого проекта.
Средненький проект платы универсального контроллера со всеми сорсами и документами занимаети пару Гиг. 
Каждый день фиксировать такое в системе контроля версий занимает слишком много времени и аннотаци превращаются в бессвязную кашу.
Приходится разбивать проект на независимые подпроекты. Особенно весело когда проекты используют общую кодовую базу стороннего проекта. 
И тогда встает вопрос как организовывать дерево проектов не на диске, а в системе контроля версий.
И че делать когда меняется структура директорий. Как избежать потери истории файлов.
Как вообще рефакторить проекты без потери истории. 
   

2 minutes ago, Corvus said:

Задачи в jira, документация в confluence.

Недавно подсел на notion для сбора всякой всячины, которая может быть полезна для проекта, списков to-do и прочих напоминалок.

jira и confluence - этож инструменты командной работы.
Зачем они нужны самостоятельному разработчику в здравом уме?  

notion  - бледное подобие OneNote

[Corvus 1]

14 minutes ago, AlexandrY said:

jira и confluence - этож инструменты командной работы.

Совершенно верно. Вопрос был "как вы организовываете типовой проект РЭА". В моих проектах участвуют несколько человек. В минимальном случае: я и заказчик. 

14 minutes ago, AlexandrY said:

notion  - бледное подобие OneNote

Ну вкус и цвет, как известно. OneNote совершенно не зашёл, сколько ни пробовал. 

[ViKo 1]

Версии встроенного ПО контролирую в TortoiseHg. Могу и отдельную папку создать для новой версии, если много отличий от старой. Добавляю к имени папки _vX, где X - мажорный номер версии. Для схем добавляю к названию _vX, для плат добавляю к имени _vXY, где X - версия схемы, Y - ревизия платы. Пока план проектов такой. Ни схемы, ни платы в контроль версий не включаю. Они редко меняются, зачем заниматься пустой работой?  

[AlexandrY 3]

У меня не так.
Версии нужны только для подрядчиков, чтоб они не путали входную документацию. 
Для собственных нужд никаких номеров версий. Есть только номера поколений разработок. 
Ставить вручную намера версиям - пустая работа. Уже через пару дней эти номера ни о чем не скажут. 
Важнее аннотации в системе управления версиями. Только ради аннотаций стоит делать версии. 
Но веток версий у меня принципиально нет. Ветки рассеивают внимание и усложняют поиск в истории и ее ретроспективу.   

[ViKo 1]

В TortoiseHg (как и в других Тортилах) при фиксации пишутся комментарии. По ним всё видно, если не поленился нужное написать.

Я ветки делаю редко. Обычно, для экспериментов.

[kolobok0 0]

18 hours ago, Stanislav_S said:

Такой вопрос - ...

как тут уже прозвучало выше = gitlab, jira, confluence, CI, nexus, docker/containers (в них разный зоопарк, сами они так-же отдельные проекты).

версия на автомате, опираясь на тэги (которые можно переустановить)

 

как то так

(круглый)

[Stanislav_S 0]

11 часов назад, ViKo сказал:

Я тоже создаю папку для проекта, и в ней отдельные папки для схем и плат, программы, документации. И веду отдельный документ-файл info, в котором описываю всё, параметры ТЗ, комплектацию, вопросы по схемам, платам, программам, журнал работы. 

А как внутри организуются версии? Например - есть версия платы XX.YY - какой версии софта она соответствует? Программа разбита по версиям. или все в одном, а для фиксации  используется система контроля? Как релиз собирается? Это отдельная папка или просто описание в неком документе?

10 часов назад, Corvus сказал:

Отдельные папки для железа, софта и документов. Схемы и код в репозитории.

Задачи в jira, документация в confluence.

Недавно подсел на notion для сбора всякой всячины, которая может быть полезна для проекта, списков to-do и прочих напоминалок.

Аналогичный вопрос.

8 часов назад, AlexandrY сказал:

У меня не так.
Версии нужны только для подрядчиков, чтоб они не путали входную документацию. 
Для собственных нужд никаких номеров версий. Есть только номера поколений разработок. 
Ставить вручную намера версиям - пустая работа. Уже через пару дней эти номера ни о чем не скажут. 
Важнее аннотации в системе управления версиями. Только ради аннотаций стоит делать версии. 
Но веток версий у меня принципиально нет. Ветки рассеивают внимание и усложняют поиск в истории и ее ретроспективу.   

Я так понимаю все ведется в системе контроля версий? Как тогда стыкуется железо + документация + софт на этапе релиза некого изделия?

11 минут назад, kolobok0 сказал:

как тут уже прозвучало выше = gitlab, jira, confluence, CI, nexus, docker/containers (в них разный зоопарк, сами они так-же отдельные проекты).

версия на автомате, опираясь на тэги (которые можно переустановить)

 

как то так

(круглый)

Все это хорошо, но ИМХО это софта касается, меня интересует более комплексный вопрос - вот например, мой типовой проект - создание железа + софта + документации + механика, вопрос как этим всем управлять в рамках одной сущности или скажем так пространства, как соединять эти разнородные сущности.

[amaora 20]

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

Документация живёт вместе с софтом но пока у меня все плохо с ней.

[AlexandrY 3]

1 hour ago, Stanislav_S said:

Я так понимаю все ведется в системе контроля версий? Как тогда стыкуется железо + документация + софт на этапе релиза некого изделия?

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



 

[Stanislav_S 0]

19 минут назад, AlexandrY сказал:

Система управления версиями используется у меня исключительно только как движок архивирования и журнала работ.
По этому журналу собственно и восстанавливаю контекст прошлых версий. 

А как примерно выглядит такой журнал работ?

И вот еще общий вопрос, для железа использую Altium, но думаю это не важно, например есть у меня железный проект, пусть будет XXX - 1.0 - MB, ему соответствует  некая схема и плата с индексом 1.0 - МВ, теперь, например надо подкорректировать плату, скажем часть трассировки изменить, но схема не изменяется. В моей текущей системы - делаю новый проект в новой папке, только проект теперь будет XXX-1.1-MB, соответственно и все остальные документы имеют индекс версии 1.1. Неудобно, что приходится руками перетаскивать файлы и переименовывать, ну и плюс место на диске, хотя в наши времена, это наверно не актуально. Может есть другие подходы?

[AlexandrY 3]

19 minutes ago, Stanislav_S said:

А как примерно выглядит такой журнал работ?

Неудобно, что приходится руками перетаскивать файлы и переименовывать,

Ничего особенного нет в тех записях. Просто короткие комментарии к выполненным модификациям в одну строку. 
Но часто, по нескольку раз в день. Тогда и набегает целостная история вводящая в контекст. 

А групповое переименование есть в Total Commander. Оч удобно. 
Хотя для Altium я переименовываю только два файла  *.PcbDoc и *.PrjPCB. 

[ViKo 1]

13 часов назад, Stanislav_S сказал:

А как внутри организуются версии? Например - есть версия платы XX.YY - какой версии софта она соответствует?

Увы, никак. В комментариях к ветке пишу, для какого железа предназначена данная версия.
Если схема и плата изменились, то мне проще создать новый проект.