Beiträge

Solaris ist ein Betriebssystem auf Basis von SunOS und einem Unix-Betriebssystem, das für Benutzerfreundlichkeit, Sicherheit und Kompatibilität steht. Das Unternehmen Oracle hat sich mehr als 20 Jahre mit dem Entwickeln der Geschäftsplattform beschäftigt und Funktionen integriert, die dem neuesten Stand der Marktentwicklung entsprechen. Die Abwärtskompatibilität ist dabei beibehalten worden. Frühere und aktuelle Anwendungen werden durch die binäre Anwendungssicherheit in einer fortschrittlichen Infrastruktur ausgeführt. Solaris gehört seit der Übernahme von Sun Microsystems im Jahr 2010 zu dem Unternehmen Oracle. Doch was ist eigentlich ein Betriebssystem und wie arbeitet ein Webserver?

Betriebssystem

Ein Betriebssystem trägt auch den Namen OS und das stammt aus der englischen Bezeichnung operating system. Das System sorgt für den Zugang auf die Hardware-Ressourcen des PC, wie beispielsweise auf Drucker, USB-Ports, Arbeitsspeicher und Festplatten. Neben dem Computer brauchen auch Smartphones, Tablets und andere PCs ein Betriebssystem. Die bekanntesten Betriebssysteme sind Android, Unix, Linux, Mac OS, Windows und iOS.

Das Betriebssystem kontrolliert und leitet die Hardware (=Komponenten des PCs). Dazu zählen auch folgende Geräte: DVD-Laufwerk, Drucker, Maus, Tastatur und anderweitige Schnittstellen, wie zum Beispiel USB-Ports. Dem Grunde nach wäre eine Anwendungssoftware, wie beispielsweise MS Word, in der Lage, diese Aufgaben eigenständig zu bewerkstelligen. In diesem Fall müsste jedoch das Programm spezielle MS-Word-Versionen für die unterschiedlichen Hardwareausstattungen des PCs bereithalten. Ein Betriebssystem reduziert den verwaltungsrelevanten Aufwand für die Anwendungsprogramme. Des Weiteren besteht eine einheitliche Oberfläche, die es ermöglicht, dass eine Software von anderen Anbietern ansetzen kann.

Was ist ein Webserver?

Ein Webserver ist eine Software oder auch eine Hardware. Die Hardware ist für das Ausführen der Software vorgesehen und kann Inhalte für das Internet bereitstellen. Der Webserver bearbeitet die eintreffende Netzwerkanforderung über HTTP sowie weitere verwandte Protokolle. Eine Interaktion mit dem Webserver erfolgt immer dann, wenn man das World Wide Web nutzt, um Mails einzusehen, um auf eine Website zu kommen sowie um eine Verbindung zu sozialen Netzwerken herzustellen. Der Server ist dafür zuständig, alle Anfragen an eine Internetadresse zu beantworten.

Die wichtigste Funktion des Webservers ist das Speichern sowie Verarbeiten der Internetseiten und das Liefern an Clients. Die Verständigung zwischen Server und Client läuft über das Hypertext Transfer Protocol (HTTP). Internetseiten sind in der Regel HTML-Dokumente, die aus Textinhalten, Stylesheets, Skripts und Bildern bestehen können. Wenn die Website stark genutzt wird, dann kommen häufig mehrere Webserver zum Einsatz.

Details zu Solaris

Die Kompatibilität zur System-V-Familie besteht seit 1990. Alle Versionen davor wurden unter der Bezeichnung Unix xx Sun Version yy bereitgestellt. Die Benennung SunOS fand Anfang 1986 mit der ersten öffentlichen SunOS-3.0 Beta eine erstmalige Verwendung. Diese Version wurde auf der Grundlage von BSD-Unix für die Anwendung auf Workstations und Servern von Sun hervorgebracht. Der Name Solaris entstand, als die Version 5.0 von SunOS auf dem Ursprung von UNIX System V entwickelt wurde.

Funktionen und Besonderheiten von Solaris

Seit der Ausführung von Solaris 7 besteht eine durchgängige 64-Bit-Unterstützung auf UltraSPARC-CPUs. 1991 erfolgte die Ankündigung der Solaris-Portierung für x86, welche im Jahr 1992 an den Start ging. Die x86er-Prozessor-Version ist seit 1992 nutzbar. Diese Version bootet seit 2004 auch auf AMD64. Das ermöglichte in der Version 10 eine 64-Bit-Unterstützung für Intel-64-CPUs oder AMD64-CPUs. Die Version von Solaris für PowerPC wurde nach der ersten Version (Solaris 2.5.1) wieder stillgelegt. Eine neue Übertragung begann nach Herausgabe von OpenSolaris unter der Bezeichnung Polaris.

