Seminar Genymotion Self-hosted / Device Image – Architektur und Einsatzplanung

Self-hosted und Device Image adressieren unterschiedliche Betriebsmodelle, verwenden jedoch vergleichbare Android-Geräte-, Zugangs- und Automatisierungskonzepte. Das Seminar schafft eine gemeinsame Entscheidungsgrundlage für Plattformgrenzen, Sicherheitszonen, Kapazität, Rollen und Pilotierung.

Seminarziel

Ein belastbares Zielbild mit Betriebsmodell, Netzsegmenten, Zugriffspfaden, Geräteklassen, Verantwortlichkeiten und Pilotplan wird erarbeitet. Die Entscheidung zwischen eigenem Betrieb und Cloud-Image wird anhand nachvollziehbarer Kriterien vorbereitet.

Inhaltsübersicht

1. 1. Betriebsmodelle abgrenzen
2. 2. Logische Plattformarchitektur
3. 3. Sicherheits- und Datenklassifikation
4. 4. Kapazitäts- und Verfügbarkeitsrahmen
5. 5. Rollen und Betriebsprozesse
6. 6. Pilot und Entscheidungsnachweis
7. Praxisprojekt und Übungen
8. Zielgruppe und Voraussetzungen
9. Didaktik und Arbeitsweise

Fachliche Einordnung

Der Themenblock ist als eigenständiger Qualifizierungsbaustein für produktionsnahe Android-Test- und Betriebsumgebungen abgegrenzt. Konfigurationen werden nicht nur demonstriert, sondern mit Sollwerten, Negativtests, Rücksetzschritten und dokumentierten Prüfpunkten abgesichert. Dadurch bleiben die erarbeiteten Abläufe auf Self-hosted- und Device-Image-Szenarien übertragbar.

Seminarinhalte

1. Betriebsmodelle abgrenzen

Self-hosted, private Infrastruktur und Device Image werden nach Kontrolle, Bereitstellung und Verantwortlichkeit eingeordnet.

1. Schritt 1: Datenstandort, Skalierungsbedarf, Netzabhängigkeiten und Betriebsverantwortung erfassen.
2. Schritt 2: Muss-Kriterien für On-Premises, private Cloud oder Cloud-Image markieren.
3. Schritt 3: Betriebsmodelle anhand einer gewichteten Nutzwertanalyse vergleichen.
4. Schritt 4: Entscheidung, offene Punkte und Annahmen in einem Architekturprotokoll festhalten.

2. Logische Plattformarchitektur

Komponenten und Kommunikationsbeziehungen werden unabhängig von konkreten Produkten visualisiert.

1. Schritt 1: Nutzer, Testwerkzeuge, virtuelle Geräte, Administrationszugänge und Datenspeicher identifizieren.
2. Schritt 2: Steuer-, Medien-, ADB-, SSH- und API-Verbindungen einzeichnen.
3. Schritt 3: Vertrauenszonen und Übergänge zwischen Arbeitsplatz, CI/CD und Geräteplattform markieren.
4. Schritt 4: Architekturdiagramm gegen drei typische Nutzungsszenarien prüfen.

3. Sicherheits- und Datenklassifikation

Schutzbedarf und Zugriffskontrollen werden früh in das Zielbild integriert.

1. Schritt 1: Testdaten, APKs, Protokolle, Screenshots und Gerätezustände klassifizieren.
2. Schritt 2: Zulässige Speicherorte und Übertragungswege festlegen.
3. Schritt 3: Administrations-, Entwickler- und Nutzerrollen trennen.
4. Schritt 4: Nachweis-, Lösch- und Aufbewahrungsanforderungen als Architekturvorgaben dokumentieren.

4. Kapazitäts- und Verfügbarkeitsrahmen

Lastprofile werden grob dimensioniert und mit Servicezielen verbunden.

1. Schritt 1: Gleichzeitige Geräte, typische Laufzeiten und Spitzenlasten schätzen.
2. Schritt 2: Geräteklassen für interaktive, automatisierte und leistungsintensive Nutzung bilden.
3. Schritt 3: Verfügbarkeits-, Wiederanlauf- und Wartungsziele festlegen.
4. Schritt 4: Kapazitätsrisiken und Messpunkte für den Pilotbetrieb definieren.

5. Rollen und Betriebsprozesse

Verantwortlichkeiten werden über den gesamten Geräte-Lifecycle verteilt.

1. Schritt 1: Plattform-, Netzwerk-, Security-, Test- und Anwendungsverantwortung benennen.
2. Schritt 2: Bereitstellung, Änderung, Störung, Freigabe und Stilllegung Rollen zuordnen.
3. Schritt 3: Eskalations- und Freigabewege skizzieren.
4. Schritt 4: Ein RACI-orientiertes Rollenblatt für den Pilot erstellen.

6. Pilot und Entscheidungsnachweis

Ein begrenzter Pilot liefert messbare Aussagen für die Produktionsentscheidung.

1. Schritt 1: Zwei bis drei repräsentative Anwendungen und Testfälle auswählen.
2. Schritt 2: Erfolgskriterien für Funktion, Performance, Sicherheit und Bedienbarkeit definieren.
3. Schritt 3: Pilotphasen, Verantwortliche, Messwerte und Abbruchkriterien planen.
4. Schritt 4: Entscheidungsvorlage mit Zielbild, Risiken, Aufwand und nächstem Schritt strukturieren.

Praxisprojekt und Übungen

Die Übungen verwenden einen zusammenhängenden Laborfall. Jeder Arbeitsauftrag enthält Ausgangslage, Sollzustand, Durchführung, Prüfpunkte und eine kontrollierte Bereinigung. Fehlerfälle werden bewusst eingebaut, damit Diagnose und Rückfall nicht erst im Produktivbetrieb erprobt werden.

1. Übung 1: Self-hosted und Device Image werden mit einer gewichteten Entscheidungsmatrix bewertet.
2. Übung 2: Ein logisches Architekturdiagramm mit Vertrauenszonen und Kommunikationspfaden wird erstellt.
3. Übung 3: Ein Pilotplan mit messbaren Akzeptanzkriterien und Rollen wird ausgearbeitet.

Zielgruppe und Voraussetzungen

Zielgruppe: IT-Architektur, technische Projektleitung, Plattformverantwortung, Security Engineering und Mobile QA.

Voraussetzungen: Grundkenntnisse zu virtueller Infrastruktur, Netzwerken und Android-Testprozessen.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurationsschritte, Praxisübungen und kontrollierte Fehlerfälle vertieft. Für jeden wesentlichen Ablauf entstehen wiederverwendbare Checklisten, Konfigurationsnachweise oder Runbooks. Die Bearbeitung erfolgt ohne undokumentierte Sonderkonfigurationen und endet jeweils mit einer technischen Validierung des erreichten Zustands.