Wie lange sollten Unternehmen Mac-CI-Build-Artefakte aufbewahren? Strategieleitfaden 2026

Apple empfiehlt, das Xcode-Archive einer verteilten App aufzubewahren; passende dSYM-Dateien helfen dabei, Abstürze zu symbolisieren (Apple: Debugging-Informationen und Archive). Leiten Sie daraus keine einheitliche Frist für alle Dateien ab: Bewahren Sie Archive und zugehörige dSYM nach Diagnose- und Auditbedarf auf, behandeln Sie Logs, Testberichte, Cache und temporäre Arbeitsverzeichnisse dagegen nach ihrem jeweiligen Zweck. Verschieben Sie alles, was Sie später zwingend benötigen, aus dem leicht bereinigbaren CI-Arbeitsbereich an einen kontrollierten Speicherort.

Für Verantwortliche für iOS-Veröffentlichungen und Crash-Diagnose: Sie können Regeln für Archive, dSYM und deren Zuordnung festlegen.
Für Plattformverantwortliche: Sie trennen wiederherstellbare Cache-Daten von nicht ohne Weiteres ersetzbaren Nachweisen.
Für IT-, Sicherheits- und Compliance-Verantwortliche: Sie dokumentieren Speicherort, Zugriffsrechte, Zuständigkeit und Wiederherstellungsprüfung.

Fehlende Artefakte unterbrechen Diagnose und Nachweisführung

Ein Build-Ergebnis ist nicht gleichbedeutend mit einem Quellcode-Stand. Selbst wenn Sie denselben Quellcode erneut bauen können, ist das neu erzeugte Ergebnis nicht automatisch mit einem bereits veröffentlichten Binärpaket oder dessen Debug-Symbolen austauschbar. Für eine spätere Untersuchung benötigen Sie den Bezug zwischen Veröffentlichung, Build-Kennung und den tatsächlich verwendeten Dateien.

Apple beschreibt das Erstellen eines Archive im Zusammenhang mit der Verteilung einer App. Die Dokumentation zu Debugging-Informationen behandelt außerdem, warum das passende Archive und die zugehörigen Symbole für spätere Untersuchungen wichtig sind (Apple: App verteilen und Archive erstellen, Apple: Debugging-Informationen im Build). Daraus folgt eine praktische Regel: Behandeln Sie Archive und dSYM nicht als austauschbare Nebenprodukte, sondern bewahren Sie ihre Zuordnung gemeinsam mit dem Veröffentlichungsnachweis auf.

Lässt sich ein Absturz noch symbolisieren, wenn das Xcode-Archive gelöscht wurde?
Eine passende dSYM kann für die Symbolisierung entscheidend sein, aber daraus folgt nicht, dass ein dSYM das Archive ersetzt. Prüfen Sie, welche Diagnose- und Wiederherstellungsanforderungen für Ihre Veröffentlichung gelten, und sichern Sie die zusammengehörigen Dateien. Apple beschreibt die Zuordnung von Symbolnamen zu einem Absturzbericht in seiner Anleitung zur Symbolisierung von Crash-Berichten.

Bei einer späteren Fehleranalyse reicht der Dateiname allein nicht als Identitätsnachweis. Verknüpfen Sie die Dateien mindestens mit der veröffentlichten Version, der Build-Kennung und dem zugehörigen Datensatz der Pipeline. Wenn Sie diese Informationen getrennt speichern, muss ein späterer Prüfer erst rekonstruieren, ob Archive und dSYM wirklich zusammengehören. Das kostet Zeit und erhöht das Risiko, dass ein technisch lesbares Symbolpaket dem falschen Build zugeordnet wird.

Ein nützlicher Prüfpunkt für Ihre Release-Ablage ist deshalb nicht nur „Datei vorhanden“, sondern „Datei eindeutig zuordenbar“. Legen Sie fest, welche Metadaten neben dem Artefakt gespeichert werden, wer die Zuordnung verifiziert und wie der Nachweis bei einem Wiederherstellungstest erbracht wird.

Aufbewahrung nach Risiko statt nach Dateiendung

Die Aufbewahrungsstrategie für Build-Artefakte in Mac-CI sollte sich an der Folge eines Verlusts orientieren. Ein wiederherstellbarer Cache und ein für eine veröffentlichte Version benötigtes dSYM haben nicht dasselbe Risikoprofil. Auch Logs und Testberichte können für Fehleranalyse oder Freigabeprüfungen wichtig sein, obwohl sie keine Bestandteile des ausgelieferten Programms sind.

