Technischer Release-Manager in Open Bet

9. Februar 2024

Technical Release Manager

Львів

OpenBet ist Sport .

Die Mission von OpenBet besteht darin, Wachstum und Spielerengagement durch ein globales Wett-Ökosystem voranzutreiben, das bei jedem großen Sportereignis in großem Umfang und mit hoher Geschwindigkeit Ergebnisse liefert. Unsere 1000 talentierten Kollegen sind das Spitzenteam des Marktes. Wir erzielen in einer Saison Milliarden von Wetten. 60.000+ pro Sekunde (mehr Transaktionen als Amazon am Prime Day); 100 % Betriebszeit (keine Superbowl-Abstürze!) und wir bauen auf 25 Jahren einfallsreicher Technologie auf, die täglich weiterentwickelt wird.

Wir bieten die Geschwindigkeit, Dynamik und Wachstumschancen eines Start-ups, gestützt auf die Stabilität und Stärke eines globalen Arbeitgebers.
Wir stellen nur Mitarbeiter in Lemberg ein, sodass Sie Ihr Team in unserem Büro treffen können.

Verantwortlichkeiten

• Verwalten Sie den End-to-End-Release-Lebenszyklus und -Prozess für die Handelssystem- und Risikosystem-Produkte.
• Definieren Sie in Zusammenarbeit mit Engineering und Product den Release-Umfang für Haupt-, Neben- und Hotfixes-Releases.
• Definieren Sie den Veröffentlichungszeitplan, identifizieren und kommunizieren Sie alle eingeführten bahnbrechenden Änderungen an in die Plattform integrierte Dritte, um Änderungen im Voraus zu planen.
• Seien Sie sich bewusst und koordinieren Sie die Einsätze zur Einbindung neuer Kunden mit den Integrationsteams von Open Services und SportCast. Kunden-Onboardings erfolgen ohne Versions-Upgrades und die meisten Schritte im Release-Prozess sind nicht anwendbar.
• Kümmern Sie sich um die Nachverfolgung der JIRA-Verwaltungen für die Tickets. Leiten Sie Produktteams an und informieren Sie sie über die Schritte, die sie bei den von ihnen zugestellten Tickets ausführen oder übersehen müssen. Erzwingen Sie im Einzelnen Folgendes:
  
  • Stellen Sie sicher, dass die in der Veröffentlichung enthaltenen Tickets die richtigen Tags haben.
  • Stellen Sie sicher, dass die Tickets die entsprechenden Versionshinweise haben.
  • Senden Sie die Tickets an die Teams zurück Aktualisierungen
  • JIRA-Versionen erstellen und verwalten (gemäß Prozess nur diejenigen, die auf MTS PROD und OPAP envs veröffentlicht wurden)
  • Tickets in JIRA mit der veröffentlichten Version aktualisieren (Massenauftrag)
• Definieren Sie den ersten Versionsschnitt – idealerweise führen Sie den ersten Schnitt selbst durch, um den Start des Lebenszyklus der neuen Versionsveröffentlichung auszulösen.
• Erstellen Sie die Versionshinweise für alle internen und externen Stakeholder, nachdem Sie überprüft haben, ob die Versionshinweise in jedem Ticket ordnungsgemäß festgelegt sind.
• Erstellen Sie verschiedene Listen mit Versionshinweisen für interne und externe Stakeholder, filtern Sie die irrelevanten Tickets heraus und legen Sie sie auf die richtige Vorlage wie:
  
  • Stellen Sie die vollständigen Versionshinweise für das Produkt zusammen Team- und Handelsleitung
  • Stellen Sie die Versionshinweise für unser Handelsteam zusammen.
  • Stellen Sie die Versionshinweise für Großkunden wie OPAP zusammen, die großes Interesse daran haben, dass bei jeder Veröffentlichung Tickets und Arbeiten herausgefiltert werden, die nicht damit zusammenhängen sie
  • Stellen Sie die Versionshinweise für die OpenBet-Kunden (wie NLO, Sazka, BCLC, Betfred usw.) zusammen, einschließlich der für sie relevanten Tickets.
  • Stellen Sie die Versionshinweise für IMGA-Kunden zusammen und heben Sie diese nur hervor die Änderungen in unserem offiziellen Feed, die sie betreffen
  • Stellen Sie die Versionshinweise für SportCast-Kunden zusammen und heben Sie dabei nur die Änderungen in unserem SC-Premium-Feed hervor, die sie betreffen