Seit 2005 besteht das OpenSolaris-Projekt unter der Führung von Sun. Das Projekt stellt den Solaris-Quellcode unter der Distribution License und der Common Development der Allgemeinheit zur Verfügung. Im Juni 2005 fand die Freigabe des Open-Source-Betriebssystems statt. Das erfolgte unter dem Namen OpenSolaris und beinhaltete Quellen für Kernel, Bibliotheken und einzelne Module. Im Zuge dessen sollte auch ein Solaris-Release für PowerPC starten. Zu Beginn des Jahres 2006 wurde von den Systementwicklern eine Übernahme auf die Pegasos-basierte CHRP-Workstation ODW von IBM/Freescale/Genesi bekanntgegeben, aber es ist nie ein Release daraus hervorgegangen.

Solaris und die Software

Die Verwaltung der Solaris-Software basiert vordergründig auf eine Paketverwaltung mithilfe der pkg-Programme (=pkgchk, pkgadd, pkgrm etc.). Es ist möglich, zahlreiche Programme auf Solaris zu portieren, welche auf Unix- und verwandten Betriebssystemen laufen. Das macht es realisierbar, tausende zusätzliche Software-Pakete für Solaris bereitzustellen. Die Softwarepakete können beispielsweise durch das OpenCSW-Projekt mit dem Programm pkgutil eingespielt werden. Durch  Weiterentwicklung der Solaris Observability-Tools können Anwendungs- und Systemfehler in Echtzeit behoben werden. Das ermöglicht einen Verlaufs- und Echtzeiteinblick und Probleme sind einfach und zügig zu erkennen und zu lösen.

Der Begriff Continuous Delivery (CD) ist englischen Ursprungs und bedeutet in die deutsche Sprache übersetzt so viel wie „fortwährende Lieferung“. Bei Continuous Delivery handelt es sich um ein Konzept aus dem Bereich der Softwareentwicklung, das sich in den letzten Jahren einer enormen Beliebtheit erfreut. Im folgenden Artikel gehen wir auf das Thema Continuous Delivery im Detail ein und beleuchten die speziellen Eigenschaften sowie die Vor- und Nachteile dieser innovativen Methode von allen Seiten.

Definition

Bei Continuous Delivery handelt es sich um ein Modell, das in der modernen Softwareentwicklung in Kombination mit DevOps immer beliebter wird und sich allmählich als Standard in der Softwarebranche etabliert. CD wird in der Softwareentwicklung eingesetzt, um Entwicklung, Bereitstellung, Feedback und Qualitätsmanagement in regelmäßigen kurzen Abständen ununterbrochen und parallel laufen zu lassen. Durch den Einsatz moderner CD-Methoden wird der gesamte Prozess der Entwicklung positiv beeinflusst und viel effizienter umgesetzt. So bekommt der Kunde beispielsweise das Produkt früher ausgeliefert, obwohl dieses noch nicht ganz fertig ist. Entwickler werden im Rahmen von Continuous Delivery kontinuierlich mit Feedback durch flächendeckende Tests versorgt, die nach jeder Änderung am Quellcode automatisch durchgeführt werden. CD beschreibt also einen dynamischen Prozess, der sämtliche Prozesse der Softwareentwicklung miteinander vereint und automatisiert. Dadurch lassen sich aufwendige und schwerfällige Arbeitsschritte minimieren. Continuous Delivery kommt in vielen bekannten Unternehmen zum Einsatz, wie beispielsweise Microsoft, Google und Red Hat.

Prinzipien und Praktiken der Continuous Delivery

Im Rahmen traditioneller Vorgehensweisen in der Softwareentwicklung wird das Endprodukt erst dann dem Kunden übergeben, wenn alle notwendigen Funktionen und Features implementiert sind, es ohne Probleme läuft und im Rahmen der Qualitätssicherung keine größeren Mängel gefunden wurden. Das Softwareprodukt wird dann anschließend von dem Entwickler mit regelmäßigen Patches und Aktualisierungen versorgt. Entwicklerteams, die auf moderne CD-Prozesse setzen, können die Software in einem viel früheren Entwicklungsstadium an den Kunden ausliefern, während das Produkt noch aktiv weiterentwickelt wird. Die ersten Versionen des Softwareprodukts enthalten in der Regel nur die Kernfunktionalitäten, die der Kunde in realer Umgebung testen kann. Der Kunde selbst nimmt keinen relevanten Platz im Rahmen der Qualitätssicherung ein.

Die auf diese Weise gewonnene Resonanz hilft dem Entwicklerteam, noch während der Entwicklungsphase vorhandene Funktionalitäten zu optimieren. Außerdem bekommt das zuständige Team wichtige Hinweise darüber, welche Funktionalität als nächstes implementiert werden sollte. Ohne Continuous Delivery sind diese einzelnen Schritte äußerst schwer zu implementieren und können sehr schnell zu Frust auf beiden Seiten führen. Der Kunde erwartet schließlich ein fertiges und funktionales Softwareprodukt, das seinen individuellen Wünschen und Anforderungen entspricht. Das Entwicklerteam weiß jedoch bis dahin überhaupt nicht, welche Anforderungen das überhaupt sind. Wenn die Kommunikation über den gesamten Entwicklungsprozess stattfindet, dann können Wünsche des Kunden viel schneller und präziser berücksichtigt und Unklarheiten vermieden werden.

Welche Vorteile bietet Continuous Delivery?