Die Tabelle gibt keine allgemeingültigen Fristen vor. Dauer und Umfang richten sich nach Ihrem Diagnosebedarf, internen Prüfanforderungen, Verträgen und den für Ihre Organisation geltenden Datenschutz- und Datenlebenszyklusregeln. Insbesondere lässt sich aus der Dokumentation eines CI-Anbieters keine für jedes Unternehmen passende Aufbewahrungsdauer ableiten.

Müssen Logs, Testberichte und Cache in Mac CI dieselbe Frist haben?
Nein. Ein Cache dient gewöhnlich dazu, Abhängigkeiten oder Zwischenergebnisse wiederzuverwenden. Ein Testbericht belegt ein Prüfergebnis; ein Log kann bei der Ursachenanalyse eines fehlgeschlagenen Builds benötigt werden. Legen Sie für jede Gruppe getrennt fest, wer sie verwendet, welche Entscheidung sie unterstützt und wann sie gelöscht werden darf.

Auch die Plattformmechanik ist von Ihrer fachlichen Regel zu unterscheiden. GitHub Actions dokumentiert Aufbewahrungseinstellungen für Logs und Artefakte auf Organisations- und Unternehmensebene; die tatsächlich wirksame Konfiguration hängt von der Ebene und den gesetzten Grenzen ab (GitHub-Dokumentation zu Organisationsregeln für Logs und Artefakte). Für einzelne Workflow-Artefakte beschreibt die Dokumentation zusätzlich eigene Einstellungen (GitHub-Dokumentation zur Aufbewahrung einzelner Workflow-Artefakte). Prüfen Sie deshalb die Konfiguration Ihrer Plattform, statt eine dort vorhandene Standardvorgabe ungeprüft als Unternehmensregel zu übernehmen.

Speicherorte und Zuständigkeiten gegen Beweislücken absichern

Ein veröffentlichtes Release ist nur dann belastbar archiviert, wenn die zugehörigen Dateien auffindbar und wiederherstellbar sind. Lassen Sie erforderliche Archive, dSYM, Exportdateien und Veröffentlichungsdaten nicht ausschließlich in einem temporären Verzeichnis auf einem einzelnen Mac-CI-Knoten liegen. Ein lokaler Arbeitsbereich kann bei Neuinitialisierung, Aufräumarbeiten oder einem Hardwareausfall verschwinden, ohne dass die Organisation bemerkt, dass ein später benötigter Nachweis mitgelöscht wurde.

Dokumentieren Sie je Artefaktgruppe den autoritativen Speicherort, die für die Ablage verantwortliche Rolle, die berechtigten Zugriffsgruppen und den Löschweg. Das muss nicht für alle Teams dasselbe Speichersystem sein. Entscheidend ist, dass Ihre Regel die Ablage nachvollziehbar macht und nicht stillschweigend auf Annahmen über ein bestimmtes Produkt oder eine bestimmte Infrastruktur setzt.

Hinweis: Ein erfolgreicher Upload beweist noch keine erfolgreiche Wiederherstellung. Prüfen Sie, ob eine berechtigte Person das benötigte Release-Artefakt tatsächlich abrufen und dessen Zuordnung zu Version und Build bestätigen kann.

Verknüpfen Sie jede länger aufzubewahrende Veröffentlichung mit einem nachvollziehbaren Datensatz. Dieser kann beispielsweise Build-Kennung, Versionsbezug, Ablageort, verantwortliche Rolle und Freigabevermerk enthalten. Definieren Sie zudem, ob ein Löschvorgang eine Freigabe erfordert und wie Löschungen dokumentiert werden. So können Sie vermeiden, dass ein allgemeiner Workspace-Cleanup versehentlich Nachweise entfernt, die einer anderen fachlichen Regel unterliegen.

Für die Cache-Behandlung ist eine klare Trennung ebenso wichtig. GitHub erläutert, dass Caches und Workflow-Artefakte unterschiedlichen Zwecken dienen: Cache-Daten unterstützen die Wiederverwendung, während Artefakte Daten zwischen Workflow-Schritten oder nach einem Lauf verfügbar machen können (GitHub-Dokumentation zu Cache und Artefakten). Die Dokumentation zum Cache-Verhalten beschreibt außerdem dessen Nutzung und Bereinigung (GitHub-Dokumentation zu Treffer, Grenzen und Bereinigung des Dependency Cache). Übertragen Sie diese technischen Unterschiede in Ihre eigene Klassifizierung, statt beide Datentypen unter einer einzigen „Build-Dateien“-Regel zu führen.

Löschrisiken an der Plattformgrenze kontrollieren

