Anmelden

Letze Releases

Geplante Features

Die folgende Tabelle zeigt den aktuellen Stand der in Planung befindlichen Erweiterungen oder Änderungen. Sofern das Release für eine Erweiterung bekannt ist, ist dieses angegeben.

Block

Appl.

Beschreibung

nsoftCMS
  • Seitenversionierung
  • Überarbeitung CELLstudio-Template (Aufhebung Frameweb)

nsoftQDE

  • Verwaltung von Beobachtern von Places und Items mit Berechtigungen Einsicht, Nachrichten an Beobachter (QdeWatch)
  • Ermöglichung anonymer Beobachter (ohne Nutzerkonto)
  • Screen-Broadcast auf Basis node.js und WebRTC, Kurento
  • RTC-Panel (Frame oder AJAX-Website)
    • Echtzeitanzeige der im Portal anwesenden Personen unter Berücksichtigung von Freigaben
    • Anzeige der sichtbaren Räume und aktuelle Sitzungen
    • Anzeige der aktuellen Sitzung des Nutzers
    • direkte Kontaktaufnahme mit anwesender Person/Support
  • Versenden von Video-Nachrichten
  • ICal
nsoftSYS
  • generische Feld- und Suchformularerweiterungen (definierbare Feldtypen TA, TF, CB, CG, SB, RG, Wertevorräte)
  • Integration von PHPMailer (pure PHP Mail Queue)
  • SysTask (geplante Änderung von Datenfeldern)
  • DMS
    • Einführung DMS-Reitermodell und DMS-Infoseite, Auflistung der CMS-Verwendung
  • Import/Export von Einstellungen
  • SysJob
    • Lock-Verfahren in einer Prozessgruppe. Prozesse die voneinander abhängen, können sich u.U. gegenseitig blockieren, sofern Prozesse über die Oberfläche manuell gestartet werden. Durch ein Lock können parallele Prozesse verhindert werden.
    • Prozessabbruch durch Operator über Oberfläche ausführen.
nsoftORG
  • 18.2 Verweigerung der View/Edit-Berechtigung auf persönliche Daten, siehe Datenschutz
  • Anzeige/Freigabe Online-Status anderer Nutzer (Sitzungsliste, Echtzeitkontakt)
  • Infozelle zur Anzeige von Berechtigten (Gruppen/Personen die ein Objekt sehen/bearbeiten können List/View/Edit), Recherchefunktion für Berechtigungen (Ermittlung der Gruppen bzw. Berechtigten für eine Berechtigung), eventuell als Infozelle mit Auswahlfeld Block/Berechtigung
  • Verwaltung von Freunden und Freigaben an Freunde
  • Kontaktdaten
    • Differenzierung von Berechtigungen für Kontakttypen (analog Referenztypen)
    • Ausbau der Maskierung auf Datenfelder in Kontaktdaten
nsoftSMB
  • APL
    • automatische SPL-Generierung (spätestens bei Export- oder Veröffentlichungsanforderung)
  • SPL - Veranstaltungsplanung
    • Ausnahmeplanung (ermöglicht Planungsabweichungen einzelner Termine, Umsetzung mittels sekundären Spl)
    • SPL-Sicherung/ Wiederherstellungspunkte
  • NC-Verfahren
  • Umstellung der SV-Erstellung auf Studienstarts

nsoftCOM

  • Konsolidierung Berechtigungsverwaltung (siehe nsoftCOM 17.1)
  • PHP-seitige Implementierung der Bestellassistenten und Detailseiten
  • Import DTA-Datei
  • clientseitige Lastabwehr
  • Synchronisierung Kurstermine nach CAL
  • Kundeneinstellung der Invoice-Benachrichtigungen
  • Anzeige betreute Kurse für Carrier (Übungsleiter)
nsoftEXP
  • Erfassung von Belegen
  • CSV-Import (Kontoauszüge)
  • Planung wiederkehrende Ausgaben
Framework
Kunden
  • HISGX-Konnektor,
    • Onlinesynchronisierung Prüfungseinschreibungen/Noten
  • SPLUS
    • Export auf SPL umbauen (siehe APL)
  • EMMi-Solution
    • Anzeige betreute Projekte im Dozent-Reitermodell, CSV-Export
    • Stat. Zahlen unter DVS-Zusammenfassung (EMMi-Extension)
    • Firmen- und Prüferverzeichnis
    • Verwaltung von Editoren
    • Einbeziehung Dozenten und Editoren in Mail-Benachrichtigungen
    • Umbau Datenmodell auf Sekundärnoten
permanent
  • Durchsetzung von Coding Standards
    • Bezeichner globaler Variablen
    • Dateinamenbereinigung aller PHP-Komponenten (*.asp)
  • Vervollständigung der Sprachressourcen
  • Datenmodell Redesign 2018
  • Mobilisierung aller Grids (Unterstützung Mobile Portale)
  • Minimalsystem ohne NET-Komponenten (campus21 Framework Basic)
  • Einführung PHPdoc für Bibliotheken und Klassen