Continuous Delivery bringt mit anderen Methoden der modernen Softwareentwicklung, wie beispielsweise Continuous Integration und Continuos Deployment eine Vielzahl verschiedener Vorteile.

Automatisierung von Software-Einführungsprozessen: Durch den Einsatz der Continuous Delivery können Entwicklerteams Änderungen an der Codebasis automatisch erstellen und testen lassen sowie für die Produktionseinführung vorbereiten. Dadurch wird der Prozess der Software-Bereitstellung wesentlich schneller und effizienter gestaltet.

Steigerung der Entwicklerproduktivität: CI-Prinzipien und Praktiken steigern die Produktivität der Entwicklerteams, da sich Entwickler nicht mehr um manuelle Aufgaben kümmern müssen. Sie können sich stattdessen voll und ganz auf die Entwicklung, Bereitstellung und Optimierung des Produktes konzentrieren.

Bugs werden schneller entdeckt und behoben: Entwicklerteams sind in der Lage, Fehler (Bugs) im Softwareprodukt zu entdecken und zu beheben, noch bevor sie sich zu größeren Problemen entwickeln. Die Beseitigung von Bugs nimmt später nicht selten viel Zeit und Arbeitsstunden in Anspruch. Da der gesamte Entwicklungsprozess im Rahmen der Continuous Delivery automatisiert ist, können zusätzliche Tests der Codebasis schnell und einfach durchgeführt werden.

Schnellere Bereitstellung von Patches und Updates: Dank der CI-Praktiken können Entwicklerteams Updates und Patches für Kunden viel regelmäßiger und schneller bereitstellen.

Continuous Delivery Phasen

Bei jeder Änderung an der Codebasis wird die sogenannte „Continuous Delivery Pipeline“ gestartet und der Testprozess ausgeführt. Die Continuous Delivery Pipeline setzt sich dabei aus folgenden Phasen zusammen:

  1. Commit Stage: Die Commit Stage ist die erste Testphase. Hier werden die Software-Versionen validiert, die benötigten Software-Komponenten gebaut und notwendige Unit-Tests realisiert. Nachdem die Tests erfolgreich durchgeführt wurden, ist diese Phase abgeschlossen.
  2. Acceptance Test Stage: In der zweiten Testphase werden Akzeptanztests durchgeführt. Akzeptanztests setzen sich aus Systemtests (Wie gut funktioniert das Softwareprodukt auf der Seite des Nutzers) und Integrationstests (Wie ist das Zusammenspiel der einzelnen Softwarekomponenten) zusammen.
  3. Feedback und Fehlerbehebung: In dieser Phase werden auftretende Fehler protokolliert und als Feedback an das zuständige Entwicklerteam geschickt. Das kann beispielsweise über Messaging-Programme, E-Mail oder dedizierte Tools realisiert werden.
  4. Manuelle Prüfung: Je nach Bedarf werden in dieser Phase manuelle Tests realisiert.
  5. Installation auf dem Zielsystem: Sollten alle Tests mit positivem Feedback abgeschlossen sein, dann wird in dem letzten Schritt das Softwareprodukt auf dem Zielsystem manuell installiert. Um dies zu erledigen sind meist nur wenige Mausklicks notwendig. Wenn auch diese Phase automatisiert ist, dann spricht man von Continuous Deployment.

Softwareprodukte werden heutzutage in der Regel in Teams entwickelt, die ihre Arbeitsergebnisse in einer zentralen Build-Umgebung zu einer Einheit zusammenführen müssen. Der Continuous Integration-Ansatz (CI) sorgt dafür, dass neue Softwarekomponenten sofort flächendeckenden Tests unterzogen und danach zusammengeführt werden. Anstatt dies beispielsweise nur einmal täglich zu machen, werden im Rahmen des CI-Ansatzes neue Software-Builds erstellt, sobald eine Komponente für die Integration zugelassen wurde.

Softwareentwicklung und Kompilierung: ein Blick in die Vergangenheit

Eine Softwareanwendung setzt sich in der Regel aus einer Vielzahl einzelner Module zusammen. Dementsprechend ist die Vorgehensweise bei der Softwareentwicklung an diese speziellen Gegebenheiten angepasst, sodass das Gesamtprojekt häufig analog zu diesen Modulen von mehreren einzelnen Teams parallel entwickelt wird. Früher wurden Änderungen und Erweiterungen an dem Softwareprodukt in vielen Fällen in Form eines „Tagewerks“ realisiert. Konkret bedeutet das, dass die Zusammenführung der Änderungen, die von den isolierten Entwicklerteams innerhalb eines Arbeitstages erschaffen wurden, nur einmal täglich im Rahmen einer Kompilierung auf dem zentralen Build-Server konsolidiert wurden.

Erst danach wurden die neuen Funktionen und Features des Softwareprodukts im Kontext der erweiterten Codebasis getestet. Dieser traditionelle Ansatz der Softwareentwicklung birgt enorme Gefahren und Risiken. Falls ein neu geschaffener Code nicht kontinuierlich integriert und flächendeckenden Tests unterzogen wird, werden eventuelle Fehler im Code zu spät erkannt. Die Folgen sind zeitintensive und kostspielige Rückkopplungsprozesse. Vor der Einführung der Continuous Integration mussten einzelne Teams auf die Fertigstellung anderer benötigter Softwarekomponenten anderer Entwicklerteams warten, was sich auf die Effizienz des gesamten Projekts äußerst negativ auswirkt.

