Erstellen einer DB für Atlassian

Erstmal Willkommen und viel Erfolg beim FISI werden

Hier einmal MS SQL als Videoreihe: https://www.youtube.com/playlist?list=PLcnT0JqQtWqOJsQE_ox3RdbZDuLUpLE7j
Alternativ frag mal bei deiner Berufsschule nach ob die LinkedIn Learning Abos haben, gibt da gite Sachen.
Weiterer hilfreicher Link wäre die Supportseite von Atlassian https://confluence.atlassian.com/search/?query=MS%20SQL dort steht auch einiges zu MS SQL ;)

Kleine Tipps für die Zukunft, gerade für eine Testumgebung für ein neues System würde ich auch aktuelle Software nehmen, wie Windows Server 2019. Windows Server 2012 bekommt seit über einem Jahr keine grundlegenden Support mehr und der erweiterte ist in zwei Jahren fertig. Und Mitarbeiter reagieren ganz allergisch auf Änderungen im Aussehen von Software, also lieber gleich was aktuelles zum Testen bereitstellen. Damit tust du dir selbst auch einen riesen Gefallen und sparst dir Diskussionen ala "...das war früher aber alles ganz anders..".
Gerade als Consultant stößt du immer wieder auf einen "ist Zustand" der zu einem "soll Zustand" werden soll. Dabei steht und fällt jedes Projekt mit sauberer Dokumentation. In dem jetzigen Fall wäre für uns z.B. auch wichtig welchen MS SQL Server du nutzt und welches Produkt von Atlassian du überhaupt nitzen willst. Lieber zu viel als zu wenig Infos

Soltest Du noch Hilfe oder Unterstützung brauchen, kannst du mir auch gerne eine PN schreiben.

Du brauchst erst mal eine Datenbank-Instanz auf dem DB-Server. Dafür gibt es in Unternehmensumgebungen drei Möglichkeiten:

1. Du bist Admin des DB-Server bzw. hast den Admin-Zugang bekommen, dann kannst du das selbst erledigen
2. Ihr habt eigene DB-Admins, die dir auf Anfrage eine einrichten
3. Es gibt noch gar keinen (passenden) DB-Server, sodass du selbst was aufsetzen musst

#2 ist meist in mittel- bis großen Unternehmen der Fall, #1 und #3 tendenziell eher in kleineren. Aber das variiert natürlich immer je nach Organisationsform, daher kann dir das hier keiner sagen sondern du musst konkret bei dir erfragen, wie vorzugehen ist, wenn du eine DB brauchst.

Wichtig wäre: Wenn du Admin-Zugang auf einen zentralen DB-Server bekommst, auf dem auch andere DB liegen, solltest du entsprechende Vorsicht walten lassen. Im besten Falle gibt es dafür Testumgebungen bzw. du setzt eine auf.

Einen Windows-Server würde ich dafür aber nicht nehmen wollen, schon gar nicht so einen alten. Die Erfahrung hat mein Vorgänger auch machen dürfen, der anschließend mittels Consultant unsere ganzen Atlassian-Anwendungen auf Linux migrieren durfte Eine Klatsche habe ich auch noch abbekommen, als ich frisch ausgelernt Bamboo über die Mittagspause updaten wollte, und dank inkonsistenter DB aus einem geplanten 30Min Update 3h wurden...

Hab das auch nicht mehr direkt unter Linux am Laufen sondern in Docker-Containern. Gerade für die Testsysteme ist das sehr praktisch: Paar Config-Einträge, Ansible drüber laufen lassen und ein paar Minuten später hab ich eine Testinstanz auf der von mir festgelegten Version. Auf Wunsch auch direkt mit einem Dump der produktiven DB, die automatisiert entsprechend angepasst wird (Basis-URL ändern, Konnektoren, Benachrichtigungsmails ausschalten etc). Da die Datenbanken auf PostgreSQL laufen, ist das kein Thema und sogar recht schnell.

Das nutze ich zum einen selbst, um Updates gefahrlos in einer Umgebung testen zu können, die 1:1 wie die produktive aufgebaut ist. Zum anderen erstelle ich damit unseren Admins (nicht Sysadmins) ab und an Testinstanzen, auf denen sie autonom irgendwas ausprobieren können. Ohne dass es zu Konflikten mit anderen kommt bzw. die Daten veraltet sind. Das war bei meinem Vorgänger ein großes Problem, dass die Addons wie z.B. Portfolio testen wollten, aber dafür aktuelle Testdaten benötigen. Damals gab es ein globales Testsystem für alle. Dieses wurde aber nicht regelmäßig aktualisiert, weil das Händisch gemacht werden musste - heißt mindestens 1h Arbeit und natürlich die hohe Fehleranfälligkeit, etwas zu vergessen.

Gerade als Consultant würde ich mir Infrastructure-as-Code, Docker und die umliegenden Themen (nächste Stufe wäre z.B. Kubernetes) unabhängig davon anschauen. Containerisierung gehört die Zukunft. Das klassische "Ich installiere mir ein riesiges OS um darauf einen Applikationsserver zu installieren, am besten noch alles via GUI und von Hand durchklicken" wird mehr und mehr zur Legacy. Es gibt noch einige Anwendungsfälle, wo das teilweise Sinn macht, wie z.B. sehr große, leistungsintensive Applikationen. Bei einem ELK beispielsweise würde ich mit entsprechender Last darüber nachdenken, den auf einem dedizierten Server zu betreiben. Kann man natürlich auch in Kubernetes laufen lassen, aber ein dedizierter Server macht da bei weitem mehr Sinn wie für irgendwelche 0815 Anwendungen.