Rozpoczynanie pracy z DevOps dla systemów wbudowanych przy użyciu ATmega328P

Metodyki DevOps i Agile przekształciły rozwój oprogramowania, kładąc nacisk na współpracę, automatyzację i ciągłe doskonalenie. Zastosowanie zasad DevOps do moich projektów i wzorców było zmianą gry, zwiększającą efektywność i niezawodność. W tym artykule przejdziemy przez proces konfiguracji ciągłej integracji (CI) dla istniejącego projektu systemów wbudowanych, który używa mikrokontrolera ATmega328P. Na koniec tego artykułu zobaczysz, jak te praktyki mogą usprawnić Twój proces rozwoju i dostarczać produkty wyższej jakości.

Zrozumienie DevOps i Agile dla systemów wbudowanych

DevOps to zestaw praktyk, spopularyzowanych przez świat oprogramowania, który łączy rozwój oprogramowania (Dev) i operacje IT (Ops) w ciągły przepływ. W świecie oprogramowania było powszechne rozwijanie oprogramowania i „przekazywanie go przez mur” do osób odpowiedzialnych za operacje w celu wdrożenia u klientów. DevOps wprowadził sposób nie tylko na zburzenie tego muru, ale także na automatyzację całego procesu od początku do końca. W świecie sprzętu znajdujemy podobieństwa między rozwojem produktu a produkcją, ciągle przekazując projekt „przez mur” do naszych zespołów inżynierii produkcji, aby upewnić się, że wszystko jest gotowe do produkcji.

W projektowaniu produktów wbudowanych nadal musimy przeprowadzić nasze oprogramowanie przez produkcję, ale stajemy przed wyzwaniem szybszego niż kiedykolwiek poruszania się i dostarczania najwyższej możliwej jakości. Dzięki zasadom DevOps dążymy do rozwiązania niektórych z tych wyzwań.

• Zależności sprzętowe: Systemy wbudowane zależą od sprzętu i konkretnych rewizji tych PCB. Może to sprawić, że testowanie i wdrażanie będą skomplikowane, jeśli nie zostaną usprawnione w celu automatyzacji i wysokiej skalowalności. Praktyki DevOps pomagają automatyzować te procesy, używając tego samego zestawu dla sprzętu i oprogramowania oraz wprowadzając je do zautomatyzowanych systemów ciągłej integracji (CI).
• Długie czasy budowania: Budowanie oprogramowania wbudowanego może być trudne do skonfigurowania i skutkować długimi czasami budowania. CI automatyzuje i przyspiesza ten proces, przenosząc budowy do chmury i wykorzystując mocniejsze instancje, do których deweloperzy zwykle nie mają dostępu.
• Ręczne testowanie: Testowanie na rzeczywistym sprzęcie jest niezbędne, ale często manualne, żmudne i czasochłonne. Automatyzacja poprzez testowanie sprzętu w pętli (HIL) poprawia efektywność i dokładność i może być przeniesiona do konfiguracji automatycznego sprzętu testowego skonfigurowanego z systemem CI.

Stosując zasady DevOps, jesteśmy w stanie szybko iterować, używając metodyk Agile w ramach paradygmatu budowania-testowania-wdrażania dla każdej dodatkowej funkcji, którą chcemy wprowadzić do produkcji.

Jak to wszystko działa

„Buduj, testuj i wdrażaj” to często spotykany zestaw słów, gdy rozmawiamy o DevOps. W systemach wbudowanych robimy to samo, ponieważ nasze wdrożenie również trafia do produkcji (a następnie do klienta końcowego). W repozytorium projektu używamy Gitlab CI do prowadzenia naszego kompleksowego procesu pracy dla Embedded DevOps. Używamy czegoś, co nazywa się „pipelines”, aby tworzyć zadania, które realizują określone zadania, takie jak kompilacja oprogramowania, uruchamianie testów na docelowym sprzęcie lub wydawanie go jako oficjalny pakiet. W Gitlabie, pipeline to zbiór zadań, które są wykonywane w sekwencyjnym przepływie, tak jak to:

Rysunek 1: Przykładowy pipeline używany z workflow DevOps ATmega328P w Gitlabie

Oto szczegółowe omówienie skryptu CI (.gitlab-ci.yml), aby dać Ci pomysł, jak to działa.

