Machen Sie sich bereit, die OpenEuropa Initiative ist da!

In einer der Episoden von Star Trek – „Kennen Sie Tribbles?“ – gibt es ein anschauliches Beispiel dafür, wie kleine Veränderungen innerhalb kurzer Zeit zu folgenschweren Konsequenzen führen können.  

Die Episode veranschaulichte die Auswirkungen neuer „Spezies“ auf eine etablierte Gesellschaft, ähnlich dem Aufstieg von Open-Source-Software und ihren Tools in der heutigen Technologielandschaft. 

Doch viele von uns sind sich der Reichweite und des Einflusses von Open Source auf unsere persönliche und berufliche Leistungsfähigkeit oft nicht bewusst.

Um dieses Bewusstseinsproblem zu lösen, wurde die OpenEuropa-Initiative ins Leben gerufen. Diese Initiative der Generaldirektion für Information zielt darauf ab, Open-Source-Tools und -Praktiken zu stärken und zu übernehmen, um die Webpräsenz der europäischen Institutionen zu konsolidieren. 

Worauf sich die Initiative konzentriert?

Um diese Ziele zu erreichen, konzentriert sich die OpenEuropa-Initiative auf die folgenden Aktivitäten. 

• Softwarekomponenten, lizenziert unter EUPL-1.2

Die Initiative konzentriert sich auf die Entwicklung, Wartung und Veröffentlichung lose gekoppelter, wiederverwendbarer Softwarekomponenten, die unter der EUPL-1.2 lizenziert sind. 

Die European Union Public License ist eine freie Softwarelizenz, die von der Europäischen Kommission erstellt und genehmigt wurde. Ziel dieser Lizenz war es, eine Open-Source-Lizenz in 23 verschiedenen Sprachen für die Europäische Union zu schaffen, die zudem dem Urheberrecht der Mitgliedstaaten der Europäischen Union entspricht.

• Open-Source-Strategien 

Die Initiative konzentrierte sich auch auf die Entwicklung, Wartung und Veröffentlichung vollwertiger Lösungen und Open-Source-Strategien für die europäischen Institutionen. Die besonderen Ziele dieser Strategien sind:

Gleichbehandlung im Verfahren 

Hierbei werden Open-Source-Lösungen und proprietäre Lösungen gleichberechtigt bewertet, wobei beide auf der Grundlage der Gesamtbetriebskosten, einschließlich der vorherrschenden Kosten, beurteilt werden. 

Beitrag zu Communities 

Die Kommissionsdienststellen würden sich aktiv an Open-Source-Software-Communities beteiligen, um einen starken Open-Source-Baustein zu entwickeln, der in der Software der Kommission verwendet wird.

Klärung rechtlicher Aspekte

Für eine einfache Zusammenarbeit mit Open-Source-Communities profitieren die Entwickler der Kommission von der richtigen rechtlichen Beratung und Unterstützung im Umgang mit Fragen des geistigen Eigentums im Zusammenhang mit Open-Source-Software.

Gute Kommunikation

Die Strategie legt großen Wert auf eine verbesserte Governance, die verstärkte Nutzung von Open Source im Bereich der IKT-Sicherheit und die Abstimmung dieser Strategie. 

 

• Übersicht über die Webdienst-Architektur 

Die Initiative bietet eine übergeordnete Architekturübersicht webbasierter Informationssysteme. 

Ein Web-Informationssystem oder webbasiertes Informationssystem ist ein Informationssystem, das Internet-Webtechnologien nutzt, um Informationen und Dienste an Benutzer oder andere Informationssysteme zu liefern. 

Ein Softwaresystem, dessen Hauptzweck die Veröffentlichung und Pflege von Daten unter Verwendung hypertextbasierter Prinzipien ist. 
 

 

• Open-Source-Projekte 

Die Initiative trug zu den Upstream-Open-Source-Projekten bei. Jedes Projekt entspricht den PHP-FIG-Standards und hält sich an die Best Practices, die von PHP „the right way“ vorgegeben werden.

PHP- und Drupal-Projekte, die unter der EUPL-1.2-Lizenz veröffentlicht wurden, sind:

 

OpenEuropa Coding Standards

OpenEuropa und seine Komponenten wurden mit Blick auf öffentliche Beiträge entwickelt. Damit alle Komponenten und Beiträge ein einheitliches Erscheinungsbild haben, hat sich OpenEuropa zur Einhaltung bestimmter Coding Standards verpflichtet. 