Continuous Integration im Überblick

Die Continuous Integration-Methoden, die in innovativen Unternehmen in Kombination mit DevOps zum Einsatz kommen, beziehen sich auf die kontinuierliche Integration einzelner Softwarekomponenten in die Gesamtcode-Basis (Codebase) des Softwareprojekts. Die wesentlichen Vorteile dieser Arbeitsweise spiegeln sich in den überschaubaren Schritten wider, die einen kontinuierlichen Arbeitsfluss fördern und die Möglichkeit bieten, Fehler in der Programmierung frühzeitig zu erkennen und zu beseitigen. Durch die gesteigerte Arbeitseffizienz ergibt sich eine höhere Softwarequalität. Die Arbeitsweise im Rahmen des Continuous Integration-Ansatzes unterscheiden sich stark, von der im obigen Absatz beschriebenen traditionellen Vorgehensweise. In Unternehmen, bei denen die kontinuierliche Integration zum Einsatz kommt, wird eine hohe Flexibilität gefordert.

Konkret bedeutet das, dass die in den kleineren Schritten vorgenommenen Änderungen oder Erweiterungen an dem Softwareprodukt in regelmäßigen Abständen zusammengeführt und getestet werden. Die Einspeisung wird über ein Versionsverwaltungssystem wie beispielsweise GitHub oder Bitbucket in einem unterteilten Code-Repository realisiert. Auf diesem Wege lassen sich Versionskontrollen durchführen, indem Build-Prozesse automatisiert werden, sodass stets die aktuelle Code-Version aus dem Repository übernommen wird.

Vor- und Nachteile von Continuous Integration

Obwohl der Continuous Integration-Ansatz zahlreiche Vorteile mit sich bringt, zeigt sich im Alltag auch, dass CI nicht nur Vorteile hat. Dass die langwierige Integrationsphase am Ende eines Softwareprojekts abgekürzt werden kann, lässt sich nicht beschreiten. Auftauchende Probleme können frühzeitig beseitigt werden. Für eingespielte Teams ist die Umstellung auf Continuous Integration jedoch oft mit Komplikationen verbunden. Anstatt dann effizienter zu arbeiten, kann das Verfahren sogar mehr Zeit in Anspruch nehmen.

Vorteile:

– kontinuierliches Feedback

– Fehler lassen sich frühzeitig identifizieren

– eine granulare Arbeitsweise wird gefördert

aktuelle und funktionsfähige Versionen sind stets verfügbar

– alle Änderungen werden im Detail protokolliert

Nachteile:

– es müssen flächendeckende Test-Abläufe entwickelt und implementiert werden

– Umstellung von einem gewohnten Arbeitsprozess

– es werden zusätzliche Server und Entwicklungsumgebungen benötigt

Welche Tools kommen bei Continuous Integration zum Einsatz?

Der Continuous Integration-Ansatz lässt sich grundsätzlich ohne spezielle Tools umsetzen. Das ist jedoch oft mit viel Aufwand verbunden und erfordert einiges an Disziplin. Aus diesem Grund ist es viel einfacher, sich die Arbeit mit den richtigen Tools zu erleichtern. Diese helfen meist bei der Versionskontrolle und beim Kompilieren und Erstellen von Builds. Die bekanntesten CI-Werkzeuge sind:

Jenkins: Hierbei handelt es sich um ein bekanntes Java-Programm, das im Rahmen moderner Continuous Integration und Continuous Delivery-Prozesse eingesetzt wird.

Travis CI: Dieses Tools ist insbesondere wegen seiner reibungslosen Integration mit GitHub beliebt. Für Open Source-Projekte ist es kostenlos, für kommerzielle Softwareprojekte muss eine offizielle Lizenz gekauft werden.

Bamboo: Auch hier handelt es sich um ein Tool, das in der Programmiersprache Java erstellt ist. Wie Travis CI ist es für kommerzielle Projekte normalerweise kostenpflichtig, während es für Open Source-Projekte kostenlos genutzt werden kann.

CodeShip: Dieses Tool basiert auf der Container-Technologie, die von IT-Größen wie Google, Microsoft und Red Hat aktiv weiterentwickelt wird und aus der modernen Softwareentwicklung nicht mehr wegzudenken ist.

Einsatzgebiete

Continuous Integration ist insbesondere im Umfeld agiler Softwareentwicklung in Kombination mit DevOps sehr beliebt. Dieser moderne Ansatz hat immer zum Ziel, in kleinen, übersichtlichen Schritten zu arbeiten. Heutzutage gibt es keine Rechtfertigung, ein Softwareprojekt ohne einen Continuous Integration-Ansatz zu betreiben. Dies liegt vor allem an dem Erfahrungsschatz sowie der großen Anzahl an verfügbaren Tools. CI kann sein volles Potenzial jedoch erst dann entfalten, wenn alle Team-Mitglieder optimal in alle Prozesse eingebunden werden und das System mittragen. Aus diesem Grund kommt einer reibungslosen Kommunikation eine sehr wichtige Rolle zu.

