Softwarepaketierung und Continuous Integration bei Airbus Defence and Space CeBIT 2015 17. März 2015 Christian Schneemann System Management & Monitoring Architect B1 Systems GmbH [email protected]B1 Systems GmbH - Linux/Open Source Consulting, Training, Support & Development
47
Embed
Softwarepaketierung und Continuous Integration bei · PDF fileSoftwarepaketierung und Continuous Integration bei Airbus Defence and ... VCS:CVS Build-Umgebung ... openSUSE,SLES,RHEL,Fedora,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Softwarepaketierung und ContinuousIntegration bei Airbus Defence andSpaceCeBIT 2015 17. März 2015
Christian SchneemannSystem Management & Monitoring Architect
gegründet 2004primär Linux/Open Source-Themennational & international tätigüber 60 Mitarbeiterunabhängig von Soft- und Hardware-HerstellernLeistungsangebot:
AusgangssituationSoftware für Flight Test Ground StationSoftware und Hardware Support für Telemetrie, MissionMonitoring, Data Processing, Analyse und Visualisierunggeschrieben in C, C++ und FORTRANca. 100 einzelne Software-Komponenten1993 Projektstart mit Unix (SGI IRIX und HPUX); um 2002Migration auf Linux (SuSE 7.x)diverse Migrationen auf verschiedene Linux Distributionen (SuSE7.x → SLES 9.x → SLES 11.x)Bei Projektstart noch auf i586; Umstieg auf x86_64 ist inVorbereitungZielplattform bei Projektstart SLE 11 SP1diverse Third Party Libraries in Gebrauch
ca. 100 Software-ProjekteIDE: proprietär (EOL und nicht mehr unterstützt)VCS: CVSBuild-Umgebung: Kontrolle über IDE und andere Projekte mitMakefiles, imake, qmake, ...Betriebssystem: SLE 11 SP1 i586Entwickler-Workstations: Fat Clients (Diskless, Distro Imageread-only, Homes auf NFS)Continuous Integration: KeineDeployment: von Hand direkt in einen zentral genutztenNFS-Ordner
neue Entwicklungsumgebung für die EntwicklerCross-Platform Development (Linux x86, Linux x86_64,Windows, ...)Software Maintenance über gesamte Projektlaufzeit(Datenvorhalt für mindestens 10 Jahre)konsistente Builds des kompletten Software StacksBauen und Bereitstellen des SW-Stacks in verschiedenenVariationen (Kundenanpassungen)
Entkopplung von IDE und Build-Umgebunglangfristige Lösung für Build-UmgebungHerstellerunabhängigkeit (Produkteinstellung)Build-Umgebung muss IDE-Nutzung und Build Automationerlaubendezentrale Versionsverwaltung (VCS) für Entwicklung außerhalbdes Firmennetzwerks (z. B. bei Testeinsätzen)
Archivierung von Quellen und Buildsvon jedem Release
In 10 Jahren muss es möglich sein,exakt den selben Code zu bauenauf die selbe Art zu bauenBuilds auszuführen und zu testenan Ort und Stelle Fehler zu suchen und zu beheben
trotzdem einfache Bedienung, falls sehr selten genutzt
statt Entwicklung einzelner Programme: Entwicklung eineskonsistenten ProduktsEinführung eines Maintenance WorkflowUm Softwarefehler während des Release Life Cycles zu beheben,
alles automatisierenanstatt alles zu dokumentieren.
Beibehalten der Automatisierung, damit bei Änderungen sofortauffällt, wenn Fehler auftreten
1 Entwicklung: Git Master Branch, Feature Branch möglich2 Test: durch eine spezielle Git Tag Notation FTGS_v1.0.03 Release: Release Manager staged Projekt nach Bedarf aus der
Jede Staging-Stufe und jedes Release ist ein OBS-Projekt.Maintenance eines Pakets erfolgt unter Verwendung von GitBranches durch Entwickler.Releases sind „abgehängte“ und konsistente Produkt-Snapshots.
„Distribution Development Platform“https://www.openbuildservice.org
seit Januar 2006 unter der GPL verfügbarseit Mai 2011 als Open Build Service bekannt (vorher openSUSEBuild Service)Nachfolger des SUSE internen Build-SystemsReferenzinstallation: https://build.opensuse.org
erlaubt konsistente und reproduzierbare Software Buildsintegriert VersionskontrollsystemeSkalierbar durch Einsatz mehrerer Workerlöst Abhängigkeiten selbstständig aufeingebaute Revisionsverwaltung mit „Deduplizierung“vollautomatisierte Abläufe vom Paketbau bisRepositoryerstellung und Signierung
DON’Ts:Deployment von Tarball/Binary-Blobs via rsync unter der Hand,ohne Kenntnisse des Package Management SystemDeployment durch automatisierte Fetch-Skriptedas Rad neu erfinden . . .Bauen von Softwarepaketen (RPM, DEB, . . . ) aufEntwickler-Workstation von Hand
Nutze den Open Build ServiceDie „Power“ von Continuous Integration und der ExtremeProgramming Ära nutzen!Nur einen Software-Stand pflegen:
für verschiedene Linux Distributionen, Releases oder ServicePacksfür verschiedene Architekturen (x86_64, i586, s390x, ia64,ppc64, pcc, ARM, . . . ). . . in einem Aufwasch: Cross-Distribution-ArchitecturePackaging
erhöhte Sicherheits-/Integritätsanforderungen? Eigene Paketemit eigenem Schlüssel signieren!