• Aus der relNotizen vereinfachen, erforderliche Bereitstellungsschritte und Abhängigkeiten sammeln:
  
  • Runbook mit allen manuellen Schritten und Abhängigkeiten aktualisieren
  • Stellen Sie sicher, dass alle PRs für Konfigurationen ausgeführt werden – idealerweise erhöhen Sie die PRs für ihn/sie /it/self
• Verfolgen Sie die Regressionstestphase, Fehlerbehebungen und Backports für die Version und aktualisieren Sie die Versionshinweise entsprechend.
• Geben Sie grünes Licht für die Veröffentlichung als produktionsbereit und legen Sie den Go-Live-Zeitplan nach Abstimmung mit den Hauptaktionären (POs, Trade Engineering SLT, Trading Team, GPMO) fest.
• Erstellen Sie Change-Management-Tickets, die dem Change-Management-Team alle notwendigen Informationen für die Produktionsgenehmigung bereitstellen.
• Teilen Sie das Veröffentlichungsdatum allen Beteiligten mit, indem Sie ihnen die entsprechenden endgültigen Versionshinweise zukommen lassen, einschließlich, aber nicht beschränkt auf:
  
  • Produktteams für Bereitschaftssupportvereinbarungen
  • Händler/Supportteams zur Sensibilisierung
  • Kunden über CSMs oder PMs zur Sensibilisierung
• Verwalten Sie die Veröffentlichungsausführung:
  
  • Stadienbereitstellung prüft die Genauigkeit der Bereitstellungsschritte, erwartete Ausfallzeiten oder fehlgeschlagene/fehlende Schritte, um die Produktionsbereitstellung zu proben.
  • Produktionseinsatz und Rauchtest bestanden.
  • Benachrichtigen Sie Stakeholder über den Abschluss der Veröffentlichung.
• Unterstützen Sie während des Lebenszyklus der Veröffentlichung auf UAT/Stage die Kommunikation mit Kunden zu von ihrer Seite gemeldeten Problemen.

Weitere Details zu den TS/RS-Releases:

Das OpenTrade-Produkt folgt einer 4 Sprint-PI-Planung, nach der eine Reihe von Funktionen folgen enthalten. Die Ausgabe des PI definiert die nächste Hauptversion, die in Produktionsumgebungen eingeführt wird. Abhängig vom Bedarf des Unternehmens kann eine Release-Kürzung etwas früher oder später als am Ende des letzten Sprints vorgenommen werden, da einige wichtige Funktionen nicht verfügbar sind und geschäftliche Anforderungen vorliegen.

Dennoch eine große Veröffentlichung, die etwa alle zwei Monate gekürzt wird. Zwischen diesen zwei Monaten haben wir eine weitere Nebenversion veröffentlicht, die entweder wichtige fehlende Funktionen enthält oder Vorfälle mit niedrigerer Priorität oder unkritische Änderungen gruppiert, die sich auf die Leistung und Stabilität der Plattform auswirken.

Basierend auf dem oben Gesagten ist jeden Monat eine Veröffentlichung mit einer beträchtlichen Anzahl an Tickets geplant. Aufgrund der mandantenfähigen Natur der Plattform gibt es jedoch häufig Ad-hoc-Mikroversionen mit P1/P2-Hotfixes, die so schnell wie möglich bereitgestellt werden müssen, um Probleme zu vermeiden, die zu Umsatzverlusten führen könnten. Es gab Fälle, in denen wir in einer einzigen Woche sieben Bereitstellungen durchgeführt haben. Im Durchschnitt werden 1,4 Mikrobereitstellungen pro Woche durchgeführt.

Die Produkte „Global Risk“ und „Global Tickers“ haben einen langsameren Veröffentlichungszyklus, der der PI-Taktfrequenz entspricht. Normalerweise sind dringende Bereitstellungen nur dann erforderlich, wenn ein RS-Sportwettenanbieter aktualisiert wird und die Sicherheitsschlüssel für die Verbindung mit AF geändert werden und aktualisiert werden müssen.