top of page
  • AutorenbildKatharina Lorenz

Wie unsere Entwickler an ILIAS arbeiten #Part 1

Aktualisiert: 18. Juli

Damit ihr einen Eindruck bekommt, wie unsere drei Software-Entwickler Fabian, Lukas und Thibeau an ILIAS mitarbeiten, möchten wir hierzu ein paar Zeilen in zwei Beiträgen veröffentlichen. Heute zum Thema ILIAS-Software-Entwicklungsprozess und Github, im nächsten Beitrag wird es dann ums Bugfixing und Mantis gehen. Los geht's mit dem Begriff "Trunk".


Hauptentwicklungszweig der ILIAS Core Softwareentwicklung, derzeit für ILIAS Version 10. ILIAS ist ein institutionsübergreifendes Softwareentwicklungsprojekt und es gibt derzeit mehrere Dutzend Personen, die teilweise gleichzeitig zum Core-Code beitragen. Damit dieses Zusammenspiel gelingen kann, nutzt ILIAS, wie viele andere Softwareprojekte, das Versionsverwaltungs-Tool Git und die Plattform Github. Aus historischen Gründen heisst der Hauptentwicklungszweig nicht «main» o.ä. Bevor ILIAS zu Git gewechselt hat, nutzte die Community das unterdessen veraltete Tool Subversion. Dort hiess der Hauptentwicklungszweig standardmässig «trunk», bei der Migration zu Git wurde dies beibehalten.

Nun habt ihr auch schon von Git und Github gelesen. Dazu nun noch ein bisschen mehr: Git erlaubt mehrere Entwicklungszweige (Branches) in einem Repository (bspw. ILIAS), so gibt es neben dem Trunk pro Release einen eigenen Branch (bspw. release_9), der mit versionsbezogenen Änderungen versorgt wird. Neue Features landen immer nur so lange auf dem Trunk, bis dann aus dem Trunk ein neuer Release-Branch abgezweigt wird (Coding Completed / Veröffentlichung Beta-Release).

Lokal nutzen die Entwickler:innen eine Vielzahl von eigenen Branches, welche bspw. für sogenannte Pull-Requests auf Github genutzt werden können. Mit einem Pull-Request stellen Entwickler:innen die Anfrage, ob sie ihre gemachten Änderungen wieder in einen der offiziellen Branches zurückführen können. Wenn derjenige Entwickler, dem die Anfrage gestellt wurde, die Änderungen annimmt, werden die Branches zusammengeführt (Merge). Nun hat aber nicht jeder die Berechtigung solche Code-Changes abzunehmen. Dies ist bei ILIAS folgendermassen geregelt: Die Person benötigt die "Authority to Sign off on Code Changes". Was früher dem Maintainer einer Komponente vorbehalten war, geschieht neu über verschiedene Authorities. Wer welche Authority bei welcher Komponente hat, kann im Development Guide nachgelesen werden. Einer Übersicht "unserer" aktuellen Komponenten findet ihr hier:


Active Record

File Services

Main Menu

Administrative Notification

File System Service

Permanent Link / Static URL

Background Tasks

File Upload Service

Shibboleth Authentication

Bibliographic List Item

Global Cache

UI Components

Database Service

Global Screen

UI Core

File Delivery Service

HTTP-Request

Web Access Checker

File Object

ILIAS Resource Storage Service (IRSS)

WOPI


49 Ansichten0 Kommentare

Aktuelle Beiträge

Alle ansehen

Comments


Beitrag: Blog2_Post
bottom of page