Системы контроля версий — один из основных инструментов разработчика. Мы можем вернуться к предыдущей версии, можем сделать свое ответвление, чтобы написать новую функцию и т. д.

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

Но любое аппаратное решение всегда имеет схему, на которой указываются детали и их соединения (принципиальная, монтажная схема). Также бывают схемы расположений, подключений и т. д. Эти схемы также неплохо было бы хранить в системе контроля версий.

В этой статье мы поговорим о том, как решения по контроля версий могут использовать разработчики аппаратных решений.

Git, просто Git

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

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

И здесь у программистов, пишущих прошивки к устройствам больших проблем возникнуть не должно. Даже если ваша прошивка написана на ассемблере какого‑нибудь не слишком распространенного процессора, все равно исходник будет представлять собой текстовый файл с кодом.

С помощью команды

git diff <commit‑id-1> <commit‑id-2>

мы можем сравнить два коммита и увидеть все различия в файлах.

Но если наши коммиты являются двоичными файлами, то что‑то реально полезное мы вряд ли увидим. Аналогичная история и со слияниями, так как объединение двух двоичных файлов гарантированно приведет к неработоспособному результату.

Изменения будут показаны в виде отдельных байтов, что не слишком информативно. Так что, Git нам не слишком подойдет для работы с двоичными файлами.

Давайте посмотрим, какие еще решения предлагаются на рынке.

GitHub

GitHub является облачным сервисом для работы с исходным кодом. Любой, кто знаком с Git, знает о GitHub. 84% компаний из списка Fortune 100 используют GitHub Enterprise, и у него более 73 миллионов пользователей. Даже покупка этого сервиса Microsoft не сделала его сильно хуже.

Итак, GitHub предлагает множество инструментов для вашего репозитория и многие организации используют сторонние интеграции для (CI/CD) и других важных процессов DevOps.

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

GitLab

Хотя его часто путают с GitHub, GitLab использует другой подход. GitLab имеет как бесплатную версию с открытым исходным кодом, которая позволяет вам размещать и изменять свой сервер по своему усмотрению, так и коммерческую версию Enterprise Edition.

Специализация GitLab — CI/CD, и у него есть множество встроенных и готовых сервисов для тестирования, упаковки и выпуска ваших файлов. Поскольку они встроены, они не зависят от внешних сервисов, которые вам нужно обновлять и поддерживать. Поскольку они нативные, вам не нужно собирать собственные интеграции с нуля.

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

Однако GitLab страдает от той же проблемы, что и все другие платформы, ориентированные на ПО. Вы не можете увидеть изменения в файлах схем и макетов, используя только этот инструмент.

Bitbucket

Bitbucket — это решение Atlassian, а поскольку данная компания также производит Jira, оно обеспечивает тесную интеграцию отслеживания проблем и управления продуктами в свой инструмент Git. Большинство остальных перечисленных здесь решений имеют стороннюю интеграцию для создания инструментов отслеживания и могут использовать Jira. Инструмент также предлагает конвейер Bitbucket для автоматизации сборки, тестирования и развертывания.

Поскольку Bitbucket ориентирован на программное обеспечение, он как и все предыдущие системы не может сравнивать двоичные файлы.

Gitea

Gitea — это бесплатная платформа хостинга Git с открытым исходным кодом, которая имеет многие из тех же функций, что и GitHub Enterprise Edition. Ее главная цель — быть вашим «безболезненным сервисом Git, размещенным самостоятельно». Gitea легко установить, но есть много хостинговых сервисов, которые имеют предварительно настроенные серверы под ключ, которые могут запустить вашу собственную платформу Git.

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

AllSpice

AllSpice — единственный инструмент в этом списке, который специально ориентирован на Git для разработки аппаратного обеспечения. Да, он не так известен, как предыдущие. Но он основан на форке Gitea, поэтому вы получаете всю мощь и функциональность Gitea, но с дополнительными возможностями, которые позволяют вам видеть изменения схем вместо двоичных BLOB‑объектов.

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

Когда вы отправляете свои изменения на сервер, hub преобразует двоичные файлы в промежуточный файл json, к которому любой пользователь может получить доступ и написать сценарий. Затем файл json преобразуется в визуальные файлы SVG, которые каждый может прочитать. SVG‑файлы схем и макетов печатных плат создаются с изменениями в цветовой кодировке. Визуальное различие легко читается специалистами любого уровня квалификации: красным цветом обозначены удаленные элементы, зеленым — новые, а желтым — измененные детали.

Например, на рисунке ниже мы можем легко определить, какой конденсатор был удален, а какой заменен. Вы также можете видеть, что вывод 27 U115 был перенесен на другую сторону резистора, R108.

Вы даже можете щелкнуть по компонентам и их соединениям для чтобы просмотреть доступные метаданные. Здесь вы можете видеть, что значение было изменено с конденсатора емкостью 220 мкФ на колпачок емкостью 470 мкФ и что был введен номер детали.

В дополнение к визуальному разнообразию, AllSpice также предлагает инструменты создания фрагментов, который позволяет вам выделять отдельные разделы дизайна и публиковать их в комментариях или обзорах без необходимости использования внешнего инструмента редактирования изображений. Прошли те времена, когда PDF‑файлы были заполнены скриншотами.

Заключение

Хотя за предыдущие 20 лет мы получили множество отличных платформ для контроля версий, большинство из них ориентированы исключительно на программные проекты. Однако, когда речь заходит о проектировании аппаратных решений, то здесь все становится значительно хуже.

В этой статье мы рассмотрели проектов для контроля версий и из них только AllSpice позволяет работать со схемами печатных плат и выявлять те изменения, которые были выполнены. Эта возможность позволяет проектировщикам эффективнее работать с различными версиями проектов.

Если вам знакомы проблемы с масштабируемостью, безопасностью и автоматизацией в Docker, Kubernetes или Terraform, то эти вебинары точно для вас. Мы покажем, как работать с данными в контейнерах, настроить деплой в Kubernetes и автоматизировать инфраструктуру с Terraform — с практическими примерами и реальными кейсами.

• 2 июля в 20:00 — «Работа с данными и сетями в Docker»
  о безопасности данных и настройке сетевых решений

• 14 июля в 20:00 — «От кода до Kubernetes за полтора часа»
  деплой ASP.NET-приложений и настройка CI/CD

• 22 июля в 20:00 — «Инфраструктура как код на примере Terraform»
  про автоматизацию и версионирование инфраструктуры