• Docker: Jak omówiono w Konteneryzacja środowisk budowania i uruchamiania dla testowania sprzętu w pętli, ten etap tworzy obrazy Docker, aby stworzyć spójne środowisko do budowania, testowania i programowania kodu. Zapewnia to, że proces budowania jest powtarzalny na różnych maszynach i architekturach (takich jak komputer stacjonarny w porównaniu z Raspberry Pi).
• Test: Ten etap uruchamia testy jednostkowe, aby zweryfikować, czy Twój kod robi to, co zamierzasz. Automatyczne testy są szybkie i ważne podczas modyfikowania lub refaktoryzacji istniejącego kodu.
• Budowa: Ten etap kompiluje kod źródłowy na pliki binarne. W tym projekcie generuje artefakty takie jak pliki .elf i .hex, które są używane do programowania chipa ATmega328P.
• HIL (Hardware-in-the-Loop): Ten etap polega na testowaniu oprogramowania na rzeczywistym sprzęcie, aby upewnić się, że działa poprawnie w warunkach rzeczywistych. Ładuje oprogramowanie na sprzęt i uruchamia testy, aby zweryfikować, czy zaprojektowana funkcjonalność faktycznie działa na gotowym produkcie.
• Wdrażanie: Ten etap zajmuje się publikowaniem zbudowanych artefaktów w rejestrze pakietów, czyniąc je dostępnymi do użycia.
• Wydanie: Ten etap tworzy nowe wydanie oprogramowania, automatyzując proces dostarczania, aby zapewnić szybkie i niezawodne aktualizacje. Z tego korzystałby zespół produkcyjny, aby pobrać potrzebną wersję oprogramowania dla całego montażu produktu.

Drobne szczegóły

Istnieją drobne szczegóły, które przekształcają ten przepływ pracy z podstawowej implementacji DevOps w płynnie działający, dobrze udokumentowany i łatwy do obserwacji system. Istnieje kilka subtelnych szczegółów w przepływie pracy CI, na które warto zwrócić uwagę.

• Semantyczne wersjonowanie: Ustawienie wersji, czy to za pomocą mechanizmu automatycznego, czy ręcznie, jest niezwykle ważne dla cyklu wydawniczego, zwłaszcza przy pracy z produkcją. Jako przykład, jest to ustawiane jako zmienna w skrypcie CI, a następnie używane w zadaniach publikowania i wydawania.
• Logika budowania Docker: Zauważysz, że istnieje blok logiki, który jest używany dla budowania kontenerów Docker:

if [ "$CI_COMMIT_REF_SLUG" == "$CI_DEFAULT_BRANCH" ]; then

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:latest

else

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:$CI_COMMIT_REF_SLUG

fi

Ta logika ustala zasadę, że tag „latest” jest używany tylko dla obrazu Docker zbudowanego na głównej gałęzi (tj. po pomyślnym przejściu żądania scalenia). Zapewnia to, że tylko pomyślne żądania scalenia publikują najnowszy i najlepszy obraz docker, z którego korzystają wszyscy i wszystkie potoki.

• Raporty i pokrycie: W nowoczesnych systemach CI takich jak Gitlab jesteśmy w stanie wydobyć i wyświetlić raporty z testów i pokrycia w naszych żądaniach scalenia i potokach. Na przykład, w tym żądaniu scalenia uchwyciliśmy pokrycie kodu:

Rysunek 2: Pokrycie kodu w żądaniu scalenia

Na tym zrzucie ekranu, Gitlab podsumowuje testy przeprowadzone na celu przy użyciu sprzętu w pętli:

Rysunek 3: Podsumowanie testów przeprowadzonych na celu

W końcu, gdy nasz kod zostanie zweryfikowany zarówno za pomocą testów jednostkowych, jak i na celu, etapy publikacji i wydania generują ładny pakiet, który może być wykorzystany przez zespół produkcyjny:

Rysunek 4: Wydanie pakietu oprogramowania

Za pomocą wszystkich tych zautomatyzowanych kroków możemy iteracyjnie wypuszczać nowe funkcje w sposób zwinny. Nie ma potrzeby rozwijania wielu funkcji, wysyłania ich do działu QA, a następnie przeglądu na potrzeby wydania pakietu przez zespół produkcyjny. Wszystko tutaj dzieje się w ramach jednego przepływu pracy i jest całkowicie zautomatyzowane.

Podsumowanie

W tym artykule zbadaliśmy, jak metodyki DevOps i Agile mogą być stosowane w rozwoju systemów wbudowanych, konkretnie przy użyciu mikrokontrolera ATmega328P. Omówiliśmy korzyści płynące z wdrożenia przepływu pracy CI w Gitlab, które obejmują automatyzację, szybsze czasy budowania i efektywne testowanie. Rozkładając skrypt CI i wyjaśniając każdy etap, pokazaliśmy, jak stworzyć solidny i usprawniony proces rozwoju, który zwiększa efektywność i jakość produktu. Postępując zgodnie z tym praktycznym przewodnikiem (oraz kodem źródłowym w repozytorium) powinieneś być również w stanie skonfigurować własny przepływ pracy Embedded DevOps.

Kod źródłowy projektu można znaleźć tutaj:https://gitlab.com/embedded-designs/atmega328p-serial-led-control.