Bei uns kann man die Antwort auf diese Frage noch an einer Hand abzählen. Vier!

Mit Land ist in diesem Fall unsere Firma, scoyo, gemeint (ich weiß, sehr progressives Denken) und Umgebung steht für Plattformumgebung. Lernplattform-Umgebung um genau zu sein.

Momentan haben wir drei – demnächst soll eine hinzu kommen.

Was so eine Umgebung tut? Dazu muss ich etwas ausholen, aber auf den Punkt gebracht, stellt sie einen bestimmten Stand der scoyo Software zur Verfügung. Noch genauer ein bestimmtes Release.

In der Softwareentwicklung – scoyo ist in erster Linie mal ein Stück Software bzw. viele Stückchen Software, die – auf vielen Internet Servern installiert – dem Benutzer ermöglichen, damit zu lernen. In der Softwareentwicklung also, spricht man von Releases.

Ein Release ist eine Software in einem bestimmten Stadium. Oft verwendete Release Stadien sind bsp. Alpha, Beta, Release Candidate (RC), Stable/GA (general availability release), etc. Releases haben meistens Namen und/oder Nummern.

Betriebssysteme zum Beispiel: Das aktuelle Windows trägt den Namen Vista. Die Versionsnummer bzw. Buildnummer des ersten Community Technology Preview war 5308. Die des Release Candidate 2 war 5744, usw.
Das aktuelle Mac OS X heißt Leopard und hat die Version 10.5 (momentan 10.5.5). Davor gab es Tiger mit Version 10.4 und bald folgen wird Snow Leopard mit Version 10.6.

Wie dem auch sei, scoyo besteht also aus vielen verschiedenen Stücken Software und sie alle haben eine Versionsnummer. Wenn all diese Software Komponenten in einem Zustand sind, in dem sie miteinander möglichst fehlerfrei funktionieren, kann man daraus ein Release machen und diesem eine Version geben.

Diese Version wird dann deployed. Was im Grunde einfach nur ein anderer Begriff für ‘installieren’ bzw. ein toll technisch klingender Begriff für “auf die Server kopiert” ist. Na ja, etwas mehr als Dateien kopieren gehört zu einem Deployment schon noch dazu, aber für den Moment soll uns diese Information reichen.

Den Weg vom Sourcecode zum fertigen Release habe ich hier mal in vereinfachter Form aufgekritzelt:

Nun ist ein bestimmtes Release der scoyo Lernplattform deployt und Lerner können auf www.scoyo.de gehen, sich einloggen und lernen.

Was aber wenn unsere Entwickler ein neues Release haben, das sie testen möchten. Auf der Plattform wird ja inzwischen gelernt und unsere Benutzer tummeln sich darauf, haben vielleicht schon eigene Bilder hochgeladen oder Bekannte in ihre Freundesliste aufgenommen. Das alles können wir ja nicht einfach löschen, um ein neues Release einzuspielen, oder? Und evtl. wäre es ja auch gut, die neue Version zu testen, bevor man sie auf die Umgebung einspielt, auf der unsere Benutzer gerade am Lernen sind.

Genau deshalb gibt es nicht nur diese eine produktive Plattformumgebung (bei uns Live Plattform oder kurz liv genannt) sondern auch noch eine Entwicklungsplattform (Development oder kurz dev genannt). Auf dieser haben unsere Entwickler die Möglichkeit, das System zu entwickeln und zu testen, ohne die Lerner zu stören oder evtl. durch Softwarefehler Daten zu zerstören.

Doch nicht alle Softwarekomponenten der Lernplattform werden immer zur gleichen Zeit fertig. D.h. auf der Entwicklungsplattform kann es schon mal vorkommen, dass die Version der Suchmaschine nicht kompatibel zu der Version des Content Management System, oder die Benutzerverwaltung gerade in einem nicht funktionalen Zustand ist. Und überhaupt, wie soll man auf der Entwicklungsumgebung die gesamte Plattform testen, wenn permanent an den Komponenten entwickelt wird und es nicht zwingend einen konsistenten Versionsstand gibt?

Hier kommt die Integrations- oder auch Staging-Umgebung (kurz stg) ins Spiel. Auf ihr ist eine relativ aktuelle Version der scoyo Software installiert. Doch viel wichtiger, sie befindet sich in einem Zustand, der Integrationstests erlaubt. Sprich, die auf ihr installierten Plattformkomponenten sind zueinander kompatibel. So kann man auf ihr prima neue Features testen, ohne die Lerner auf der Live Umgebung zu stören, hat aber dennoch eine funktionierende Umgebung, auf der nicht ständig ein System ausfällt, weil jemand an ihm rumschraubt.

An diesem Punkt haben wir also eine Plattformumgebung für die Entwicklung (dev), eine für die Integrationstests (stg) und eine für die produktiven Benutzer (liv). Letzteres ist auch die Plattform, die unter scoyo.de im Internet erreichbar ist. Alle anderen Plattformen sind nur innerhalb des Firmennetzwerks sichtbar.