Mit dem Begriff Continuous Deployment wird ein Entwicklungs- und Veröffentlichungs-Ansatz für Software-Produkte beschrieben, der sich mit der wachsenden Bedeutung von Webanwendungen in den letzten Jahren durchgesetzt hat. Im Rahmen des Continuous Deployment-Ansatzes werden Änderungen an dem Software-Produkt kontinuierlich veröffentlicht und Nutzern zugänglich gemacht.

Continuous Deployment, Continuous Integration und Continuous Delivery

Bei Continuous Deployment (CD) und Continuous Delivery (CI) handelt es sich um Teilbereiche, die dem Dachbegriff Continuous Integration entsprungen sind. Prinzipiell geht es bei diesen Prozessen darum, dass Software-Produkte kontinuierlich weiterentwickelt werden. Dabei liegt die Perfektionierung der entwickelten Software im Fokus aller Bemühungen, wobei jedoch auch in erster Linie auf eine kontinuierliche Auslieferung des Produkts geachtet wird. Durch den Einsatz flächendeckender automatisierter Tests während des gesamten Entwicklungsprozesses kann somit gewährleistet werden, dass sich neu zugefügte Komponenten nicht negativ auf die Lauffähigkeit und Performance des Software-Produkts auswirken und dass sich keine Fehler unbemerkt in das System einschleichen. Nichtsdestotrotz bleibt Continuous Integration ein kontroverses Thema, das sowohl zahlreiche Vorteile als auch einige Nachteile mit sich bringt.

Die Grundlagen im Überblick

Continuous Delivery verspricht prinzipiell eine bessere Qualität des entwickelten Software-Produkts. Somit rückt das altbekannte Phasenmodell, das in der Softwareentwicklung bereits seit Jahrzehnten erfolgreich eingesetzt wird, in den Hintergrund. Alle neu entwickelten Komponenten und Änderungen am System werden im Rahmen des CI/CD-Ansatzes in Kombination mit modernen DevOps-Methoden umfassend getestet, ehe sie in die laufende Software integriert werden. Für Anbieter und Kunden bietet Continuous Deployment eine Vielzahl unterschiedlicher Vorteile. So kann beispielsweise das laufende Software-Produkt jederzeit durch eine bessere Version ausgetauscht und mit neuen Funktionen und Features angereichert werden, ohne dass Nutzer lange auf die Implementierung einer neuen Version warten müssen. Dies ist insbesondere für Webanwendungen von Vorteil, da der Betrieb der laufenden Software während der Aktualisierung auf eine neue Version nicht unterbrochen wird und Nutzer in der Regel davon nichts mitbekommen. Der wesentliche Nachteil des CI/CD-Ansatzes spiegelt sich in der Tatsache wider, dass sich tiefgreifende Änderungen nur schwer implementieren lassen. Oftmals bringt das eine gigantische Umstellung mit sich, da alle Tests und Testroutinen an die neuen Bedingungen angepasst werden müssen.

Continuous Deployment als Basis

Der Continuous Deployment-Ansatz kann als Hintergrund des gesamten Systems betrachtet und ist eng an DevOps gekoppelt. Das Software-Produkt wird kontinuierlich weiterentwickelt, sodass es jederzeit freigegeben und an den Nutzer bzw. Kunden ausgeliefert werden kann. Konkret bedeutet das, dass der gesamte Entwicklungsprozess im Rahmen des Continuous Deployment durch automatisierte Tests in isolierten Testumgebungen abgesichert wird, ehe neue Komponenten oder Versionen des Systems in die laufende Software integriert werden. Im Rahmen des Continuous Deployment-Ansatzes werden alle Änderungen an dem Software-System nach strengen Kriterien und vollautomatisch in die laufende Software implementiert. Auf diese Weise wird eine Continuous Delivery (kontinuierliche Auslieferung) des Software-Produkts ermöglicht.

Gefahren beim Continuous Deployment

Der Einsatz von Continuous Deployment bringt auch einige potenzielle Probleme mit sich, die bei monolithischen Entwicklungsansätzen kaum eine Rolle spielen. So ist im Rahmen des Continuous Deployment die Gefahr relativ groß, dass innerhalb eines einzelnen Teams oder eines gesamten Projekts der Fokus der Arbeit unpräzise und falsch gesetzt wird, was katastrophale Folgen für den Ausgang des Projekts haben kann. Statt eine kontinuierliche Verbesserung des Software-Produkts anzustreben, wird in erster Linie eine möglichst hohe Deployment-Frequenz anvisiert. Ein beachtlicher Teil des Erfolgs des Continuous Deployment-Ansatzes hängt auch in hohem Maße von den eingesetzten Testkriterien und Testumgebungen ab, die bei der automatisierten Implementierung der Änderungen in die laufende Software zum Einsatz kommen. Falls schwerwiegende Fehler gar nicht erkannt oder nur zu spät identifiziert werden, sind infolgedessen in vielen Fällen umfangreiche Revisionen notwendig, um die eingeschlichenen Fehler zu beheben. Außerdem müssen für viele Neuerungen und Änderungen eigene Tests geschrieben werden, welche wiederum Fehler enthalten können.

