logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak zdefiniować idealny pipeline CI/CD dla urządzeń wbudowanych?

ghost666 30 Wrz 2023 12:42 990 1
  • We wcześniejszym poście: „Jak zdefiniować idealny system kompilacji dla urządzeń wbudowanych?”, omawialiśmy systemy budowy aplikacji i to, jak istotne jest zdefiniowanie nowoczesnego dla projektów embedded. System budowy stanowi podstawę sposobu, w jaki kompilujesz i przygotowujesz swój kod. I jest znacznie bardziej złożony niż tylko debugowanie. Wypracowany system budowania aplikacji zostanie zintegrowany w procesie DevOps i ułatwi funkcjonowanie całej ścieżki dostarczania oprogramowania. Źle zaprojektowany może doprowadzić do wielu problemów w późniejszym cyklu rozwoju oraz kosztować czas i pieniądze.

    Współczesne zespoły tworzące oprogramowanie osadzone wdrażają proces DevOps, który poprawia bezpieczeństwo, automatyzuje cykl życia oprogramowania, poprawia współpracę pomiędzy developerami i umożliwia stałe doskonalenie systemu. DevOps to połączenie filozofii kulturowych, najlepszych praktyk i narzędzi, które przyspieszają dostarczanie oprogramowania. Jeśli wspomnisz o DevOps, wielu programistów osadzonych od razu myśli o ciągłej integracji/ciągłym wdrażaniu (CI/CD). W tym artykule badać będziemy, co jest potrzebne, aby zdefiniować idealny pipeline (potok) CI/CD dla projektów wbudowanych. (Jednak należy pamiętać, że DevOps to coś więcej niż tylko sam potok CI/CD!).

    Co składa się na pipeline CI/CD?

    Pipeline CI/CD to seria kroków lub zadań, które muszą zostać pomyślnie zrealizowane, aby przygotować nową wersję oprogramowania. W pewnym sensie programiści wbudowani zawsze mieli jakiś pipeline CI/CD, ale był to proces przeprowadzany ręcznie i dosyć czasochłonny. Współczesne pojęcie potoku CI/CD zakłada automatyzację i ułatwienie dostarczania szybkich, drobnych usprawnień oprogramowania klientowi. Klasyczny potok CI/CD składa się z trzech prostych działań: kompilacji, testowania i wdrażania. Koncepcyjnie potoki są dość proste, ale drobne szczegóły często sprawiają trudności przy implementacji. Jeśli mielibyśmy wymienić różne składniki potoku CI/CD, to podstawowa lista obejmowałaby:

    1. Repozytoria — miejsce, z którego pobierany jest kod źródłowy do kompilacji (może być jedno lub więcej).
    2. Zautomatyzowany system kompilacji — często jest to zkonteneryzowany system, który może automatycznie budować oprogramowanie w zdefiniowanym środowisku.
    3. Testowanie automatyczne — zawiera testy jednostkowe, integracyjne, systemowe i regresji.
    4. Analiza statyczna kodu — weryfikacja oprogramowania, która obejmuje sprawdzanie zgodności z normami kodowania, interpretację metryk, poprawność języka itp.
    5. Emulacja/symulacja sprzętu — użycie sprzętu wirtualnego do testowania i zbadania poprawności oprogramowania.
    6. Mechanizm wdrażania — metoda dostarczenia nowego oprogramowania do produktu po pomyślnym przejściu wszystkich testów automatycznych i kontroli manualnych.
    7. Monitorowanie i raportowanie — mechanizm rejestrowania postępów i raportowania statusu oprogramowania oraz ewentualnych problemów, które mogą wymagać zbadania.
    8. Analiza bezpieczeństwa — weryfikacja w celu zidentyfikowania podatności na ataki i zapewnienia ochrony systemu. (Może ona być uwzględniona w analizie statycznej, ale warto ją wymienić osobno, ponieważ łatwo ją przeoczyć).

    Jak widać, przemyślenie każdej z tych dziedzin, zidentyfikowanie sposobu implementacji, jakiej chcemy użyć, a także jej konfiguracja nie będą trywialne. Wymaga to zastanowienia się i inwestycji czasu we wdrożenie swojego rozwiązania CI/CD, jednakże jak to powinno wyglądać? Każdy zespół ma własne potrzeby, ale istnieją pewne standardowe cechy, które będą mieć wszystkie potoki CI/CD. Przyjrzyjmy się kilku obszarom i określmy ogólny pipeline CI/CD dla programistów systemów wbudowanych. Będziemy go trzymać w formie prostego wzorca, który można rozbudować w przyszłości.

    Definicja idealnego pipeline CI/CD

    Zanim zagłębimy się w koncepcję doskonałego potoku CI/CD, konieczne jest zaznaczenie, że nie powinniśmy pozwalać bieżącym zasobom ani limitacjom na ograniczanie myślenia przy analizie tego zagadnienia. Zespoły, które tworzą potoki CI/CD, często wdrażają je stopniowo, przez kwartały lub lata. Dlatego, chociaż zaplanowany, idealny pipeline CI/CD może wydawać się obecnie nieosiągalny, zdefiniowanie go mówi, dokąd należy zmierzać. Następnie można systematycznie wdrażać każdą funkcję, aż osiągnięty zostanie bazowy, rozrysowany wcześniej potok.

    Twój pierwszy idealny potok CI/CD powinien zawierać następujące zadania:

    1. Kompilacja — operacja kompilacji, która przetworzy firmware i wygeneruje binaria wersji wydaniowej.
    2. Analiza — zadanie kompilacji analizy statycznej kodu. Typowa analiza obejmuje złożoność cyklomatyczną, metryki kodu oraz zgodność ze standardami kodowania, takie jak przewodnik stylu, MISRA i/lub CERT.
    3. Testowanie — operacja testowania przeprowadzi wszystkie weryfikacje niezbędne do dostarczenia produktu. Może obejmować testy jednostkowe, funkcjonalne, integracyjne, systemowe i wydajnościowe.
    4. Raportowanie — zadanie raportowania zbierze efekty z poprzednich działań, dostarczając informacji na temat sukcesu kompilacji, wyników analizy, pokrycia testów i ich rezultatów oraz innych szczegółów.
    5. Scalanie — operacja scalania włączy nową funkcję do gałęzi wdrożenia, gdy wszystkie zadania zakończą się sukcesem. Często związane jest to z elementem ludzkim, ale może być również w pełni zautomatyzowane.
    6. Wdrożenie — po zakończeniu scalania, zadanie to uruchomi i rozpocznie proces wdrożenia oprogramowania w urządzeniach/na produkcji. Ma tutaj zazwyczaj miejsce współpraca z oprogramowaniem do wdrożenia 'w terenie', które może przesyłać firmware do urządzeń pracujących zdalnie, celem ich aktualizacji.

    Idealny potok opisany powyżej to ujęcie, które należy potraktować jako konieczne minimum, do czego powinien dążyć zespół programistów osadzonych. Niewątpliwie można uwzględnić dodatkowe operacje, takie jak testowanie sprzętu w pętli, symulacyjne itp. Niemniej nie zawsze uważa się te działania za wartościowe. Samo wprowadzenie i uruchomienie ich może również zająć sporo czasu. Gdy osiągnięty zostanie poziom zgodny z idealną wizją, można ją albo utrzymywać, albo rozwijać i dodawać kolejne funkcje, które przyniosą zwiększenie wartości czy wydajności zespołowi.

    Przykład doskonałego pipeline CI/CD

    Ludzie często mówią, że obraz jest wart tysiąca słów. Podczas gdy określamy znaczące elementy, które będą niezbędne do stworzenia twojego wzorowego potoku CI/CD, wizualizacja może pomóc lepiej wyobrazić sobie taki system. Na rysunku 1, poniżej, pokazano 'idealny' pipeline, który przedstawiony został powyżej (rysunek należy czytać od lewej do prawej, co jest kolejnością, w jakiej powinno się wykonywać opisane w nim zadania).

    Jak zdefiniować idealny pipeline CI/CD dla urządzeń wbudowanych?
    Rysunek 1. Idealny potok CI/CD, który łączy podstawowe zadania niezbędne do budowy i wdrożenia nowoczesnego oprogramowania osadzonego.


    Na rysunku umieszczono każdą operację (kroki), o których wspomniano powyżej. Serwer CI/CD pobiera materiały źródłowe z repozytorium chmurowego i uruchamia zadania kolejno. Jeśli któreś z nich zakończy się niepowodzeniem, potok zostanie przerwany, a zespół deweloperski otrzyma o tym stosowne powiadomienie. Można zdecydować, że kolejność tych zadań będzie inna. Na przykład można uznać, że analiza statyczna powinna być przeprowadzona przed kompilacją oprogramowania. Jeśli zostanie wykryty problem, może nie być sensu budować systemu. Niemniej, zazwyczaj najpierw tworzy się oprogramowanie, a potem kontynuuje testy, w tym statyczne kodu. W końcu, jeśli oprogramowanie nie buduje się, to czy jest sens je analizować?

    Podsumowanie

    Koncepcja DevOps szybko staje się częścią wielu zespołów zajmujących się procesami rozwoju oprogramowania embedded. CI/CD jest znaczącym czynnikiem wpływającym na przyjęcie filozofii DevOps, ponieważ osoby zaangażowane starają się dostarczać oprogramowanie w szybszym tempie. Automatyzacja, którą oferuje CI/CD, jest również doskonałym narzędziem do ograniczenia konieczności prowadzenia wielu prac manualnych i uwolnienia programistów, aby mogli skupić się na bardziej wartościowych zadaniach czy innowacjach produktowych. Kiedy rozpoczyna się swoją podróż z CI/CD, można wykorzystać podstawowy, idealny potok CI/CD omówiony w tym artykule. Nie należy się jednak obawiać dostosowywać tych podstaw do własnych wymagań, co do doskonałego pipeline CI/CD.

    Źródło: https://www.embedded.com/how-to-define-your-ideal-embedded-ci-cd-pipeline/

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • #2 20754946
    Imekxus
    Poziom 19  
    Zawsze jako testera zastanawia mnie ten podział:
    "zawiera testy jednostkowe, integracyjne, systemowe i regresji. "

    podpowiem, że wszystkie te testy mogą być regresyjne, dodatkowo testy systemowe to też testy integracyjne
REKLAMA