Eine Plattform kann Ablaufregeln unterstützen, ohne damit Ihre fachliche Entscheidung zu treffen. GitLab dokumentiert beispielsweise den Ablauf von Job-Artefakten und eine Sonderbehandlung für Artefakte der neuesten Pipeline. Prüfen Sie daher, welche Regel für Ihren konkreten Projekt- und Pipeline-Kontext gilt, bevor Sie daraus eine Löschgarantie ableiten (GitLab-Dokumentation zu Job-Artefakten). Eine Plattformfunktion ersetzt weder die Zuordnung von Archive und dSYM noch die Prüfung, ob erforderliche Release-Dateien außerhalb des automatisch bereinigten Bereichs liegen.

Bei Logs und Testberichten sollten Sie zusätzlich klären, ob diese für eine Fehleranalyse, Freigabe oder interne Untersuchung benötigt werden. Legen Sie nicht einfach dieselbe Ablaufregel auf alle Pipeline-Ausgaben, nur weil sie im selben Lauf erzeugt wurden. Prüfen Sie, welche Daten eine gezielte Bereinigung erfasst, ob Ausnahmen möglich sind und ob ein späteres Wiederherstellen vorgesehen ist.

Wie vermeiden Sie, dass eine Bereinigung den Audit-Nachweis eines Releases entfernt?
Trennen Sie Nachweise von bereinigbaren Arbeitsdaten, dokumentieren Sie Speicherort und Eigentümer und testen Sie den Abruf eines ausgewählten Releases. Ein Löschlauf sollte nur Dateien erfassen, deren Wiederherstellbarkeit und Zuständigkeit vorher geklärt sind. Verlassen Sie sich nicht darauf, dass ein Dateiname oder ein erfolgreicher Pipeline-Status eine vollständige Nachweiskette ersetzt.

Für die interne Kontrolle bietet sich eine Verantwortungsmatrix an, ohne dass Sie daraus eine starre Aufbewahrungsdauer ableiten müssen:

• Release-Verantwortliche: bestätigen die Zuordnung von Veröffentlichung, Archive, dSYM und Exportdatei.
• Plattformverantwortliche: pflegen Ablauf- und Bereinigungsregeln für Logs, Cache und temporäre Arbeitsbereiche.
• IT- oder Sicherheitsverantwortliche: genehmigen Zugriff, Löschung und den Ablageweg für relevante Nachweise.
• Prüfverantwortliche: führen Wiederherstellungstests durch und halten das Ergebnis fest.

Abnahme anhand eines Wiederherstellungstests

Führen Sie die Prüfung an einem veröffentlichten Build durch, nicht nur anhand einer Konfigurationsansicht. Damit testen Sie, ob die Zuordnung, die Berechtigungen und die tatsächliche Ablage gemeinsam funktionieren.

1. Release auswählen: Bestimmen Sie ein veröffentlichtes iOS-Release und notieren Sie dessen Versionsbezug sowie Build-Kennung.
2. Dateien abgleichen: Suchen Sie das zugehörige Xcode Archive, die passende dSYM, die ausgelieferte Datei und die erforderlichen Veröffentlichungsinformationen.
3. Zuordnung bestätigen: Prüfen Sie anhand der gespeicherten Metadaten, dass Archive und dSYM tatsächlich zum ausgewählten Release gehören.
4. Berechtigungen kontrollieren: Verifizieren Sie, wer Artefakte lesen, löschen oder aus einem Backup wiederherstellen darf und wer dafür verantwortlich ist.
5. Ablaufregeln testen: Stellen Sie für Logs, Testberichte, Cache und temporäre Dateien fest, welche konkrete Regel greift und ob Ausnahmen dokumentiert sind.
6. Wiederherstellung ausführen: Rufen Sie die notwendigen Release-Dateien aus dem unabhängigen Ablageort ab und dokumentieren Sie, ob sie verwendbar und eindeutig zuordenbar sind.

7. Bereinigung nachweisen: Prüfen Sie, ob eine vorgesehene Löschung nur die freigegebenen Daten betrifft und ob ihr Ergebnis nachvollziehbar festgehalten wird.

8. [ ] Ein veröffentlichtes Release ist mit Version und Build-Kennung auffindbar.

9. [ ] Das passende Archive und die dazugehörige dSYM sind gemeinsam zuordenbar.
10. [ ] Exportdatei und erforderlicher Veröffentlichungsnachweis liegen nicht nur im temporären Mac-Arbeitsbereich.
11. [ ] Speicherort, Zugriffsrechte, Löschverantwortung und Freigaberegel sind dokumentiert.
12. [ ] Logs und Testberichte besitzen eine zweckbezogene Ablaufregel statt einer pauschalen Cache-Regel.
13. [ ] Cache-Daten können nach einer Bereinigung wieder aufgebaut werden; dieser Wiederaufbau wurde geprüft.
14. [ ] Eine Wiederherstellung aus dem festgelegten Ablageort wurde tatsächlich getestet.

