Um mit mehreren Entwicklern an immer weiter wachsenden Softwareprojekten effizient arbeiten zu können, muss vorher eine gemeinsame Arbeitsweise gefunden werden. Dafür müssen mehrere Fragen gemeinsam beantwortet werden.

  • Wie versionieren wir?
  • Wie entwickeln wir Features?
  • Wie testen wir und wie werden Bugs behandelt?

Diesen ganzen Fragen wollen wir uns in diesem Blog Post widmen und somit einen kleinen Einblick in den Entwicklungsalltag bei Minecraft Legend bieten.

Wie versionieren wir?

Wir haben uns darauf geeinigt, Git als Version-Control System (VCS) im Zusammenhang mit Github zu nutzen. Git ist momentan das bei weitem am häufigsten genutzte VCS.

Im Zusammenhang mit Git wird sehr oft die Plattform GitHub erwähnt. GitHub ist eine kostenlose Plattform für Entwickler, auf der diese ihre Git Repositories verwalten können. Deshalb wird sie sehr gerne von OpenSource Entwicklern genutzt. Jedoch stellt GitHub auch für private Organisationen gute Möglichkeiten zur Verfügung, Repositories sowohl öffentlich als auch privat zu verwalten.

Aktuell sind zwei unserer Projekte OpenSource und es werden hoffentlich weitere Projekte folgen.

Zusätzlich ist im letzten Jahr eine Möglichkeit hinzugekommen, Projekte automatisch via GitHub Actions bauen zu lassen. Dies hat die Plattform noch attraktiver gemacht.

Eins der Hauptargumente für die Nutzung von GitHub war jedoch, dass wir unsere Repositories so nicht selbst, mit zum Beispiel GitLab, hosten und eine hohe Uptime garantieren müssen.

Git Workflow

Git Workflow
Git Worflow

Unser Git Workflow besteht aus einer leicht abgewandelten Version von Gitflow. Ein Git Repository hat bei uns mindestens drei Branches, die unsere verschiedenen Systeme widerspiegeln.

  • prod: Der Source Code in diesem Branch repräsentiert, unsere produktiven Systemen.
  • stage: Einmal in der Woche werden die entwickelten Features aus dem dev-Branch in diesen Branch gemerged. Dieser Stand wird anschließend vom Gamedesign getestet.
  • dev: Source Code in diesem Branch ist unter dauernder Veränderung, da unsere Entwickler alle neuen Features von Zeit zu Zeit in diesen Branch mergen.

Zusätzlich gibt es noch zwei weitere Arten von Branches, die beide einen gesonderten Zweck erfüllen. Das sind unsere bugfix & feature Branches. In diesen werden neue Features entwickelt und Bugs gefixt. Nach dem diese grob auf unserem Dev-System getestet wurden, werden sie in den dev-Branch gemergt.

Wie entwickeln wir Features?

Die Entwicklung von Gameinhalten

Neue Inhalte werden von unserem Gamedesignern ausgearbeitet und im Confluence dokumentiert. Confluence ist eine Enterprise Wiki Software, mit der es sehr einfach ist, mit mehreren Personen an Dokumenten zu arbeiten. Bei jeder neuen Funktion legt die Entwicklungsleitung zusammen mit dem Gamedesign eine Priorisierung des Inhalt fest und trägt diese auf die interne Roadmap ein. Je nach Priorisierung auf der Roadmap werden die Features nach und nach entwickelt.

Bei Beginn der Entwicklung eines neuen Features setzt sich meist das gesamte Entwicklerteam zusammen und erarbeitet passende Konzepte, um den Gameinhalt schnell und performant im Spiel umzusetzen. Anschließend setzen ein bis zwei Entwickler den Inhalt um.

Auch während der Entwicklung wird ausgiebig getestet. Um schnell und dynamisch Testserver bereitstellen zu können, benutzen wir Pterodactyl. Pterodactyl bietet ein eigenes Webinterface, auf dem der Entwickler selber Configs verändern, Plugins hochladen und vieles mehr einstellen kann. Außerdem stellen wir die Möglichkeit bereit, sich per VPN an den Java Debugger anzuhängen, um sein jeweiliges Feature vernünftig testen zu können. Selbst auf dem Testsystem ist unsere gesamte benötigte Infrastruktur in kleinen widergespiegelt, um nahezu identische System zu bieten.

Wie testen wir und wie werden Bugs behandelt?

Stage System

Nachdem neue Inhalte fertig entwickelt wurden, werden diese, wie oben beschrieben, in unseren dev-Branch gemergt. Mindestens einmal pro Woche werden diese auf das Stage System übertragen. Auf dem Stage System testen vor allem Gamedesigner, aber auch weitere Teammitglieder, ausgiebig die neuen Funktionen und geben den Entwickler Feedback und reporten Bugs.

Das Stage System entspricht zu 100% unserer produktiven Umgebung. Die Systemlandschaft unserer Stage-Umgebung ist auf der folgenden Zeichnung sehr minimiert dargestellt. Viele Systeme und Komponenten der Visualisierung werden in zukünftigen Blogposts genauer beschrieben.

Systemlandschaft

Folgende Blog Posts

In den nächsten Monaten werden noch weitere Blogposts folgen, in denen unsere Infrastruktur an sich und einige Konzepte vorgestellt werden.

Grobe Aufteilung der nächsten Blogposts:

  • HashiCorp Stack (Nomad, Vault und Consul)
  • Multibungee Probleme und Lösungsmöglichkeiten
  • Echtzeitdatenverarbeitung in Minecraft
  • Minecraft mit JUnit