Build und CI untersuchen
Den bestehenden Ablauf messen, langsame Schritte untersuchen und Änderungen anhand einer wiederholbaren Ausgangsmessung bewerten. Prüfungen erhalten, die echte Probleme finden.
Android-Testautomatisierung & Gradle-Optimierung
Schneller wissen, ob eine Änderung funktioniert.
Langsame Builds und unzuverlässige Tests machen selbst kleine Änderungen aufwendig. Ich helfe Android-Teams herauszufinden, wo Rückmeldungen zu lange dauern, und ihre Prüfungen für Releases zu verbessern.
Wobei ich helfen kann
Für Teams mit langen Gradle- oder CI-Laufzeiten, instabilen UI-Tests oder zu viel wiederkehrender manueller Release-Prüfung.
Sinnvolle Testabdeckung
Wichtige Verhaltensweisen und frühere Fehler als Ausgangspunkt nutzen. Unit-, Integrations- oder UI-Tests dort verbessern, wo sie verwertbare Rückmeldungen liefern.
Testinfrastruktur verbessern
Instabile Tests untersuchen, ihre Voraussetzungen verbessern und Fehler leichter nachvollziehbar machen. Den Ablauf so dokumentieren, dass Ihr Team ihn weiter pflegen kann.
Ein überschaubarer erster Schritt
Ein repräsentativer Build, ein aktueller Pipeline-Durchlauf und die problematischen Tests sind ein guter Anfang. Wir vereinbaren eine gezielte Untersuchung, ermitteln die Ausgangswerte und wählen die erste Verbesserung, die wir umsetzen und überprüfen.
Passende Projekterfahrung
Ein konkretes Beispiel
blackned
- Die Aufgabe
- Eine AOSP-basierte Kommunikationsplattform in einer Umgebung mit hohen Sicherheitsanforderungen benötigte Unterstützung durch einen erfahrenen Android-Entwickler. Build- und CI/CD-Abläufe waren ein Schwerpunkt.
- Mein Beitrag
- Android-Entwicklung im Team sowie Verbesserungen der Gradle-Builds und der CI/CD-Pipeline unter den bestehenden Sicherheitsvorgaben.
- Dokumentiertes Ergebnis
- Die Gradle-Build-Zeiten sanken in dieser Projektumgebung um rund 50 %, die Gesamtdauer der CI/CD-Pipeline um rund 60 %. Diese Ergebnisse sind keine Prognose für andere Projekte.
blackned
Android-Plattformentwicklung mit schnelleren Build- und Auslieferungsabläufen.
Projektbeschreibung auf Englisch
lexoffice
Android-UI-Tests und die zugehörige Testinfrastruktur verbessert.
Projektbeschreibung auf Englisch
GLS
Android-Testautomatisierung und Build-Optimierung für Logistik und Außeneinsatz, mit deutlich kürzeren Build-Zeiten.
Projektbeschreibung auf Englisch
Vor der Zusammenarbeit
Garantieren Sie eine bestimmte Zeitersparnis?
Nein. Das Potenzial hängt vom Projekt und seinen Rahmenbedingungen ab. Die Ergebnisse im blackned-Projekt sind Erfahrungen aus diesem Auftrag, keine Prognose für eine andere Codebasis.
Brauchen wir mehr UI-Tests?
Nicht unbedingt. Das Ziel sind nützliche Rückmeldungen. Manche Verhaltensweisen lassen sich besser unterhalb der Oberfläche prüfen; zentrale Nutzerabläufe können Ende-zu-Ende-Tests rechtfertigen.
Können Sie mit unserer bestehenden CI arbeiten?
Wir betrachten zunächst Ihre Pipeline, Infrastruktur und Zugriffsbedingungen. Der Auftrag kann sich auf die Teile konzentrieren, die Sie verbessern können, ohne den gesamten Aufbau zu ersetzen.
Wo brauchen Sie Unterstützung?
Wo verliert Ihr Team Zeit: bei lokalen Builds, in der CI, durch unzuverlässige Tests oder manuelle Release-Prüfungen? Vorhandene Laufzeiten sind hilfreich, aber keine Voraussetzung für die erste Nachricht.