Continuous Integration mit dem

Continuous Integration mit dem
Embedded Computing Conference 31. Mai 2016, © Markus Kappeler
Continus Integration
1. Continus tablets:
These tablets have been prescribed for you by your doctor
to relieve severe pain over a period of 12 hours. They
contain the active ingredient morphine which belongs to a
group of medicines called strong analgesics or ‘painkillers’.
Continuous Integration mit Yocto Project
Agenda
●
Was ist Continuous Integration
●
Was ist das yocto Project
●
Continuous Integration & Yocto
●
Yocto: CI vs. One shot
●
Zusammenfassung
Continuous Integration
●
Wer macht CI?
●
Was ist das Gegenteil von CI?
●
Was ist CI?
●
●
CI = (git | svn ) x Jenkins
Warum CI?
Continous Integration
Continuous Integration (CI) is a development
practice that requires developers to integrate
code into a shared repository several times
a day. Each check-in is then verified by an
automated build, allowing teams to detect
problems early.
CI: One Repository
●
●
●
Nutzung von Software Version Managament Tool: git,
svn
Alles in einem Repository
●
Source Code
●
IDE Setup / Compiler settings, make files
●
Resourcen: Bilder, Audio, etc.
Only master Branch
●
●
Branches nur für Maintenance
Alle Entwickler commiten Änderungen laufend
CI: Automate Build
●
●
Alles mit einem Script
●
Von Unix / Linux kennt man make / automake
●
Java Entwickler kennen ant oder maven
●
Qt Entwickler kennen qmake
●
.NET kennt MS Build
Jeder kann build starten und bekommt Resultat
●
●
Kein Build-Master, keine Abhängigkeit zu Personen
Auch DB-Entities müssen erzeugt werden
●
SQL create table, insert into etc.
●
DB restore
CI: Self testing
●
Unit Test
●
Komplexere Klassen mit Unit Test
●
Junit, cppunit, gtest, ptest
●
TestCase ideal von anderer Person
●
Test Driven Design als Inspiration
●
●
Write test before code
Integration and AcceptanceTest
●
Tool-Support: FitNesse, sahi (web apps)
CI: every commit builds
●
Build auf Integration-Server
●
Abbild vom Zustand des Repositories
●
Ideal: jeder einzelne Commit führt zu Build & Test
●
Einsatz von Tools:
●
●
Jenkins, Hudson
●
Travis
●
Bamboo
Nightly Build ist nicht gut genug
●
Zuviele Änderungen
●
Aufwendige Suche nach der Ursache bei broken build
CI: fix broken build
●
Sofort
●
Keep it green
●
CI baut auf einem sauberen Build auf.
●
Geht es zu lange, revert letzten commit
●
●
●
Entwickler muss zuerst lokal bauen, vor commit.
Kent Beck: „Es gibt kein wichtigeren Task als das
Fixen vom Build.“
Achtung: fear driven development ist kontra produktiv
CI: keep build fast
●
Faustregel: build sollte unter 10 Minuten sein
●
Spare nicht bei CPU-Speed, RAM, SSD
●
Benutze ccache und parallel builds
●
Analysiere build periodisch, wenn > 10 Min.
●
Neue / anderer compiler
●
Neue / andere Tools
●
Schnellere Hardware
Warum CI?
●
Qualitätsicherung
●
Schnellere Time-to-market
●
Risiko-Reduzierung
yocto
●
●
●
The yocto project is not a embedded linux
distribution – It creates a custom one for you!
Das yocto Projekt ist nicht ein einzelnes open
source Projekt – es ist ein Ecosystem.
yocto ist eine Kombination von ready to run LinuxDistro mit der Flexibilität eines custom Linux-OS.
Was ist das yocto project
●
Opensource Projekt mit aktiver Community
●
Ein Sammlung von embedded Projekten und Tools:
●
●
Board Support Packages
●
Application Development Tools (Eclipse Plugins)
●
Compiler, Libraries, Tools
Referenz Distro Poky
●
●
Kompletes Build-System basierend auf bitbake
Release alle 6 Monate (April und Oktober) mit aktuellem
Kernel LTS, Toolchain und Package Versionen.
It's not an embedded Linux distribution,
It creates a custom one for you.
yocto build process
source yocto project
yocto Layers
Layers beinhalten Rezepte
● Layers können bestehende Rezepte erweitern, ändern
● Layers nach Funktionen gruppieren
●
Developer Specific
Commercial
UI-Specific
Hardware Specific BSP
yocto Layer (meta-yocto)
Open embedded core Layer (meta)
CI & Yocto: One repository
●
Min. 3 Repositories (meist 4 oder mehr)
●
Yocto Project
●
(Openembedded)
●
BSP Layer
●
Eigentliche Applikation in separaten layer
●
git submodule um Stand zusammen zu halten
●
Script, welches definierten Stand fetched
●
●
Commit id
●
Tag
Alles in ein „neues“ Repository nicht empfehlenswert
CI & Yocto: Automate build
●
●
●
Yocto und bitbake
Ganze Images oder auch nur einzelne
Packages
Autobuilder ist buildbot von Yocto
CI & Yocto: Automate build
●
Toaster: Web-Interface zu Yocto Project
●
Jeder kann einfach build ausführen
●
Nicht wirklich CI Tool
CI & Yocto: Self testing
●
●
Yocto hat built-in Test-Framework
●
ptest Framework in phyton
●
In local.conf: TEST_IMAGE = “1”
Architecture spezifische Test
●
qemu
●
Direkt auf target:
–
–
–
nfs
ssh
serial console
CI & Yocto: every commit builds
●
Autobuilder ist buildbot von Yocto
●
Yocto lässt sich mit CI-Tool kombinieren
●
z.B. Jenkins
–
●
Script Ausführen: update, bitbake my-image
Every commit? Hängt von Repository Setup ab
●
Erfahrung nicht zwingend
●
Applikation separates CI
CI & Yocto: keep build fast
●
Yocto hat built-in build cache
●
Share downloads folder
●
●
●
Wurde ein Package schon downloaded, profitieren
die nächsten
Share sstate
●
Wird nicht alles von scratch gebaut
●
Bis zu 80% Zeit Einsparung
Mirror sstate und download
Yocto: CI vs. One shot
Ausgangslage:
●
Yocto beinhaltet auch Toolchain, BSP
●
Yocto hat fixen Release Zyklus von 6 Monaten
●
Geplante Einführung von Projekt in 18 Monate
Soll man bei Projekt-Start Stand einmal YoctoVersion festlegen oder fortlaufend aktuell halten?
Yocto: One shot
●
●
Bei Projekt Start werden Versionen festgelegt.
Grosse Anzahl SW Packages mit der man sich
vertraut macht
●
Was muss man selber implementieren
●
Benutzen, was da ist. → Design festgelegt
Yocto: One shot
April - Sep.
Okt – März
April - Sept.
Okt. - März
Yocto 2.x
Applikation
●
●
●
Kann eigenen Design nicht an neue Features
anpassen.
Erweiterungen an open source Packages müssen
backported werden.
Vielleicht wurden Bugs bereits von Community
gefixed....
Yocto: One shot
April - Sep.
Okt – März
April - Sept.
Okt. - März
EoL
Yocto 2.x
Applikation
●
Beim Release Datum ist Infra +18 Monate
●
Beim Release Datum ist EoL Yocto Version
●
Repositories / Downloads müssen gesichert werden
●
Was tun bei neuem Feature?
●
Update Toolchain, Kernel, Libraries
●
Aufwand? Je nach Komplexität 3-6 Monate
Yocto: CI approach
April - Sep.
Yocto 2.x
Okt – März
April - Sept.
Yocto 2.x
Yocto 2.x
Okt. - März
EoL
Yocto 2.x+1
Yocto 2.x+2
Yocto 2.x+3
Applikation
●
Aktuell bleiben
●
Beeinflussung der Community.
●
Feature Request stellen und Requirements besprechen
●
Bug reports, submit patches
●
●
Kann eigenen Design anpassen an neue Features aus Libraries /
Toolchains (z.B. c++11)
Braucht zusätzliche Resourcen
Yocto: CI vs. One shot
●
●
Für grösserer Projekte lohnt sich CI
●
Follow master
●
Aktiv bugtracking, patch submitting
●
Up to date Toolchain, security fixes
BSP den Silicon Hersteller folgen
●
●
Kernel LTS
Generell: follow Yocto stable version
●
Alle 6 Monate alles updaten
Yocto: CI Variante Konsequenz
●
Update Mechanismus auf Target:
●
Yocto basiert auf Package Management (deb, ipk)
●
Ganzes Image update:
–
–
●
Bootloader via USB Stick, SD card
eigenes kleines initram-image ev. mit WebGUI
Config Partition
–
–
Separate /config und Symbolische link von /etc/
/etc mit union fs (Achtung mount time...)
Zusammenfassung
●
●
●
CI mehr als nur Tool installieren
Yocto bietet viel Infrastruktur, welche CI
erlauben und unterstützt
Aktuell bleiben (wenn möglich) auch bei
Toolchain, libraries
Wenn alles nichts bringt
Weitere Infos
●
Website: https://www.yoctoproject.org/
●
Wiki: https://wiki.yoctoproject.org/wiki/Main_Page
●
Git: http://git.yoctoproject.org
●
Martin Fowler: Continuous Integration
●
Jenkins: http://jenkins.org
●
Travis: https://travis-ci.org/
●
FitNesse: http://fitness.org
●
Sahi: http://sahipro.com/
Vielen Dank an
- yocto project: https://www.yoctoproject.org
[email protected]
http://www.bytesatwork.ch