Obwohl OpenEuropa keine eigenen Coding-Standards-Richtlinien verfolgt, hält es sich an bekannte Standards wie PSR-1 und PSR-2.

Die Code-Review-Komponenten wurden entwickelt, um es den Beitragenden zu erleichtern, neue Komponenten zu erstellen oder bestehende zu modifizieren. Die Coding Standards müssen im Rahmen der OpenEuropa-Code-Reviews für die verschiedenen OpenEuropa-Komponenten überprüft und validiert werden. 

Entwicklungsumgebung

Die Projekte, die im Rahmen der OpenEuropa-Initiative entwickelt werden, folgen keiner bestimmten Entwicklungsumgebung; es gibt jedoch Softwarepakete, die dies tun. Die Softwarepakete sind:

Tools	Erforderlich	Zweck
PHP	JA	Benötigt von Drush, Composer und Task Runner
Composer	JA	Ein Paketmanager für PHP
GIT	JA	Versionskontrollsystem
Drush	JA	CLI (Kommandozeilen-Schnittstelle) Integration mit Drupal
ROBO	JA	Erforderlich für den OpenEuropa Task Runner
Node.js	JA	Erforderlich für die Entwicklung des OpenEuropa-Themes

PHP:  Wir haben dieses Wort schon einmal in unserem Leben gehört. Hier wird PHP von verschiedenen Tools benötigt, darunter Composer, Drush, Robo und Drupal selbst.

Composer:  Composer wird zur Verwaltung von Abhängigkeiten in PHP-Projekten verwendet. Alle Projekte müssen ihn verwenden, und der Vorteil dabei ist seine natürliche Integration mit Drupal.org.

Git: Git ist das verteilte Versionskontrollsystem, das als Grundlage des OpenEuropa-Ökosystems dient. 

Drush: Dies ist die Kommandozeilen-Shell und UNIX-Interface-Skripting für Drupal und wird verwendet, um über die Kommandozeile mit der Drupal-Website zu interagieren.

ROBO: Dies ist ein einfacher PHP-Task-Runner, der von Gulp und Rake inspiriert ist und darauf abzielt, gängige Aufgaben zu automatisieren.

Node.js: Es wird für die Entwicklung von OpenEuropa-Themes benötigt. Alle Entwicklungsabhängigkeiten sind in package.json definiert. 

Automatisierte Tests für Funktionalitäten

OpenEuropa verlangt, dass für jede neue Funktion oder Fehlerbehebung automatisierte Tests geschrieben werden, um sicherzustellen, dass die Funktionalität auch in Zukunft wie erwartet funktioniert. Es gibt zwei Arten von Tests: 

User Stories

OpenEuropa praktiziert Behaviour Driven Development (BDD), um eine effektive Kommunikation zwischen Geschäfts- und Entwicklungsteams zu ermöglichen. User Stories sollten von Testszenarien begleitet werden, die in nicht-technischer Sprache verfasst sind. Nachdem die User Stories akzeptiert wurden, können sie für automatisierte Tests verwendet werden, um sicherzustellen, dass die Geschäftsanforderungen erfüllt werden. 

Unit Tests 

Pull Requests, die nicht aus User Stories resultieren, können durch Unit Tests anstelle von BDD-User Stories abgedeckt werden. Der Benutzer sollte das geeignete Unit-Testing-Framework verwenden, das für die Programmiersprachen verfügbar ist, in denen die Komponenten entwickelt werden. 

Können auch Drupal-Komponenten getestet werden?

Zusätzlich zum Test-Framework, das mit dem Drupal-Core geliefert wird, verwendet OpenEuropa auch Behat, um Geschäftsanforderungen zu beschreiben. 

Behat ist ein Test-Framework für verhaltensgesteuerte Entwicklung (Behavior-Driven Development), das in der Programmiersprache PHP geschrieben ist. 

Wenn ein Pull Request eine Änderung des Benutzerverhaltens erzwingt, ist es erforderlich, das erwartete Endbenutzerverhalten im Behat-Szenario zu beschreiben. 

• Jede User Story wird von einem Behat-Szenario begleitet. Das Szenario dient den Projektbeteiligten für die Akzeptanztests. 
• Die Zielgruppe dieser Szenarien sind Stakeholder. 
• Jedes Behat-Testszenario ist in einer domänenspezifischen Sprache verfasst und sollte nur dazu verwendet werden, das erwartete Benutzerverhalten zu beschreiben, wie es von den Stakeholdern festgelegt wurde.
• Jeder Code, der das erwartete Endbenutzerverhalten nicht direkt beeinflusst, sollte stattdessen durch Unit Tests abgedeckt werden.