Chancen und Möglichkeiten

Continuous Deployment kann unter einer streng strukturierten Arbeits-Arbeitsaufteilung sowie einer klar definierten Zielführung durchaus von großem Nutzen sein und erstklassige Ergebnisse liefern. Dieser Ansatz der Softwareentwicklung wird von vielen Entwicklern und Unternehmen, wie beispielsweise Red Hat oder Microsoft, in erster Linie wegen seiner Geschwindigkeit und seiner hohen Nutzerfreundlichkeit hochgeschätzt. Continuous Delivery ist von seinem Umfang her eher an die Bedürfnisse mittelgroßer und großer Software-Projekte ausgerichtet. Da die entsprechenden Systeme und die benötigte Infrastruktur in vielen Fällen von Grund auf aufgebaut, getestet und implementiert werden müssen, ist der Umstieg auf Continuous Deployment, Continuous Integration und Continuous Delivery für viele Unternehmen mit hohem Aufwand und intensiven Kosten verbunden. Nach der erfolgreichen Implementierung bringt dieser Ansatz der Softwareentwicklung jedoch beachtliche wirtschaftliche Vorteile mit sich. Neue Funktionen und Features lassen sich dann schneller umsetzen und für den Nutzer bzw. Kunden freigeben.

Die Abkürzung PaaS steht für Platform as a Service. Damit wird eine Cloud-Infrastruktur bezeichnet, die Entwicklern diverse Entwicklungsumgebungen und Tools zur Verfügung stellt, um Software-Produkte möglichst schnell und effizient zu entwickeln. PaaS ist also ein Cloud-Service, der insbesondere für Entwickler und IT-Unternehmen sinnvoll ist, die schnell und möglichst unkompliziert neue Apps entwickeln und diese ins Netz stellen möchten, ohne eine eigene Infrastruktur betrieben zu müssen.

Was genau ist PaaS?

Im Rahmen des Cloud-Computings fungiert PaaS als eine Art Bindeglied zwischen „Software as a Service“ (SaaS) und „Infrastructure as a Service“ (IaaS). Mit IaaS wird lediglich die benötigte IT-Infrastruktur bereitgestellt, die Unternehmen für ihre geschäftlichen Prozesse benötigen. Bekannte Beispiele für IaaS-Dienstleiter sind Amazon Web Services und Google Cloud. PaaS geht jedoch noch einen Schritt weiter und stellt gezielt fertige Pakete mit diversen Tools bereit, um direkt mit der App-Entwicklung zu beginnen. Entwickeln, testen, überarbeiten und als fertiges Produkt seinen Nutzern zur Verfügung zu stellen – all das lässt sich mi Platform as a Service realisieren.

Wie ist PaaS aufgebaut?

PaaS-Angebote setzen sich aus der benötigten Infrastruktur, wie beispielsweise Servern und Betriebssystemen, und der sogenannten Middleware zusammen. Mit Middleware werden spezielle Programme bezeichnet, die in der Lage sind, unterschiedliche Anwendungen miteinander zu verbinden. Hinzu kommen noch diverse Tools, wie zum Beispiel Entwicklungswerkzeuge, Datenbanken-Systeme, Container-Techniken sowie spezielle Programmier- und Skriptsprachen. Bei der auf der Plattform bereitgestellten Lösungen handelt es sich entweder um Eigenentwicklungen des Anbieters oder um Tools von Drittanbietern. Ihre Hauptaufgabe besteht darin, dem Kunden eine möglichst schnelle und komfortable Entwicklung zu ermöglichen.

 

Wenn Sie die Leistungen eines PaaS-Anbieters in Anspruch nehmen, dann müssen Sie sich also nicht mehr um die Beschaffung, Einrichtung und Verwaltung der IT-Infrastruktur kümmern. Sie können sich voll und ganz auf die Entwicklung Ihrer Anwendungen und auf Ihre Kunden fokussieren. Die Software lässt sich als SaaS  über die Cloud-Infrastruktur bereitstellen. Dabei kann es sich zum Beispiel um interne Software-Tools handeln oder auch um kommerzielle Software-Produkte, die für die Nutzung im Rahmen des World Wide Web vorgesehen sind.

Die Funktionsweise von PaaS

Im Rahmen von Plattform as a Service entwickelt Sie Ihr Software-Produkt grundsätzlich so, wie Sie es auch in einer eigenen Entwicklungsumgebung machen würden. Nach der Entwicklung des Programmcodes laden Sie ihn auf die Plattform hoch, wo er in einem Container bereitgestellt und ausgeführt wird, der den Anforderungen der Anwendung genauestens entspricht. Die meisten PaaS-Dienstleister bieten die Möglichkeit, mehrere Versionen derselben Anwendung parallel auszuführen Dadurch können Sie beispielsweise Live-Testumgebungen und Real Time Monitoring realisieren oder ein Rollback auf eine frühere Version schnell und unkompliziert ausführen.

