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 |
|
|
nsoftQDE |
|
|
nsoftSYS |
|
|
nsoftORG |
|
|
nsoftSMB |
|
|
nsoftCOM |
|
|
|
||
Framework |
|
|
Kunden |
|
|
permanent |
|
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
- 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.
- 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.
- 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
Wir arbeiten mit Software von http://www.campus21.de.
Verantwortlich für angezeigte Daten ist der Webdomain-Eigentümer laut Impressum.