Drupal 8 hat das Konzept der experimentellen Module eingeführt, die nicht unter Datenschutzrichtlinien fallen oder vollständig unterstützt werden, sondern zu Testzwecken verwendet werden. Sie bieten eine breite Palette von Funktionalitäten, von der Migration bis zum Site Building. 

Aufgrund des experimentellen Charakters dieser Module hat OpenEuropa eine Reihe von Richtlinien für seine Komponenten definiert.

Erforderliche Mindeststabilität

Diese Module folgen verschiedenen Stabilitätsstufen von Drupal: Alpha, Beta, RC und Stable.
Damit OpenEuropa Stabilität gewährleisten kann, sind nur experimentelle Module in der Beta-Phase und höher zugelassen. 

Dies geschieht, weil die Module in der Beta-Phase und späteren Phasen sehr API-stabil sind. Wann immer die API geändert wird, wird große Sorgfalt darauf verwendet, eine Kompatibilitätsschicht bereitzustellen. 

Experimentelle Module im Alpha-Status

Obwohl die Regeln besagen, dass Alpha-Module nicht in der Produktion zugelassen sind, bieten sie dennoch einen großen potenziellen Wert für die Kunden. 

Wenn aus technischen oder geschäftlichen Gründen ein Alpha-Modul das Projekt rechtfertigt, sind Alpha-Module für Experimente zugelassen. In solchen Fällen verwenden die Komponenten jedoch dieselben Bezeichnungen wie die experimentellen Module, die sie nutzen. Das bedeutet, wenn Sie ein Alpha-Modul verwenden, müssen Sie dessen Bezeichnung ebenfalls verwenden, bis das zugehörige Modul geändert wird. 

OpenEuropa Release-Zyklus

OpenEuropa veröffentlicht seine Komponenten nach semantischer Versionierung. Es sind drei Arten von Releases geplant:

MAJOR

Inkompatible API-Änderungen, sehr selten und geplant

MINOR

Fügt abwärtskompatible Funktionalitäten und Fehlerbehebungen hinzu
 
PATCH 

Fügt abwärtskompatible Fehler-/Sicherheitskorrekturen hinzu und kann sofort bereitgestellt werden. Es werden keine neuen Funktionalitäten eingeführt. 

Release-Vorbereitung und Tests in Drupal

OpenEuropa Drupal-Komponenten werden in Anlehnung an Drupal 8-Komponenten veröffentlicht und immer gegen folgende Versionen getestet: 

• Aktuelle Stabilität in der Drupal 8 Core Minor Release. (n)
• Vorherige Drupal 8 Core Minor Release. (n-1)
• Entwicklungsbereich in Drupal 8 Core Minor.

Dies ermöglicht es, denselben Support-Zyklus wie Drupal Core zu verfolgen und besser auf die nächsten Minor Releases vorbereitet zu sein, sobald sie erscheinen.

Release-Support 

Für Drupal-Komponenten wird das OpenEuropa-Team eine Support-Richtlinie haben, die vom Drupal Core inspiriert ist:
Komponenten unterstützen die aktuelle und die vorherige Drupal Core Minor Version. Neue Minor Versionen für Komponenten werden mit diesen jeweiligen Core-Versionen kompatibel gemacht.
Wenn eine neue Minor Core Version (n) unterstützt wird, wird der Support für Release n-2 eingestellt.

Fazit 

Open Source und seine Komponenten sind für den Aufbau von Vertrauen und Sicherheit rund um Software und Web unerlässlich geworden. Es hat zu Projekten, serviceorientierter Architektur und technischer Governance beigetragen, die das Design und die Entwicklung der Komponenten bestimmen.

Die Initiative ist wie ein Blitz in dieser dunklen Welt der „Unwissenheit“ aufgetaucht. Sie hat nicht nur die Stärken und Kräfte von Open-Source-Tools und -Praktiken genutzt, sondern auch eine starke Position in der Webpräsenz etabliert. 

Kontaktieren Sie uns unter [email protected] für alle Anfragen und Fragen zu diesem Thema. Unsere Expert:innen beraten Sie gerne und bieten Ihnen entsprechende Dienstleistungen an.