Erfahrung für die Abnahme: Wenn der Test nur mit Administratorrechten gelingt, prüfen Sie zusätzlich den regulären Wiederherstellungsweg der zuständigen Rolle. Ein theoretisch vorhandenes Backup hilft dem Team nicht, wenn der Zugriff im Fehlerfall ungeklärt ist.

Speicherbereinigung ohne Verlust von Release-Daten

Cache und temporäre Arbeitsverzeichnisse können sich ansammeln, doch eine pauschale Löschung ist kein Speicherplan. Bestimmen Sie zunächst, welchem Prozess ein Verzeichnis gehört, wann es zuletzt genutzt wurde und ob sein Inhalt ohne Verlust eines Nachweises neu erzeugt werden kann. Bereinigen Sie erst, wenn Eigentümer und Wiederherstellungsweg feststehen. Wo eine Plattform eigene Ablaufmechanismen bereitstellt, gleichen Sie deren Reichweite mit Ihrer Klassifizierung ab.

Für jede Regel sollte erkennbar sein, ob sie eine fachliche Entscheidung oder lediglich eine technische Voreinstellung darstellt. Halten Sie fest, welche Daten geschützt, welche nach erfolgreicher Wiederherstellungsprüfung entbehrlich und welche nur nach Freigabe löschbar sind. Dadurch lassen sich Speicherprobleme gezielt behandeln, ohne dass Archive oder Belege denselben Bereinigungsprozess wie ein Cache durchlaufen.

Wie lange sollten Sie Archive und dSYM für veröffentlichte iOS-Versionen behalten?
Legen Sie keine vermeintlich universelle Frist zugrunde. Bestimmen Sie sie anhand des Zeitraums, in dem Sie Abstürze diagnostizieren, eine Veröffentlichung nachweisen oder Dateien wiederherstellen müssen, und gleichen Sie sie mit Ihren internen Regeln und Verpflichtungen ab. Wenn diese Anforderungen nicht geklärt sind, sollten Sie die benötigten Dateien nicht durch eine allgemeine Workspace-Bereinigung entfernen.

Die Entscheidung lässt sich für jedes Release nachvollziehbar festhalten: Welches Artefakt wird benötigt, wofür wird es gebraucht, wo liegt es, wer darf es abrufen und unter welcher Bedingung darf es gelöscht werden? Diese Angaben helfen auch dann, wenn sich der CI-Anbieter, die Speicherarchitektur oder die Zuständigkeit im Team ändert. Eine konkrete gesetzliche Frist lässt sich daraus nicht pauschal ableiten; prüfen Sie dafür die Vorgaben, die für Ihr Unternehmen tatsächlich gelten.

Wenn Sie bei der Plattformwahl auch die Aufbewahrung und Übergabe Ihrer Build-Daten berücksichtigen, können Sie die Mac-Knoten für den CI-Einsatz in Ihre Planung einbeziehen. Prüfen Sie dabei ausdrücklich, wie Ihr Team erforderliche Daten außerhalb eines flüchtigen Arbeitsbereichs sichert: Ein verfügbarer Build-Knoten allein ersetzt keine Archivierungs- oder Wiederherstellungsregel.

Ein eigener Mac bietet direkten Zugriff auf lokale Schnittstellen und kann für einen dauerhaft stark ausgelasteten, fest kontrollierten Arbeitsablauf die passende Wahl sein. Er bindet jedoch Kapital, benötigt Wartung und lässt sich bei kurzfristigem Mehrbedarf nicht ohne Weiteres erweitern. Ein allgemeiner CI-Arbeitsbereich kann außerdem ungeeignet sein, wenn er zugleich bereinigbare Cache-Daten und langfristig benötigte Release-Nachweise enthält. Für zeitweise zusätzliche Mac-Build-Kapazität kann ein gemieteter Mac von VPSMAC eine flexiblere Ergänzung sein; Ablage, Zugriff und Wiederherstellung Ihrer Artefakte müssen Sie unabhängig davon weiterhin festlegen. Vergleichen Sie dafür die Einsatzmöglichkeiten von VPSMAC mit Ihrem tatsächlichen Bedarf an dauerhaften Knoten, physischen Schnittstellen und kontrollierter Datenhaltung.