Installationshinweise für Release-Wechsel

Die Installation eines Releases bzw. des Trunkes erfolgt aus dem SVN-Repository mittels svn checkout, update oder switch in das Wurzelverzeichnis der ECampus21/CELLstudio-Installation (im Beispiel his2010). Folgendes ist zu beachten:

  • dass Konfigurationsdateien vom SVN nicht in der endgültigen Form geliefert werden. Bei der Erstinstallation sind sie aus den Vorlagedateien zu kopieren, siehe Softwareinstallation.
  • Bei Updates müssen eventuelle Änderungen oder Ergänzungen von Konfigurationsdateien manuell durchgeführt werden. Ein automatisches "Merging" wird nicht durchgeführt. Die Änderungen werden mit dem Release dokumentiert.
  • Scriptdateien im Ordner System müssen nach einem svn checkout, update oder switch auf einem Linux-System erneut mit Execute-Rechten versehen werden

Ab 16.3 findet die Kompilierung aller NET-Komponenten in den Releases als auch im trunk auf dem Zielsystem statt. Die ausführbaren Dateien (.dll, .exe) sind nicht mehr Bestandteil des SVN. Dies betrifft alle Tools, Assemblies, Websites/ Webservices. Ein Ausrollen des kompilierten (binären) Releases als ZIP ist aktuell nicht möglich.

Releasewechsel

Bei einem Releasewechsel wird die Produktivumgebung auf den SVN-Pfad des jeweiligen Releases (branch) umgeschalten und damit gleichzeitig aktualisiert.

