CO TO JEST WERSJONOWANIE KODU?
Zagadnienia wersjonowania kodu są integralną częścią świata IT. Coraz częściej jednak sięgają po nie programiści PLC, bo jak się okazuje jest to świetne narzędzie do ułatwienia sobie pracy z kodem zarówno w językach typu SCL jak i LAD i FBD. O co tak naprawdę chodzi?
Przede wszystkim należy wyjaśnić czym jest to “wersjonowanie kodu” i na co to komu potrzebne. Wyobraźmy sobie program, w którym chcemy dokonać takiej zmiany, która może spowodować nieodwracalne skutki. Wprowadzając taką zmianę warto wcześniej zrobić kopię zapasową tego programu. Tworzenie takich właśnie kopii zapasowych w kluczowych momentach można nazwać uproszczonym wersjonowaniem kodu. Wykonywanie takich “kamieni milowych” ułatwia późniejszą pracę z kodem zarówno indywidualnie jak i grupowo, czy też zapewnia możliwość powrotu do określonego miejsca w kodzie. Funkcjonalność ta stała się na tyle popularna, że jest ona znana i wykorzystywana przez prawie każdego programistę w dziedzinie IT, a dodatkowo powstały dedykowane do wersjonowania kodu platformy (najpopularniejszą z nich jest GitHub) i programy (np. Git), które pozwalają na zintegrowanie środowisk programistycznych z systemem kontroli wersji, ich obsługę i możliwość “wypchnięcia” danej wersji kodu do zewnętrznego katalogu (repozytorium), które może być prywatne lub publiczne.
Zacznijmy od tego czym tak naprawdę jest Git. To system kontroli wersji, który ułatwia nam pracę przy pisaniu kodu. Pozwala nam na wprowadzanie zmian w kodzie oraz śledzenie wszystkich zmian (nawet wprowadzanych przez innych użytkowników). Dzięki niemu jesteśmy w stanie również przywrócić dowolną, wcześniejszą wersję kodu. GitHub jest więc hostingiem repozytoriów – publicznych i prywatnych. Możemy na nim tworzyć wirtualne portfolio własnych projektów oraz daje on możliwość do dzielenia się kodem źródłowym z innymi użytkownikami platformy, dzięki czemu można otrzymać feedback o jakości napisanego przez nas kodu. Najważniejsza różnica między Gitem a GitHubem dotyczy sposobu działania – Git działa na danym urządzeniu – lokalnie, a GitHub zapisuje wszystko w chmurze.
ZACZNIJMY PRACĘ Z GITEM I GITHUBEM
Przede wszystkim na głównej stronie GitHuba zakładamy własne konto – pamiętając, że nazwa użytkownika jest publiczna. Instalujemy Gita (pamiętając o zaznaczeniu git bash here w select components – pobierze się konsola, dzięki której można obsługiwać system kontroli wersji). Po zalogowaniu, na stronie można utworzyć swoje pierwsze repozytorium poprzez kliknięcie opcji new repository. To właśnie tutaj określa się czy będzie ono publiczne czy prywatne, co później zmienić można również w ustawieniach danego repozytorium. Mając utworzony katalog na GitHubie można się zabrać za pracę z lokalnym repozytorium.
Do stworzenia lokalnego repozytorium na komputerze potrzebny będzie Git, którego przed chwilą zainstalowaliśmy. W określonym folderze klikamy PPM i wybieramy opcję Git Bash Here, co otworzy dedykowaną konsolę do zarządzania repozytorium.
1.Początkowo wprowadzamy dane podane przy rejestracji na stronie GitHuba, którymi podpisywane będą wprowadzone przez nas zmiany:
$ git config –global user.name “nazwa użytkownika”
$ git config –global user.email “email”
2.Za pomocą komendy $git init tworzymy lokalne repozytorium w wybranym folderze
3.Status każdego pliku w tym folderze można sprawdzić za pomocą komendy $git status. Status o nazwie untracked oznacza, że taki plik oczekuje na dodanie do tzw. staging area, z którego dopiero może zostać wysłany w postaci commita do lokalnego repozytorium
4.Dodanie pojedynczego pliku do staging area wykonuje się za pomocą komendy $git add “nazwa_pliku.rozszerzenie”
5.Tak przygotowany plik należy wysłać, wraz z wiadomością jednoznacznie informującą jakie zmiany zostały wprowadzone, do lokalnego repozytorium za pomocą komendy $git commit –m”wiadomość”
Wróćmy do naszego repozytorium stworzonego w GitHubowej chmurze. Należy skopiować link do naszego repozytorium, a następnie za pomocą konsoli Git Bash wpisać poniższą komendę, która doda informacje o danym repozytorium do tego lokalnego:
$ git remote add origin link_do_repozytorium
Każda zmiana w postaci commita może zostać “wypchnięta” na zewnętrzne repozytorium, do którego link podaliśmy powyżej, poprzez komendę $ git push –u origin master, gdzie master jest nazwą gałęzi. Jeżeli wszystko poprawnie zadziała to po chwili wprowadzone przez nas zmiany powinny pojawić się w serwisie GitHub. W momencie jakiegoś błędu Git bardzo dokładnie informuje co poszło nie tak – wystarczy postępować zgodnie z instrukcjami jakie podaje nam konsola Bash.
W przypadku dokonywania zmian w chmurze lub gdy ktoś inny dokonał zmian w pliku, należy zmiany te pobrać do lokalnego repozytorium. Służy do tego komenda $ git pull –rebase.
Ciekawostka z GitHuba – od 1 października 2020 roku firma postanowiła zmienić nazwy repozytoriów z master na main. Dlaczego? Kojarzyło się to wielu ludziom z odniesieniami związanymi z niewolnictwem. Chcieli je zastąpić bardziej uniwersalnymi słowami. W rzeczywistości dalej możemy korzystać z tych określeń zamiennie, uwzględniając ich zamianę podczas użytkowania.
W tym rozdziale pokazano pewne podstawy pracy z narzędziem do kontroli wersji, które będą potrzebne do zrozumienia i obsługi połączenia pomiędzy tym systemem, a środowiskiem TIA Portal. Przytoczone komendy to tylko mały kawałek wiedzy o narzędziu jakim jest Git, a jak można zaobserwować jest to bardzo przydatne i pomocne narzędzie, które może znacząco ułatwić pracę indywidualną jak i grupową, dlatego też zachęcamy do poszerzania wiedzy na temat Gita we własnym zakresie.
GIT + TIA
Głównym tematem tego artykułu jest wykorzystanie narzędzia do kontroli wersji we współpracy z programowaniem sterowników PLC firmy Siemens w środowisku TIA Portal. Podejść do wersjonowania kodu współpracujących z oprogramowaniem TIA Portal jest kilka i każde z nich ma swoje wady i zalety. Jedno z rozwiązań, które można znaleźć pod nazwą Project Server pozwala na wersjonowanie i dzielenie się z innymi użytkownikami całym kodem programu. Problem w tym, że często istnieje potrzeba wykonania takich operacji tylko z fragmentem np. jedną instancją w postaci bloku funkcyjnego, którą wykorzystuje się w wielu projektach przy zmianie tylko niektórych parametrów. Przy takich wymaganiach bardzo dobrze sprawdza się interfejs wbudowany w TIA Portal, który nazywa się Version Control Interface (VCI). Ważny jest fakt, że VCI pojawiło się dopiero w TIA Portal V16. Głównym celem tego artykułu jest zapoznanie się z tym interfejsem oraz nauka jego obsługi w połączeniu z wersjonowaniem kodu za pomocą Gita i GitHuba.
Chcąc rozpocząć współpracę pomiędzy TIA Portal, a Gitem w pierwszej kolejności należy pobrać ze strony Siemensa wtyczkę, której nazwa widoczna jest poniżej.
Następnym krokiem jest podążanie za załączoną w folderze instrukcją w celu poprawnej instalacji wtyczki VCI Git Connector. Mając zainstalowaną wtyczkę, już w programie TIA Portal należy ją aktywować – wybrać zakładkę Add-ins po prawej stronie ekranu, a następnie PPM wybrać daną wtyczkę tak, jak prezentuje to poniższe zdjęcie. Następnie pojawi się dodatkowe okno, w którym należy zezwolić na dostęp do programu.
Mając aktywowaną wtyczkę można przejść do konfiguracji środowiska VCI. Rozpoczynając pracę z VCI pierwsze co należy zrobić to stworzyć obszar – workspace, w którym przeprowadzane będą wszystkie operacje związane z wersjonowaniem kodu. Następnie należy wybrać Configure workspace :
Dzięki niej można wskazać folder, w którym zainicjalizowano wcześniej repozytorium oraz koniecznie trzeba wybrać Git w polu Version control add-in tak, jak na poniższym zdjęciu.
Możliwe jest korzystanie z uproszczonej kontroli wersji, niewymagającej dodatkowej wtyczki. Wystarczy wtedy pozostawić pole Version control add-in puste, a wprowadzane zmiany będą zapisywane tylko w wyznaczonym folderze.
Warto wspomnieć, że chcąc wersjonować pewne instancje programu takie jak bloki funkcyjne (FB) czy funkcje (FC) mogą one być napisane w różnych językach programowania. Te, które napisane są w języku LAD, VCI konwertuje do postaci plików .xml, a te napisane w języku SCL pozostają w formacie .scl.
Patrząc na poniższe zdjęcie można zaobserwować, że po lewej stronie znajduje się główny projekt, którego elementy można przeciągnąć na prawą stronę, czyli do folderu o określonej ścieżce dostępu, który jest wcześniej zainicjalizowanym repozytorium.
Przeciągnięcie danej instancji spowoduje wywołanie okna, w którym można wpisać informację dotyczącą wprowadzanej zmiany lub wersji kodu. Można zaobserwować, że korzystając z konsoli Git Bash najpierw należało dodać dany plik do staging area, a dopiero w następnym kroku zaakceptować zmiany i dodać do repozytorium za pomocą komendy commit. W tym przypadku jest to wykonywane prawie automatycznie – należy tylko dodać komentarz i zaakceptować, a następnie wyświetli się informacja o dodaniu konkretnego commita, który od razu zostaje “wypchnięty” do zewnętrznego repozytorium na GitHubie (o ile zostało ono wcześniej połączone z tym lokalnym, znajdującym się w określonym folderze).
Korzystając z komendy git log w konsoli Git Bash można zaobserwować wprowadzone przez TIA Portal zmiany – autora, datę wprowadzenia zmian i komentarz, co przedstawia poniższe zdjęcie.
Pamiętać warto o tym, że przed rozpoczęciem pracy z kodem, nad którym pracuje więcej osób zawsze dobrze jest zaciągnąć wszelkie zmiany wprowadzane z poziomu GitHuba czy też przez innych użytkowników z zewnętrznego repozytorium korzystając z funkcji Pull prezentowanej poniżej
Następnie zaciągnięte zmiany, które prezentowane są przez znaczek:
trzeba wgrać do aktualnego programu poprzez sekwencję, w której najpierw ustawia się akcję na import from workspace:
później synchronizuje się aktualny katalog z tym, zaciągniętym z repozytorium za pomocą przycisku Synchronize:
Dobrze wgrane zmiany i brak nieścisłości pomiędzy programem w TIA Portal, a repozytorium sygnalizowane są przez zielone diody tak, jak na zdjęciu poniżej.
Z drugiej strony, każda zmiana jaka zostaje wprowadzona do danej instancji z poziomu TIA Portal sygnalizowana jest w VCI za pomocą znaczka:
, a import tych zmian należy wykonać poprzez ustawienie akcji na export to workspace:
i późniejszą synchronizację, co pozwala na dodanie komentarza do commita i bezpośrednie wyeksportowanie zmian do zewnętrznego repozytorium.
W ustawieniach zaprezentowanych na poniższym zdjęciu można włączyć lub wyłączyć automatyczne “wypychanie” zmian do repozytorium na GitHubie, ale opcja ta wydaje się bardzo wygodna przynajmniej przy początkowych etapach pracy. Dodatkowo widoczne są tutaj inne opcje, które nie zostały omówione w artykule. Ich zastosowania są analogiczne do komend o tych samych nazwach stosowanych w konsoli Git Bash, dlatego też zagłębienie się w obsługę Gita pozwoli na lepsze zrozumienie całego VCI.
WIZUALIZACJA ZMIAN W JĘZYKU LAD I FBD
Ostatnim aspektem, jaki zostanie poruszony w tym artykule, jest możliwość podglądu zmian w dwóch różnych wersjach programu napisanych w języku LAD za pomocą narzędzia ACT (Automation Compare Tool). Jak można zauważyć program napisany w języku SCL jest zapisywany w repozytorium w postaci pliku .scl co umożliwia bezpośredni odczyt takiego kodu. Jak wspomniano wcześniej kod napisany w języku LAD konwertowany jest na mało czytelny format .xml, co wprowadza wiele trudności przy chęci porównania dwóch wersji kodu, a przecież nie warto konfigurować do tego osobnego programu. Narzędzie to pozwala również na porównywanie kodu napisanego w języku FBD.
Przejdźmy zatem do instalacji tego oprogramowania. Na stronie Siemensa wyszukujemy narzędzie o nazwie SIMATIC Automation Compare Tool – for the comparsion of LAD/FBD blocks. Do jego pobrania należy mieć zatwierdzone przez support konto (to samo dotyczyło pobierania wtyczki VCI).
Po pobraniu, w TIA Portal wyszukujemy na górnym pasku Options, następnie klikamy Setting i Version control interface. Zjeżdżamy niżej i naciskamy ikonę:
– wyskoczy nam okienko Edit comparison program zaprezentowane poniżej. Dodajemy tutaj ścieżkę do zainstalowanego ACT i potwierdzamy to przyciskiem Modify. W taki sposób dokonaliśmy konfiguracji narzędzia do wizualizacji zmian w kodzie.
Chcąc porównać różne wersje kodu z poziomu TIA Portal należy to zrobić z poziomu Workspace’u w zakładce Version Control Interface, w którym wykonywaliśmy większość czynności odnoszących się do wersjonowania kodu. Tak jak pokazuje zdjęcie poniżej – żeby porównać dwie wersje kodu muszą być one różne względem siebie, co symbolizują przedstawione ikony w kolumnie status, a samo porównanie wykonuje się poprzez wybór funkcji ACT.
Interfejs tej aplikacji jest bardzo prosty i przejrzysty. Jego działanie zaprezentowano na przykładowej funkcji, w której zmieniono nazwę jednej zmiennej z #stop na #reset. Wszelkie zmiany zostały zaznaczone na czerwono, a obie funkcje zostały ze sobą porównane w formie wizualizacji, co można zauważyć na poniższym rysunku.
Niezależnie czy zmiany zostaną wprowadzone w środowisku TIA Portal, na zewnętrznym repozytorium czy przez inne osoby, to po zaciągnięciu zmian do TIA będzie można porównać różne wersje kodu, biorąc pod uwagę fakt, że na zewnętrznym repozytorium przechowywane są one w postaci plików .xml.
To co pozostało, to wykonanie jakiejś określonej akcji z wprowadzonymi zmianami za pomocą odpowiedniego wyboru w kolumnie Action i synchronizacji. Było to prezentowane we wcześniejszych rozdziałach tego artykułu.
PODSUMOWANIE
Jak można zauważyć narzędzie, którego funkcjonalności zostały przedstawione w tym artykule może być bardzo pomocne podczas pracy w grupach, pracy z dużymi programami, w których często wprowadzane są modyfikacji czy wtedy, gdy korzysta się z jednej określonej instancji ze zmiennymi parametrami np. bloku funkcyjnego (FB) na tyle często, że bardziej efektywne jest pobieranie takiego bloku z istniejącego już repozytorium niż pisane go od początku.
Proces instalacyjny, dodatkowe wtyczki, zewnętrzne narzędzia takie jak ACT czy obsługa Gita i GitHuba może okazać się wyzwaniem dla początkującego automatyka, ale chodzi właśnie o to, żeby cały czas się doskonalić i ułatwiać sobie późniejszą pracę. Naprawdę zachęcamy do zapoznania się z narzędziami przedstawionymi w artykule i przede wszystkim do samodzielnej pracy, bo dopiero wtedy wiedza, którą zdobyto zostanie utrwalona. Pamiętajcie o Gicie i GitHubie – prędzej czy później przyjdzie wam się zmierzyć z tym narzędziem w pracy, dlatego lepiej jest mieć je opanowane już teraz!
Mamy nadzieję, że artykuł ten w mniejszym bądź większym stopniu pomógł wam w nauce czegoś nowego albo przypomnieniu, utrwaleniu lub ustandaryzowaniu pewnej wiedzy, którą już wcześniej zdobyliście!
Trzymajcie się!
Wiktor Kawa
Wiktoria Staszewska
0 komentarzy