Traditionelle Webhosting-Angebote sind ein gutes Beispiel dafür, wie das Konzept Platform as a Service funktioniert. Sie erstellen den Programmcode und laden ihn bei Ihrem Webhosting-Dienst hoch. Dieser führt den Code in der entsprechenden Umgebung aus und generiert daraus eine im World Wide Web frei zugängliche Website. Dabei müssen Sie sich nicht explizit um die Einrichtung von Datenbanken, Webservern und Speicherplatz kümmern. Moderne PaaS-Angebote sind grundsätzlich wesentlich komplexer und enthalten eine Vielzahl unterschiedlicher Funktionen und Features.

Welche Modelle gibt es?

Angesichts des gigantischen Angebots an unterschiedlichen Platform as a Service-Lösungen ist es nicht möglich, sie einzeln zu kategorisieren. Die einzelnen Lösungen unterscheiden sich teilweise stark und sind in der Regel auf unterschiedliche Anforderungen und Bedürfnisse ausgelegt. Dennoch existieren bestimmte Attribute, anhand derer sich die unterschiedlichen Platform as a Service-Lösungen identifizieren lassen. So unterscheiden man zum Beispiel:

– Application PaaS (aPaaS)

– Integration and Governance PaaS (iPaaS)

Mit dem erstgenannten Modell wird die Bereitstellung von Apps beschrieben, die mit einer grafischen Benutzeroberfläche ausgestattet sind. Das kann zum Beispiel eine App für die interne Nutzung im Unternehmen sein, die Mitarbeiter über die Cloud nutzen.

iPaaS ist hingegen auf die Integration von Cloud Services ausgelegt. Hier sorgt die Plattform dafür, dass keine Middleware-Lösungen benötigt werden, um Anwendungen zur Verfügung zu stellen. Ein bekanntes Beispiel hierfür ist die Anypoint Platform von MuleSoft.

Hinzu kommen noch die zahlreichen offenen Angebote etablierter IT-Größen, wie Google App Engine. Diese ermöglichen die Entwicklung in einer Open-Source-Umgebung, sodass Sie nicht an bestimmte Server, Programmiersprachen, Betriebssysteme und Datenbanken gebunden sind.

Vor- und Nachteile- moderner Lösungen

Der Einsatz von Platform as a Service überzeugt mit zahlreichen Vorteilen. Der wohl größte Vorteil spiegelt sich in der Tatsache wider, dass die App-Entwicklung ohne die Anschaffung und Verwaltung einer eigenen IT-Infrastruktur viel schneller und einfacher stattfindet. Produkte lassen sich so deutlich schneller auf den Markt bringen. Außerdem ist die Leistung der bereitgestellten Ressourcen skalierbar. Konkret bedeutet das, dass Sie die gebuchten Kapazitäten je nach Bedarf hoch- oder herunterskalieren können. Darüber hinaus ist der Faktor der Kosteneinsparung nicht zu unterschätzen, da Sie keine Lizenzen und Hardware erwerben und nicht selbst die Instandhaltung und Aktualisierung vornehmen müssen.

Ein sowohl Vorteil als auch Nachteil von PaaS spiegelt sich in der Tatsache wider, dass sich der Anbieter um die Anschaffung und Konfiguration der IT-Infrastruktur kümmert. Dadurch haben Sie keinen direkten Einfluss auf die Infrastruktur und können auch keine eigenen Lösungen implementieren.

Bei der Scrum-Methode handelt es sich um ein Vorgehensmodell aus dem Projektmanagement, das vornehmlich bei der agilen Entwicklung von Software zum Einsatz kommt. Der Ursprung der Methode liegt in der Softwaretechnik. Mittlerweile kommt Scrum in vielen Bereichen zum Einsatz.

Die Geschichte von Scrum

Die Anfänge der Scrum-Methode liegen in den 90er Jahren. Es handelt sich um einen Begriff aus dem Rugby, der frei übersetzt „angeordnetes Gedränge“ bedeutet. Ken Schwaber und Jeff Sutherland gelten heute als Gründer der Methode. Die öffentliche Vorstellung erfolgte 1995 auf einer Konferenz. Im Laufe der Jahre entwickelten die Anwender die Methode kontinuierlich weiter. Die Formulierung des agilen Manifests im Jahr 2001 war ein Meilenstein in der Scrum-Historie.

Was ist Scrum?

Kurz und bündig handelt es sich bei Scrum um das Rahmenwerk, welches die Zusammenarbeit von Teams definiert. Dieses legt Rollen, Werkzeuge und Meetings fest, um dem Arbeitsprozesse eine Struktur zu geben, die auf agilen Prinzipien basiert. Es handelt sich bei Scrum jedoch keineswegs um eine dogmatische Methode. Als Framework existieren lediglich Orientierungspunkte, die die Zusammenarbeit konkretisieren und leiten.

Wichtige Scrum-Prinzipien