cd ~/releases/his2010
svn switch http://www.campus21.de:8081/branches/17.1/his2010
chmod 755 *.sh
chmod 755 System/*.sh
cd ~/trunk
svn switch http://www.campus21.de:8081/branches/17.1/trunk

Sollten Teil der Installation (PHP, Webservice, Systemprozesse und Wartungsskripte) in getrennten Ordnern abweichend von der SVN-Struktur installiert worden sein, dann müssen diese Teile bei einem Release-Wechsel auch getrennt aktualisiert werden. Im folgenden Beispiel wurde der PHP-Teil im wwwroot-Verzeichnis eines Windows Servers installiert.

cd C:\inetpub\wwwroot\nsoft
svn switch http://www.campus21.de:8081/branches/17.1/his2010/php
cd ...\his2010\System
svn switch http://www.campus21.de:8081/branches/17.1/his2010/System

Nach dem Switch kann es unter Umständen möglich sein, dass kundenspezifische Anpassungen verloren gegangen sind erneut getätigt werden müssen (Kopieren von Dateien, di an einem anderen Pfad erwarted werden o.ä.).

Umschaltung auf trunk

Die Umschaltung von einem Release auf den Trunk (aktueller Entwicklungsstand) ist in Entwicklungs- und Testumgebung manchmal erforderlich. Insbesondere wird dies gemacht, wenn ein Release vor dem Release-Wechsel in den Produktivbetrieb übernommen werden soll (sogenanntes Pre-Release). In kritischen Produktivumgebungen wird im Normalfall nicht mit dem Trunk (bzw. Pre-Releases) gearbeitet.

cd ~/releases/his2010
svn switch http://www.campus21.de:8081/releases/his2010 

Partielle Umschaltung (nur trunk):

cd ~/trunk
svn switch http://www.campus21.de:8081/trunk

Partielle Umschaltung (nur PHP):

cd ~/releases/his2010/php
svn switch http://www.campus21.de:8081/releases/his2010/php

Partielle Umschaltung (nur Website):

cd ~/releases/his2010/Nsoft.His.Website
svn switch http://www.campus21.de:8081/releases/his2010/Nsoft.His.Website

Partielle Umschaltung (nur System):

cd ~/releases/his2010/System
svn switch http://www.campus21.de:8081/releases/his2010/System

Ab 16.3 findet die Kompilierung der NET-Komponenten auf dem Zielsystem statt, welche nach dem Rückschalten durchgeführt werden muss.

Informationen für Entwickler

Das Anlegen von Branches (=Releases) erfolgt durch campus21. Unter der Release-Planung finden Sie Informationen über die existierenden Releases, als auch über die Features und Termine für geplante Releases. Kunden und externe Entwickler, die eigene Komponenten besitzen müssen den Release-Zyklus beachten, wenn Sie zukünftige Release-Wechsel durchführen wollen.

Für die Koordinierung von Release-Wechseln und spezifischen Entwicklungen gibt es verschiedene Szenarien. Je nach Anforderung des Kunden wird das geeignetste Szenario ausgewählt und ggf. vertraglich abgesichert.

Standard-Szenario

Im Normalfall werden nur Releases (Branches) im Produktivbetrieb eingesetzt. Die Release-Wechsel der Produktivsysteme erfolgen nach Herausgabe der Releases durch campus21. Bei der Herausgabe wird durch campus21 der Trunk in einen Branch kopiert.

In einem Branch werden für eine begrenzte Dauer Bugfixes durch campus21 vorgenommen. Auch Kunden und externe Entwickler tun dies für ihre Komponenten, solange der Branch produktiv verwendet wird. Bugfixes müssen im Trunk und allen aktiven Branches vorgenommen werden. Kunden und externen Entwickler müssen jedoch nur den Branch pflegen, der tatsächlich (in der Regel bei Ihnen selbst) eingesetzt sind.

Die Weiterentwicklung seitens campus21 und seitens Kunden und externen Entwicklern erfolgt in der Regel nur im Trunk. Diese Erweiterungen werden erst mit dem nächsten Release-Wechsel wirksam. Entwicklungssysteme oder Evaluierungssysteme arbeiten in der Regel mit dem Trunk, damit Weiterentwicklungen sofort getestet werden können.

In Ausnahmefällen sollen Erweiterungen oder Änderungen sofort auf einem Produktivsystem wirksam werden. Dazu müssen diese, analog zu Bugfixes, zusätzlich auf den jeweiligen Branch übertragen und das Produktivsystem aktualisiert werden.

Zur Durchführung von übergreifenden Änderungen (Bugfixes, sowort wirksame Änderungen) kann man mit den Werkzeugen von SVN (Merge) vorgehen. Oftmals genügt es auch ganze Dateien oder einzelen Programmzeilen zu kopieren. Dazu muss der Entwickler die jeweiligen Branches ausgebucht haben. Der Test von Bugfixes erfolgt in der Regel im Trunk, nach der Übertragung auf Branches muss der Entwickler dafür sorgen, dass der Branch funktionsfähig ist.

Die Durchführung von Änderungen erfordert in der Regel eine Arbeitskopie des Trunkes bzw. Branches auf einem Eintwicklungssystem. Eine solche Arbeitskopie wird mit SVN checkout hergestellt. Neben den dazu nötigen Leserechten im SVN-Repository sollten auch Schreibrechte bestehen, damit Änderungen eingebucht werden können. Änderungen der Arbeitskopie werden mit SVN commit in das campus21-Repository eingebucht.

Eingebuchte Änderungen auf dem campus21-Repository werden über die Revisionsnummer sichtbar (SVN info). In der Regel können und sollen Produktivsysteme als auch Entwicklungssysteme regelmäßig, d.h. auch außerhalb eines Release-Wechsel, aktualisiert werden (SVN update), damit Änderungen bzw. Bugfixes wirksam werden.

Aktualisierungen, Dateiänderungen und Einbuchen sind auch auf einem lauffähigem System mit dem integrierten Dateimanagement möglich (nur custom-Bereich).

Sonderszenarien

  1. Kunden-Repository: Hiebei wird eine Kopie des campus21-Repository auf ein kundeneigenes Repository vorgenommen. Der Kunde entwickelt ausschließlich darin weiter. Der Kunde ist unabhängig vom campus21-Repository. Es besteht die Möglichkeit eigene Branches oder Berechtigungen zu verwalten. Diese Variante ist dann sinnvoll, wenn der Kunde im Kernsystem Änderungen oder Umstrukturierungen in größerem Umfang vornehmen möchte. Hierdurch wird ein eigenes Produkt etabliert. Ein Abgleich mit dem campus21-Repository ist nicht möglich bzw. sehr aufwendig.
  2. Kunden-Branch: Hierbei wird ebenfalls ein vollständiger kundenspezifischer Entwicklungspfad begonnen, der zugleich das Produktivsystem des Kunden darstellt. Dieser befindet sich aber im campus21-Repository, wobei der Kunde ebenfalls volle Berechtigungen und Eigenverantwortung hat. Der Kunde ist von den Release-Wechseln abgekoppelt, es bestehen aber Möglichkeiten des Vergleiches oder Abgleiches (Merge) mit dem campus21-Trunk oder Releases.
  3. Kunden-Export: Hierbei exportiert der Kunde ein Kopie aus dem campus21-Repository. Er kann diese eigenständig ohne weitere Unterstützung von SVN und besondere Berechtigungen und Rücksichtnahmen weiterentwickeln. Ein späterer Abgleich mit dem Repository (Einbuchen, Aktualisieren, Merge usw.) ist nicht möglich, da beim Export keine SVN-Informationen auf dem Kundensystem hinterlegt sind.

Kundenkomponenten und Berechtigungen

Kunden und externe Entwickler erhalten Berechtigungen zur Bearbeitung einzelnder Komponenten im campus21-Repository:

  • Kunden lagern ihre Komponenten ausschließlich unter dem Pfad custom/kunde im Trunk als auch in Releases. Auf diesen Pfad haben sie im campus21-Repository Lese - und Schreibzugriff
  • externe Entwickler können auch im Kernsystem tätig werden, je nach Verantwortlichkeit un vereinbarungen erhlten Sie die dafür notwendigen Berechtigungen im campus21-Repository

   
Top

Wir arbeiten mit Software von http://www.campus21.de.

Verantwortlich für angezeigte Daten ist der Webdomain-Eigentümer laut Impressum.

Suche