Drei Mal die gleiche Plattform, nur in unterschiedlichen Versionen. Das sollte doch eigentlich ausreichen! Immerhin besteht jede einzelne Umgebung aus mindestens 97 Linux Servern. Die Live Plattform sogar aus 157 Servern. Gut, zum Glück alles nur virtuelle, von denen jeweils 10-20 auf einem physikalischen Server laufen. Nichts desto trotz eine Menge Holz… nur für so eine Lernplattform.

Was wir bei all diesen Plattformen jetzt aber noch nicht zuverlässig testen können sind Probleme die evtl. auf der Liveplattform auftreten und die man in einer isolierten Umgebung untersuchen und durch Hotfixes beheben möchte. Außerdem fehlt noch eine Umgebung für die Endabnahme unseres Content. Also die Lernmodule, die unserer Plattform erst die Würze geben.

All die feine Software bringt ja nichts, wenn auf ihr kein Content läuft. Und dieser will schließlich auch noch ein letztes Mal getestet werden, bevor man ihn auf die Benutzer loslässt.

Man kann sich ein Lernmodul für unsere Lernplattform ein bisschen vorstellen wie einen Film für einen Mediaplayer. Der Mediaplayer ist für sich alleine schon ein tolles Stück Software. Aber wenn darin keine Musik oder Filme laufen, bleibt er ein relativ langweiliges Stück Software.

Nicht jeder Mediaplayer kann jedes Filmformat abspielen. Ähnlich gestaltet sich die Sache auch bei der scoyo Plattform. Ein Lernmodul benutzt Funktionen der Plattform und stellt ihr wiederum Funktionalitäten zur Verfügung, ist also noch ein wenig komplizierter als eine Filmdatei. Doch nicht jede Version eines Lernmoduls ist  zu jeder Version der Lernplattform kompatibel. Ein Lernmodul ist nämlich auch ein Stück Software und es muss kompatibel sein zu der Software, mit der es interagieren soll, also der Plattform.

Aber was soll das ganze Theater? Um zu testen, ob ein Lernmodul auf der Live Umgebung funktioniert, müsste man es doch nur dort einspielen und testen. Na gut, vielleicht möchte man ja nicht, dass die noch ungetesteten Lernmodule für unsere Benutzer sofort sichtbar werden. Solange es sich um neue Lernmodule handelt, könnte man sicherlich so etwas einbauen wie “dieses Modul ist nicht für alle Benutzer sichtbar” und damit selektiv einzelne Lernmodule freigeben. Doch was ist, wenn es sich einfach nur um eine neue Version eines bestehenden Lernmoduls handelt. Wir können ja nicht blind die bestehende Version durch die Neue ersetzen, ohne diese vorher getestet zu haben. Schon bei diesem einfachen Szenario käme es zu Problemen. 

Die Live Plattform eignet sich also nicht so gut, um neue Lernmodule auf ihr auszuprobieren. Die Stage Plattform auf der anderen Seite hat wahrscheinlich einen viel zu neuen Versionsstand, der mit dem der Live Plattform nicht überein stimmt. D.h. wenn wir ein Lernmodul nur auf Stage testen würden, könnte es passieren, dass es zwar auf dem Stage System funktioniert, auf dem Live System aber nicht, weil dort bestimmte neue Funktionen, die das Lernmodul evtl. schon verwendet, noch gar nicht vorhanden sind.

Darüber hinaus gibt es ja auch noch Upgrade Scripte, die mit den Paketen beim Deployment installiert werden. Diese aktuallisieren bsp. das Datenbank Schema, also die Datenbank Strukturen, oder organisieren Daten neu. Bevor man so etwas auf die produktive Umgebung deployt, will man sich schon sehr sicher sein, dass auch wirklich alles sauber durch läuft.

So entsteht der Bedarf für eine vierte Plattformumgebung. Eine, die den gleichen Versionsstand wie das Live System hat. Auf der man aber rumspielen und testen kann, ohne dass unsere Lerner davon beeinträchtigt werden oder etwas davon mitbekommen. Diese vierte Plattform kann auch sonst für viele nützliche Sachen herhalten. Beispielsweise kann man auf ihr Lastsimulationen (Benchmarks) und Security Scans  (simulierte Angriffe) testen, die evtl. einzelne Plattformkomponenten zum Absturz bringen. So etwas möchte man auf der Live Plattform nicht unbedingt tun, ohne es vorher woanders getestet zu haben.

Diese vierte Umgebung nennen wir Pre-Live oder kurz pre. Sie dient dazu, unsere Tests realitätsnäher ablaufen zu lassen und so das Risiko einer Fehlfunktion beim Einspielen unserer Plattformkomponenten und Lernmodule in die Live Umgebung weiter zu minimieren.

Das sind sie also, unsere vier Umgebungen. dev, stg, pre und liv. Auf jeder von ihnen läuft scoyo in einem bestimmten Entwicklungsstadium.

Tags: Lernplattform, Releases, Umgebungen

Der Beitrag wurde am Donnerstag, den 02. Oktober 2008 um 17:37 Uhr veröffentlicht und wurde unter Allgemein, Produkt abgelegt. Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.