Организация взаимодействия в любой ECAD-системе может быть сложной задачей. Многие придерживаются старой методики:
Такой метод не только засоряет ваш почтовый ящик, но и заставляет работать в последовательном режиме. Решением здесь является управление версиями. Когда управление версиями пришло в область ECAD, работа значительно улучшилась, хотя и несколько более сложной.
Системы управления версиями существуют уже достаточно давно, и они популярны среди разработчиков программного обеспечения. Эти системы позволяют пользователям фиксировать свои разработки в репозиториях и совместно работать с другими разработками, не перезаписывая файлы друг друга (что обычно происходит при работе с общей сетевой папкой). Altium Designer® поддерживает системы управления версиями, такие как SVN, для нескольких версий. Инструменты в Altium Designer, такие как Storage Manager, предоставили пользователям больше возможностей для совместной работы. Начиная с версии 18, Altium интегрировал Git в Altium Designer. Это был огромный шаг вперед для пользователей ECAD.
Чем же так полезен Git в ECAD-системе? Git стал популярной системой VCS, которая прекрасно интегрируется с системами управления бизнес-процессами, и мы хотим получить максимальную выгоду от этого во всех наших инструментах проектирования. Благодаря поддержке Git мы теперь можем интегрировать наши инструменты ECAD в современные системы управления бизнес-процессами, широко используемые сообществом разработчиков программного обеспечения.
Решать конфликты всегда не просто. К счастью, в Altium Designer для этого есть встроенные инструменты. Возможности Storage Manager позволяют сравнивать коммиты между собой и решать возможные конфликты. К сожалению, Storage Manager не решит все конфликты, и поэтому приходится вмешиваться самостоятельно, но по крайней мере, начало уже положено!
Рассмотрим пример, когда два человека работают над одним документом схемы. Сотрудник А фиксирует свои изменения на сервере. Сотрудник Б делает локальные изменения и затем пытается получить изменения сотрудника А. Это приведет к конфликту, поскольку оба сотрудника изменили один файл. Сотрудник Б может объединить свои коммиты с коммитами сотрудника А с помощью средств Storage Manager. Обратите внимание, что любые изменения документов схем или других файлов Altium Designer приведут к конфликту, поскольку они являются бинарными файлами, и Git не знает, как следует объединять файлы, отличные от текстовых.
Другим полезным инструментом взаимодействия является Collaborate, Compare and Merge. Он может быть крайне полезен, когда множество людей трассируют одну плату.
Представим сценарий, когда инженер завершил схему, разместил на плате компоненты и развел некоторые цепи. Теперь инженер хочет создать несколько дополнительных пробных трасс, чтобы определить оптимальную структуру слоев. Когда инженер создает и схему, и плату, этот процесс достаточно тривиален: инженер сохранит локальную копию платы и переименует ее во что-нибудь вроде “Тестовая”. Что произойдет, если в дело вступит конструктор? Что если и инженер, и конструктор хотят сделать пробную трассировку, но сохранить “согласованные” трассы? Рассмотрим два сценария.
Сценарий 1. Инженер и конструктор согласились оставить в VCS первоначальную трассировку как самую новую и лучшую. Инженер начинает экспериментировать с трассировкой в копии проекта (переименованного), и то же самое делает конструктор. Участники процесса начинают обмениваться между собой электронными письмами, и, предположим, к самой новой версии добавлено “_v92e”. Это очень неудачная буквенно-цифровая схема именования файлов, которая может запутать двух или даже больше участников, когда они начнут получать сотни писем с подобными вложениями.
Сценарий 2. Те же самые инженер и конструктор решили сделать по-другому, и теперь они фиксируют в репозиторий свою тестовую трассировку по очереди и вместе проводят проверку. Теперь это командная работа! Что ж, не совсем. Рано или поздно начнут возникать конфликты, и мы будет тратить множество часов на решение того, что изначально задумывалось как эксперимент.
Идеальный сценарий. Представьте мир, в котором все три проекта могут существовать в рамках одного репозитория, и переключение между ними доступно по нажатию одной кнопки. Нет, это не какая-то потенциально возможная система – такие системы уже существуют. Эта концепция называется Создание ветвей, и она используется в Git. Каждый пользователь может экспериментировать в собственной “песочнице” (или ветке), не влияя на главный, согласованный проект. В этом примере мы показываем, как инженер и конструктор создают ветки для собственных экспериментов и затем принимают новое направление.
Рис. 1. Экспериментирование и принятие нового направления
В другом примере, инженер и конструктор экспериментируют с трассировкой, но они решают, что следует продолжить работу с вариантом конструктора. Эта ветка (ветка Б) объединяется с главной веткой, и после этого с ней проводят финальную доработку.
Рис. 2. Экспериментирование и продолжение работы с веткой Б
К сожалению, метод “ветвления” не поддерживается непосредственно в Altium Designer (пока что?). Для этого необходимо использовать внешние клиенты Git, такие как Git BASH, TortoiseGit или Sourcetree.
Системы управления версиями стали популярными не только в среде разработки программного обеспечения, но и во всех инженерных дисциплинах. Такие системы, как Git, позволили пользователям работать вместе над одними и теми же проектами. Благодаря интеграции Git и Altium Designer, совместная работа в системе ECAD стала простой как никогда раньше. Надеемся, что эта статья прояснила важность таких инструментов, как Git, и то, как вы можете начать с ними работать. Поговорите с экспертом Altium, чтобы узнать больше.