# Geteilte Verantwortungen - Sprintweise Team-Rotation Version: 48 | Last modified: 2025-03-07T11:32:53.545+01:00 Source: confluence page ID 304424588 --- AllgemeinAm 11.01.2024 haben sich Vertreter der Ast-NuG-Teams darauf geeinigt, die Verantwortung für das Erfassen und Analysieren von Whitesource-Findings, sowie die Umgebungswartung sprintweise zwischen den Teams zu rotieren. Zuständigkeiten: PI 35 (neu)Sprint | Datum | Team Adams | Team Flow | Team Tango → Infinity | 1 | 11.12. - 24.12. | Umgebungwartung | Security | Renovate (Tango) | 2 | 25.12. - 07.01. | Renovate | Umgebungswartung | Security (ab hier Infinity) | 3 | 08.01. - 21.01. | Security | Renovate | Umgebungswartung | 4 | 22.01. - 04.02. | Umgebungwartung | Security | Renovate | 5 | 05.02. - 18.02. | Renovate | Umgebungwartung | Security | 6 | 19.02. - 04.03. | Security | Renovate | Umgebungwartung | 7 | 05.03. - 18.03. | Umgebungwartung | Security | Renovate | 8 | 19.03. - 01.04. | Renovate + Security | Umgebungwartung | | PI 35 (alt) Sprint | Team Adams | Team Flow | Team Tango | Team Infinity | 1 | Umgebungwartung | Security | Renovate | | 2 | | Umgebungswartung | Security | Renovate | 3 | Renovate | | Umgebungswartung | Security | 4 | Security | Renovate | | Umgebungwartung | 5 | Umgebungwartung | Security | Renovate | | 6 | | Umgebungswartung | Security | Renovate | 7 | Renovate | | Umgebungswartung | Security | 8 | Security | Renovate | | Umgebungwartung | PI 34 Sprint | Team Adams | Team Flow | Team Tango | 1 | Umgebungwartung | Security | Renovate | 2 | Renovate | Umgebungswartung | Security | 3 | Security | Renovate | Umgebungswartung | 4 | Umgebungwartung | Security | Renovate | 5 | Renovate | Umgebungwartung | Security | 6 | Security | Renovate | Umgebungwartung | PI 33 Sprint | Team Adams | Team Flow | Team Gravity | Team Tango | 1 | Umgebungwartung | Security | Renovate | | 2 | Renovate | Umgebungswartung | Security | | 3 | Security | Renovate | Umgebungswartung | | 4 | Umgebungwartung | Security | Renovate | | 5 | Renovate | Umgebungwartung | Security | | 6 | Security | Renovate | Umgebungwartung | | Umgebungen, um die wir uns kümmern müssenifp-dev: Dev, Demo, ains, gravity, tango, adams → machen die Teams ifp-integration   ifp-int-next   ifp-int-sys ifp-int-ttt (ITU) ifp-abn-ttt (KTU) Produkte, um die wir uns kümmern müssenArbeitssteuerung UI ASt NuG Mocks Es wäre gut, wenn man trotzdem auch die Produkte prüft, die aus der Arbeitssteuerung kommen: IFP-Common IFP-Auth SecurityVorgehen:Täglich prüfen, ob neue Sicherheitslücken gemeldet wurden (E-Mail-Alerts oder im Tool oder in den Trivy-Findings direkt prüfen). Und Grafana-Dashboard - https://grafana-v2.cnp.comp.db.de/d/e8f2b0d4-6fd5-4cc3-8575-35d485e04f54/vulnerabilities-by-service?orgId=55&var-cluster=ifp-abn-tv998&var-namespace=ifp-abn-ttt&var-image=ast-nug&var-version=1.18.1&var-DS_LOKI=Q3YIx8Q7k&var-DS_PROMETHEUS=ud1IbUwnz Analyse Enabler anlegen und das Stichwort 'ast-nug' nicht vergessen (Enabler-Vorlage und Analyse-Vorgehen beschrieben) Analyse zeitnah einplanen und ggf. Versionsanhebung durchführen Falls eine Anpassung der Implementierung vorzunehmen ist, die komplexer ist, wird ein Folge-Enabler angelegt und die anderen Teams darüber informiert. Hier müssen wir ggf. noch ein gutes Vorgehen finden, welches Team die Umsetzung bei sich zeitnah einplanen kann. Hinweis: die Renovate-MRs sind in ihrer Anzahl begrenzt. Alle Dependency-Updates die das Limit übersteigen können aber in einem Issue im GitLab angesehen werden, der von Renovate automatisch geplegt wird. In der AstNuG ist das z.B. https://git.tech.rz.db.de/ifp/app/arbeitssteuerung/-/issues/9 . Die Liste an Dependencies, die dem Rate-Limit zum Opfer fallen sollte nicht zu lang werden, weil ansonsten die Dauer bis zur Aktualisierung der Dependencies zu groß wird. RenovateVorgehen:Empfehlung: im Sprint-Board eine Aufgabe anlegen und innerhalb des Teams zuweisen. Täglich prüfen, ob neue Renovate Merge Requests geöffnet wurden. Bei den fehlschlagenden Pipelines der MRs nach den Problemen schauen und beheben. Aufwand durch Time Boxing begrenzen. In der Arbeitssteuerung werden diese auch automatisch gemerged, sofern die Pipeline erfolgreich ist. Bei allen anderen Projekten die MRs die Risiken der Änderungen abschätzen, ggf. testen, approven. Bei schwierigen MRs:MRs die aus konkreten Gründen nicht gemerged werden können, z.B. weil größere Refactorings notwendig sind, werden geschlossen. Sie werden unten dokumentiert und ein entsprechender Enabler angelegt. MRs die grundsätzlich merge-bar sind, bei denen es aber zu Problemen kommt sollten angegangen werden. Der Aufwand wird durch Time-Boxing begrenzt. Die Probleme und Fortschritte sollen dabei im MR dokumentiert werden. MRs die während eines Sprints nicht fertiggestellt werden, werden vom vorherigen Team ans nächste Übergeben. MRs sind entweder zu bearbeiten oder zu schließen und sollten nicht ohne Grund über längere Zeit offen bleiben. Aktuell nicht merge-bare Dependencies:Camunda-Plattform 11, zeebe docker tag v8.6.0 und operate docker tag to v8.6.0: vgl. MR 2068, MR 2069 und MR 2070. UmgebungswartungRelease Candidates bauen und deployenJeden zweiten Mittwoch (hierfür gibt es einen Termin; falls man den nicht im Kalender hat → auf Teamkolleg:innen zugehen) wird ein Release Candidate erstellt und deployed, siehe: Solution Train Capacity2Schedule | Releasemanagement Kundentestumgebung | Microsoft Teams im Auge behalten und wie gewünscht Deployments durchführen Begleitung Kundentest Resourcen für Kundentest:  System Health beobachten und ggf. auf Wiederherstellung hinwirkenProbleme werden ggf. auch von den Testern gemeldet!Im Wesentlichen ist regelmäßig zu beobachten, ob die Umgebungen, um die wir uns kümmern müssen, noch laufen. Für eine grobe Übersicht gibt es folgende Tools: die Umgebungsübersicht IFP: ifp-infotafel.cnp.comp.db.de ArgoCD: argocd.cnp.comp.db.de Grafana: grafana-v2.cnp.comp.db.de Fallen Unregelmäßigkeiten oder Probleme auf: versuchen, das Problem einzugrenzen bzw. Informationen darüber zu sammeln anhand der Logs → z.B. über Grafana oder direkt auf den Pods (z.B. über K9s) ist das Problem nicht konkretisier- oder kein konkretes Team zur Behebung ermittelbarKanal "ASt NuG privat" ODER SIT-Team fragen gibt es Anhaltspunkte, welches Team für die Behebung in Frage kommt → Bug-Ticket erstellenhier ist eine teamübergreifende Ansicht der vorhandenen Bug-Tickets