Für eine hochwertige Umsetzung des agilen Projektmanagements unter Berücksichtigung der Scrum-Methode ist eine gezielte Vorgehensweise entscheidend. Folglich existieren einige Prinzipien, die als agile Werte das Fundament des Projektmanagements bilden. Unternehmen, in denen die Scrum-Methode zum Einsatz kommt, sollten die Werte und Leitlinien in die Unternehmenskultur integrieren.

– Wertorientierung: Die Teams bewerten ihre Tätigkeit nach dem erzielten Wert für das Unternehmen und die Kunden.

– Transparenz: Alle Ziele, Visionen, Entscheidungen und Aufgaben sollten transparent den Beteiligten zur Verfügung stehen.

– Fokussierung: Die anstehenden Aufgaben werden kontinuierlich nach ihrer Priorität geordnet, um den Fokus zu erhöhen.

– Autonomie: Das Scrum-Team agiert autonom. Die Organisation obliegt den Mitgliedern des Teams.

– Kommunikation: Eine enge Kommunikation ist Basis für kontinuierliche Verbesserung.

Die Prozessbeteiligten

Damit im Sprint ein funktionsfähiges Produkt für den Auftraggeber entsteht, müssen alle Beteiligten effektiv zusammenarbeiten. Drei Rollen beschreiben diejenigen Mitarbeiter, die direkt am Scrum-Prozess beteiligt sind.

Product Owner

Der Product Owner steht stellvertretend für die Nutzer eines Produkts. Folglich bringt der Product Owner die Perspektive in den Scrum-Prozess ein, dass das Produkt reibungslos funktionieren muss.

Team

Das Team organisiert sich im Prozess selbst und hat keinen Projektleiter. Die Größe ist überschaubar. Zudem befinden sich Mitarbeiter aus verschiedenen Fachdisziplinen im Scrum-Team.

Scrum Master

Der Scrum Master moderiert den gesamten Prozess. Als Ansprechpartner für Außenstehende kümmert er sich um eine Interaktion, die Mehrwert für das Team bringt.

Der zeitliche Ablauf

Je nach Definition und Erklärung gibt es unterschiedliche Bestandteile des Scrum-Modells. Im sogenannten Sprint Planning erfolgt die Planung des nächsten Sprints, in dem das Team die Anforderungen in konkrete Aufgaben zerlegt. Beim Daily Scrum tauschen sich die Teammitglieder aus und erörtern aktuelle Probleme. Es handelt sich um ein Meeting, um den Fokus auf bestimmte Punkte auszurichten. Am Ende des Sprints steht der Sprint Review. Das Entwicklungsteam präsentiert an dieser Stelle bereits das Product Increment. Im Sprint Retrospective findet die Überprüfung der gesamten Projektarbeit statt, um die Zusammenarbeit zu optimieren.

Die Artefakte

Die Scrum-Artefakte sind als Werkzeuge ein wichtiger Baustein für das Framework. Die Werkzeuge erhöhen die Transparenz der Prozesse.

Product Backlog

Das Product Backlog beschreibt eine Liste mit Anforderungen, die vom Team kontinuierlich weiterentwickelt wird. Der Product Owner führt das Produkt Backlog. Es handelt sich um ein dynamisches Dokument, das dauernd an das Produkt angepasst wird.

Sprint Backlog

Auf Basis des Product Backlogs entsteht eine Auswahl an Anforderungen, die das Team im Sprint bearbeiten soll. Im Sprint Backlog werden einzelne Aufgaben definiert – die sogenannten Tickets. Ein Teammitglied übernimmt Verantwortung für das Ticket. Im Sprint Backlog findet eine Prognose statt, inwieweit das zukünftige Increment bereits den funktionellen Anforderungen genügt. Zur gezielten Visualisierung der Anforderungen greifen die Mitglieder auf die Kanban-Methode zurück. Das Kanban-Board ist ein beliebtes Werkzeug, um Workflows abzubilden.

Product Increment

Am Ende des Sprints gibt es ein funktionsfähiges Zwischenprodukt, welches als Product Increment bezeichnet wird. Dieses Produkt ist bereits einsatzfähig. Der Product Owner entscheidet, ob es bereits ausgeliefert werden soll.

Der Vorteil von Scrum

Ein entscheidender Vorteil der Scrum-Methode ist, dass diese mit wenig Hilfsmitteln funktioniert. Der Aufwand für die Beteiligen ist überschaubar. Zudem erhöht die Standardisierung der Prozesse die Erfolgschancen eines Projekts. Die stetige Verbesserung im Projektmanagement erhöht Effizienz und Qualität gleichermaßen.

Die Grenzen

Die Scrum-Methode kam ursprünglich ausschließlich in der Softwaretechnik zum Einsatz. Im Laufe der Zeit adaptierten immer mehr Branchen die Projektmanagement-Methode. Dennoch ist diese nicht für Branchen geeignet, in welchen umfangreiche Dokumentationen erforderlich sind oder die Projekte Lebensgefahr verursachen können. Weiterhin existiert keine Erfolgsgarantie. Zu jeder Zeit gibt es Abweichungen vom Soll-Zustand. Der Erfolg des Projekts ist davon abhängig, wie das Team die gewonnenen Erkenntnisse einsetzt, um die Produkte zu verbessern.