Git tagging i aplikacja Git do opracowywania osprzętu w Altium Designer
Idea wprowadzania poprawek w projektach układów elektronicznych jest dość rozpowszechniona w branży. Poprawiona wersja jest zazwyczaj oznaczona literą, a czasami również numerem. Istnieje wiele schematów oznaczania wersji projektu PCB, z którymi eksperymentowano, jednak według mojego doświadczenia w branży dominuje standardowe oznaczenie literowe. Zawsze zadaję sobie jedno pytanie: Co się stało z tymi wszystkimi wersjami pomiędzy? Rozumiem, że zmiana literowego oznaczenia wersji projektu PCB oznacza publikację, ale co się dzieje ze wszystkimi zmianami pomiędzy tymi wydaniami? Jak się je śledzi?
Z czasem odpowiedź na to pytanie dały systemy kontroli wersji, takie jak CVS, Subversion czy Git. Programiści najprawdopodobniej znają aplikację Git, jednak jej wykorzystanie przy projektowaniu osprzętu to doskonały sposób na śledzenie poprawek, rozgałęzianie projektów PCB oraz publikowanie projektów. Takie systemy kontroli wersji projektów PCB pozwalają nam przeglądać wszystkie wersje pomiędzy wydaniami. W artykule Ciągła integracja i wdrażanie w ECAD omówiliśmy koncepcję publikowania nowych wersji projektu po każdej zmianie. W niniejszym artykule przedstawię prosty, ale skuteczny sposób publikowania wydań poprzez serwer Git przy jednoczesnym zachowaniu związku z literowym oznaczeniem wersji projektu PCB.
Git tagging w projektach PCB
Tagowanie Git to funkcja pozwalająca użytkownikom oznaczać konkretną zmianę dla celów specjalnych. Użytkownicy „tagują” zmianę, aby zasygnalizować jej wprowadzenie. Ktoś może np. otagować trzecią zmianę w repozytorium jako Wersję 1.0.0, podczas gdy dziesięć zmian później ta zmiana może ostatecznie być otagowana jako Wersja 1.1.0. Nie ma dobrych i złych metod tagowania, ale używanie tagowania Git dla publikacji to zazwyczaj główne zastosowanie tej funkcji.
Bez względu na to, czy zarządzamy projektami w programie Altium Concord Pro, GitHub, Bitbucket, Gitlab, czy też na dowolnym innym serwerze Git, wszystkie one pozwalają na tagowanie zmian. Niektóre serwery Git, np. GitHub i Bitbucket, mają własne systemy Git taggingu, które można uruchamiać z ich interfejsów sieciowych. W przypadku innych serwerów Git można korzystać z polecenia „git tag” w wierszu poleceń. Bez względu na wybrany sposób Git taggingu w systemie Git przy projektowaniu osprzętu zespół musi opracować system nazywania wersji projektu PCB, aby każdy rozumiał wzajemne powiązania różnych wersji.
Powiązywanie wydania ze zmianą Git
Ponieważ społeczność ECAD migruje do takich systemów kontroli wersji jak Git, koniecznie trzeba zachować powiązania między systemem Git a procesem, który wszyscy dobrze znają. Wiele osób miało problemy z określeniem najlepszego sposobu zachowywania ich zmian w systemie kontroli wersji projektu PCB przy jednoczesnym zachowaniu swobody w kompletowaniu pakietów, które można wysłać do dostawców (albo do weryfikacji na późniejszym etapie). Można sobie z tym poradzić na wiele sposobów. Proponuję, aby procesu publikowania nie traktować jako uniwersalnego rozwiązania, ale zachęcam do wypróbowania go jako punktu wyjścia i późniejszego dostosowania go do potrzeb grupy.
Największym wyzwaniem jest zrozumienie wszystkich zmian Git, a następnie połączenie tego z wydawanym pakietem. Oto przykład serii zmian Git w GitHub:
_5.png)
Rys. 1. Historia zmian Git w repozytorium GitHub przy wykorzystaniu Git Taggingu
As you can see, there are many commit comments that describe design changes, and other various commits comments that proclaim an “official release.” This is prevalent among many version control system users, and it generally works. I’ve also seen users bundling release packages within the repository as well. While this may not be the cleanest solution (as it pollutes the repository with non-design files), it does seem to get the trick done.
Rather than making your official release known in a commit comment, we can leverage the concept of git tagging (or also known as “Releases” in GitHub). In this example, we have taken those official release commits and made them into releases in GitHub (which also become tags):
.png)
Rys. 2. Wersje projektu PCB. Widok wydań dla repozytorium projektu w GitHub
Jak widać powyżej, wzięliśmy konkretne zmiany i przerobiliśmy je na wydania. Teraz GitHub dołącza tag do każdej zmiany, jak tutaj:
.png)
Na koniec możemy wyszukiwać wydania lub tagi w GitHub:
.png)
Rys. 4. Git tagging- część dalsza. Wyszukiwanie tagów w GitHub
Powiązywanie schematu ze zmianą Git
Innym sposobem na zapewnienie prawidłowego powiązania między projektem PCB a repozytorium Git jest śledzenie haszów Git w samym schemacie. John Watson pokazał mi kiedyś mały trick, gdy jeszcze używaliśmy Subversion. Poprzez wykorzystanie ciągów specjalnych można powiązać schemat (i projekt PCB) bezpośrednio ze zmianą Git przesyłaną do serwera Git. W tym przykładzie umieściliśmy ciąg kontroli wersji na schemacie najwyższego poziomu zaraz przy bloku tytułu:
_3.png)
Rys. 5. Git tagging- zaawansowane zastosowania. Hash Git zastosowany jako ciąg specjalny
Jak widać powyżej, na schemacie znajdują się dwie wersje haszów Git: pierwszy to pełny hasz Git, a drugi to jego skrócona wersja (tak jak występuje w GitHub). Aby zastosować hasz o pełnej długości, wprowadziłem następujący ciąg specjalny:
=VersionControl_ProjFolderRevNumber
Aby dołączyć do tego tytuł z przodu, trzeba dodać, co następuje:
=’Git Hash:’ + VersionControl_ProjFolderRevNumber
W czasie pisania tego artykułu okazało się jednak, że ten ciąg specjalny był zbyt długi, żeby go połączyć. Można temu zaradzić, ustawiając krótszy parametr VersionControl_ProjFolderRevNumber. W tym przypadku parametr został utworzony i ustawiony na wartość VersionControl_ProjFolderRevNumber w panelu Properties (Właściwości) tego konkretnego schematu.
_0.png)
Rys. 1. Historia zmian Git w repozytorium GitHub przy wykorzystaniu Git Taggingu
Po skróceniu parametru możemy manipulować ciągiem. W tym przypadku chcemy mieć tylko 7 pierwszych znaków parametru GitHash, tak jak jest on wyświetlany w GitHub. Wprowadzamy następującą frazę połączonego i zmanipulowanego ciągu specjalnego:
='Git Hash: ' + Copy(GitHash,1,7)
Trzeba pamiętać, że wszelkie zastosowane funkcje manipulowania ciągiem bazują na języku Delphi. Technika podciągu to zwykłe wywołanie funkcji Copy (Kopiuj) z Delphi zagnieżdżone w ciągu tekstowym. Po otwarciu dokumentów projektowych z wydania Git w Altium Designer będzie widać tag zawierający konkretne łącze bezpośrednio do kontrolowanej wersji projektu PCB.
Wdrażanie Git taggingu do opracowywania osprzętu w Altium 365
Ponieważ branża zaczyna wykorzystywać wersje w systemie Git do opracowywania sprzętu, zarówno lokalnie, jak i w chmurze, ważne jest, aby rozumieć połączenie między oficjalnym wydaniem projektu PCB a rzeczywistą rewizją Git (hashem), która istnieje w systemie kontroli wersji. Koncepcja hashów Git oraz ich wykorzystania przy publikowaniu projektu PCB w systemie kontroli wersji projektu PCB pozwala nam zachować to powiązanie i zapewnić zgranie obu procesów (lub systemów).
Zamiast używać systemów kontroli wersji innych producentów, można wykorzystać Git do opracowywania osprzętu w Altium Designer i na platformie Altium 365. Ten system zastępuje rozwiązanie Git do kontroli wersji w chmurze i umożliwia członkom zespołu błyskawiczne importowanie projektów do Altium Designer. Alternatywnie można wdrożyć Altium Concord Pro lokalnie, dając zespołowi kompletny zestaw funkcji kontroli wersji i zarządzania danymi, które są zintegrowane z Altium Designer.
Altium Designer na platformie Altium 365 wnosi do branży elektronicznej bezprecedensowy poziom integracji, która pozostawała domeną świata programowania, dając projektantom możliwość pracowania z domu i osiągnięcia niespotykanych dotąd wyżyn wydajności.
W tym artykule poczuliśmy zaledwie przedsmak możliwości, jakie daje Altium Designer na platformie Altium 365. Aby uzyskać bardziej dogłębny opis funkcji, zajrzyj na stronę produktu lub zapoznaj się z jednym z seminariów internetowych na żądanie.
