Der Einsatz einheitlicher Software und Fonts stellt sicher, dass technisch einheitliche Ergebnisse generiert werden können. Insbesondere die von Crem erworbenen Fonts müssen in der aktuellen Version genutzt werden. Die Programme und Fonts werden von der Crem-IT bereitgestellt. Die Einrichtung zusätzlicher Software unterliegt den IT-Richtlinien der Crem Solutions und bedarf entsprechender Rückfrage bei der jeweils zuständigen Stelle.
Generelle Quelle für Software ist I:\SOFTWARE.
PF DinText Std-Light, Dateiversion 1.001, OpenType-Layout, TrueType Konturen PF DinText Std Medium, Dateiversion 1.001, OpenType-Layout, TrueType Konturen Die ttf-Fonts stehen im Verzeichnis i:\PROJEKTE\PF Din Text Std Light bzw. i:\PROJEKTE\PF Din Text Std Medium für Windows-Systeme zur Verfügung. Die gleichnamigen otf-Dateien sind nur für Apple-Betriebssysteme vorgesehen. Der Medium-Font wird lt. CI-Vorgaben für fett-Darstellungen in Überschriften genutzt (der light-Font in fett gesetzt ist typographisch minderer Qualität).
Der Client Tortoise SVN ist ein freier Client für den Versionsverwaltungs-Dienst Apache Subversion. Er wird von der Entwicklung bereitgestellt und installiert. Als lokales Verzeichnis wird hierzu c:\work eingerichtet.
Crem-internes Ticketsystem, welches vor allem von Produktmanagement, Entwicklung und Customer Care sowie Consulting und Crem-IT genutzt wird.
E-Mail- und Kalenderfunktionen
Der lizenzierte Total Commander ist eine optionale Alternative zum Microsoft Windows Explorer. Er bietet viele nützliche Funktionen für Dateioperationen, welche so zentral nutzbar sind.
Notepad++ ist eine OpenSource Software. Als universeller ASCII/ANSI/html-Editor ist er eine sinnvolle Alternative zu Windows notepad.exe). Notepad++ kann als Editor in Total Commander eingebunden werden.
Die Adobe Software zum Erstellen und Bearbeiten von PDF bietet einige Funktionen, welche insbesondere für die Nachbearbeitung von PDF-Dateien sinnvoll sind. Die Nachbearbeitung stellt aber nur eine Notlösung dar, da i. d. R. die Quelltexte in offen bearbeitbarer Form (vor allem .docx) zur Verfügung stehen.
Das c:\work-Verzeichnis enthält aktuell die Unterverzeichnisse branch, trunk, trunk_minus1, trunk_minus2, trunk_minus3, trunk_minus4 sowie merge-Hilfsverzeichnisse (merge_t_to_b, merge_t1_to_2, merge_t2_to_t1, merge_t3_to_t2 und merge_t4_to_t3). Mit Tortoise SVN werden alle einzeln generierten Datenpakete versioniert gespeichert. Änderungen können somit verfolgt oder auch rückgängig gemacht werden, da der Code zwischen einzelnen Entwicklungsschritten abgeglichen werden kann. Wöchentliche Patches (i. d. R. Bugfixes u. kleinere Anpassungen) werden in den Trunk-Ebenen gespeichert und den Kunden per Update Service zur Verfügung gestellt. Patches werden innerhalb eines Zyklus inkrementell aufgebaut, d. h. das neuere Patch beinhaltet auch alle Inhalte und Verbesserungen seiner Vorgänger. Demgegenüber werden im Branch-Verzeichnis im dreimonatigen Entwicklungszyklus vollständige Updates zu vorhandenen Programmversion entwickelt. Mit diesen so genannten Service Pack werden auch alle Erweiterungen und Korrekturen aus den für die Vorgängerversion generierten Patches zur Verfügung gestellt.
Kundenversionen (Sonderprogrammierungen) werden in Kundenverzeichnissen im Trunk oder Branch separat gespeichert. Sie sind i. A. durch Kopplung an eine Lizenz kundenspezifisch operabel. Andere Varianten für individualisierte Einrichtung sind der Einsatz von speziellen Systemparametern in iX-Haus oder die Einrichtung von Modulen als Zusatzprogramme oder eine Variantensteuerung via Alias-Aufruf. Zum Aufruf solcher Module benötigt man daher dann eine analoge Einrichtung wie beim Kunden und/oder eine adäquate Lizenz.
Als Vorschlag einer entwicklungsinternen Terminologie zur Differenzierung verschiedener kundenspezifischer Modulvarianten im Prozess der Update Notes Erstellung hat die Redaktion folgendes empfohlen:
1. Sonderprogrammierung exklusiv für diesen Kunden: SoPro Kundenname exklusiv
⇒ TR macht nichts weiter.
2. Sonderprogrammierung zunächst nur für diesen Kunden, später für alle: SoPro Kundenname
⇒ TR bereitet Aufnahme in Benutzerdoku vor (zukünftig: legt Eintrag im Wiki an), aber erstellt zunächst keinen Notes Eintrag.
3. Sonderprogrammierung für diesen Kunden geht sofort an alle raus: SoPro Kundenname allgemein
⇒ TR nimmt in Benutzerdoku auf und erstellt den entsprechenden Notes Eintrag.
Wöchentlich wird für Testzwecke im Pfad Q:\RanorexVergleichsdateien\Test-Updates\Branch ein Servicepack aktualisiert zur Verfügung gestellt. Diese Quelle wird als Updatepfad für lokale Testinstanzen auch in der Redaktion genutzt. Am Anfang der Woche kann somit ein Update hierüber abgerufen werden. Darin sind dann alle Anpassungen aus den vorherigen Wochen kumulativ enthalten. Relevant ist dies für Testinstallationen mit dem in Arbeit befindlichen neuen Servicepack.
Zu Beginn der Testphase an einem Monatsende kann dann ein Update über Q:\Deploy\ServicePack\20.17_Next_ServicePack\… genutzt werden.
Das Update der Testversion unter y:\kundenv4\IXODA35 wird i. d. R. durch die CremIT oder ARR vorgenommen. Da es in der internen Dateiverwaltung immer wieder zu Dateisperrkonflikten kommen kann (Benutzer X hat Programm geschlossen, Windowsserver gibt verwendete Programmdatei aber nicht zeitnah frei) ist es sinnvoll, das Update durch die IT vornehmen zu lassen, da diese vorab Dateisperren administrativ aufheben kann.
Für den aktuellen Stand der releasten Version kann der Redakteur eine VM-Ware-Variante auf seinem lokalen PC nutzen. Hier kann ein anstehendes Patch zu Testzwecken eingespielt werden, welches aus Q:\Deploy\… stammt.
Die redaktionelle Arbeit erfordert Zugriff auf bestimmte Verzeichnisse von technischer Redaktion und Entwicklung. Diese sind durch einheitliches Mapping vorgegeben. Derzeit erforderlich ist eine Berechtigung mit lesend/schreibendem Zugriff auf
I: -> \\crem-solutions.de\intranet
hier u. a. die Unterverzeichnisse DOKU, PROJEKTE, SOFTWARE, SYBILLE
Q: -> \\srv-dev\QK
hier u. a. die Unterverzeichnisse Doku, QK_325, Deploy, Doku
Y: -> \\crem-solutions.de\dasis
Datensicherungen
Weitere Verzeichnisse können im Rahmen von Projekttätigkeiten hinzukommen.
Dateien werden i. d. R. lokal bearbeitet und dann mit einem Netzwerkpfad abgeglichen. Der Abgleich erfolgt meist über die im Dateimanagement von Windows eingebundene Software Tortoise SVN. Als lokales Verzeichnis für die Dokumente unter dieser Verwaltung wird c:\work eingerichtet. Die darunter befindlichen lokalen Verzeichnisse haben zugeordnete Verzeichnisse in einem Netzwerkpfad.
Wichtig: Der Hauptarbeitsordner der Redaktion mit Wiki, Leitfaden, Ressourcen und Projektübersichten ist 2019 lokal unter c:\Work\Branch\intern\Technische Redaktion eingerichtet.
Dokumentationen (alle PDF- Dateien aus .\ix_dev\Doku\Allgemein\) kommen in das Unterverzeichnis .\doku\. Ein entsprechender Eintrag wird in der Datei ixupdate.cmd hinzugefügt.
Kundendokumentationen (alle PDF-Dateien aus .\ix_dev\Doku\Kunden\) kommen in das Unterverzeichnis .\kdoku\). Pro Datei wird hier ein Eintrag mit der Kundenlizenznummer in der Datei ixupdate.cmd hinzugefügt. Die Kundenlizenznummer(n) werden aus dem Namen des Kundenordners ermittelt. Mehrere Lizenznummern werden mit Unterstrich „_“ getrennt angegeben, z. B. „aik_310884_311603“.
Die Dokumentation gibt es sowohl im Trunk als auch im Branch. Jeweils in dem Verzeichnis .\ixdev\doku\. Änderungen im Trunk werden automatisch in den Branch weitergeleitet. Änderungen aus dem Trunk-1 werden automatisch in den Trunk gemerged. Dies geschieht mit den gleichen Techniken wie beim Sourcecode. Daher müssen wir alle Dokumente, die entfernt werden sollen, auf der unterst relevanten Ebene löschen. Auf Ebene des Branchs bearbeiten wir alle internen Dokumente im Ordner Intern / Technische Redaktion.
Eine veränderte Word-Datei wird bei Commit des Autors automatisch als PDF-Datei generiert und committet und kann dann über ein Update des entsprechenden Verzeichnisses geholt werden. Über den Befehl NoDeploy beim Commit kann das automatische Erzeugen einer PDF-Datei unterbunden werden. Nur die PDF-Datei wird in einem Updatepaket abgelegt, wodurch sie automatisch bei der nächsten Auslieferung von Patch bzw. Servicepack zu den Kunden gelangt.
Als Auslöser wird der Basis-Dateiname (ohne Extension) benannt, ggf. mit Ergänzung (z. B. bei Patch auch die Kalenderwoche). Der Auslöser ist namensbildend in den AddOns. Unter Inhaltliche Änderung werden die logische Anpassung oder Details beschrieben.
Beim SVN Commit für Dokumente (Word-, PDF- oder XLS-Dokumente) muss die Protokolldatei mit der Technischen Änderung NoMerge generiert werden, um einen Abgleich der Datei in anderen übergeordneten SVN-Verzeichnissen zu verhindern! Ohne NoMerge-Befehl erfolgt eine aufsteigende Aktualisierung (z. B. bei Erstellung in trunk_minus1 → trunk → branch). Beispiel:
Auslöser 20.17_PatchDoku KW05/19 Inhaltliche Änderung bis 31.01.2019 11:16:08 AddOn 537 Doku Testhinweise Betroffene Module Technische Änderung NoMerge
Bezüglich der Dokumentationen sind drei Typen zu unterscheiden: Patch-Doku, Service Pack-Doku und Mini-Doku. Die Patch-Doku ist begleitend zu den wöchentlichen Korrekturen. Die Service Pack-Doku erfolgt monatlich zu den Sprints und wird monatlich intern und zur Veröffentlichung an die Kunden in der Endfassung auch extern zur Verfügung gestellt. Mini-Dokus werden von Entwicklern und Projektbeteiligten in Rohfassung erstellt. Sie sind ggf. kundenspezifische Dokumente.
Um Ihre eigene Kopie von DokuWiki laufen zu lassen, benötigen Sie Folgendes: Quelle: https://www.dokuwiki.org/requirements
Siehe auch Dokumentation zu DokuWiki
In DokuWiki kann administrativ der Hinweis auf vorhandene Udates deaktiviert werden. Leider werden hier nicht nur essentielle Updates sondern auch Prereleases angezeigt. Insofern haben wir uns entschieden, vorläufig in der jeweiligen Branch-Variante diesen Updatecheck in den erweiterten Einstellungen zu deaktivieren. In allen anderen Wiki-Varianten ist Updatecheck aktiviert und kann so schnell zur Information herangezogen werden.
Die beschriebenen Workflows basieren auf der Annahme, dass das Wiki mehrere Programmversionen technisch unterstützt. Pro Programmversion wird ein Namespace benötigt. Das root-Verzeichnis der iX-Wiki-Varianten ist http://srv-dev/xampp/DokuWiki. Für jede Version wird hierunter ein Verzeichnis für die jeweilige Programmversion gepflegt, z. B. http://srv-dev/xampp/DokuWiki/Version.20.22.0/. Die Wiki-Startseite wird über doku.php aufgerufen. Hieraus ergibt sich z. B. der Aufruf http://srv-dev/xampp/DokuWiki/Version.20.22.0/doku.php im Intranet.
Die Startseite in jedem Namespace heißt start.txt. Die Navigationsseite heißt sidebar.txt und liefert den kompletten Menübaum der Version. Allgemeine Bestandteile wie Impressum und Datenschutz sind auf der Startseite hinterlegt und verweisen auf die jeweiligen Seiten des Internetauftritts der CREM SOLUTIONS. Sie können daher als statische, externe Links geführt werden und müssen nur angepasst werden, wenn die Zieladresse in dem Webauftritt (vom Marketing) geändert wird.
Neuerungen werden per Patchnotes/Releasenotes in PDF-Dateiform veröffentlicht. Eine Onlinevariante hiervon ist derzeit nicht vorgesehen. Versionsabhängig werden die Features in den untergeordneten Namespaces redaktionell eingearbeitet.
Namespaces werden derzeit i. d. R. namensgleich nach der Modulbezeichnung organisiert. Die im Root liegende Startseite start.txt wird bei unspezifischem Aufruf der Webseite oder Klick auf das Crem-Logo im Wiki angesteuert. Hier werden interne Links zu den Startseiten der jeweiligen Module sowie weitere externe Links, z. B. zum Impressum angeboten.
Alle externen Links öffnen ihr Ziel in einem separaten Fenster (z. B. Impressum, Datenschutz), alle internen Links wechseln zum Ziel innerhalb der aktiven Seite. Alle redaktionellen Aktionen sind nur im Intranet und erst nach entsprechender Anmeldung zulässig. Sie benötigen teilweise auch administrative Rechte. In der Online-Version im Internet wird die Benutzeranmeldung nicht angeboten. Daher werden Änderungen in den Online-Versionen nur durch Upload (durch SMV) vorgenommen.
Die Verzeichnisstruktur von DokuWiki kann in TortoiseSVN abgebildet werden. Neue Seiten werden geadded, Änderungen committet. Sollten Seiten später umbenannt werden, ist der vorgenannte Ablauf unbedingt zu beachten.
Mit Anlage von neuen Seiten und Überarbeitungen werden weitere Verzeichnisinhalte, z. B. der attic oder Medien bei Nutzung von integrierten Bildern inhaltliche Änderungen erfahren oder interne index-Dateien angepasst. Über das SVN-Archivflag gesteuert erfolgt eine Aktualisierung auf Basis aller Änderungen in DokuWiki-Unterverzeichnissen.
Neben der Wiki-Source für das öffentliche DokuWiki (iX-Wiki-Trunk-Version) kann eine Neufassung gepflegt werden, die in separatem Bereich liegt (iX-Wiki-Branch-Version)
Der Browserpfad srv-dev/xampp/DokuWiki/trunk/doku.php?id=berichtscenter:excel_berichte:system hat ein Pendant im Serverpfad: \\srv-dev\DokuWiki\Trunk\data\pages\berichtscenter\excel_berichte\system.txt ⇒ nach id= ist im Browserpfad der Pfad innerhalb des pages-Verzeichnisses auf dem Server abgebildet.
Bei jeder Aktualisierung kann in DokuWiki eine Bemerkung für die Wiki-Historie gesetzt werden. Auch wenn die Anzeige der Historie ausgeblendet ist, werden diese Informationen erfasst. Diese Historieninformation erfassen wir nicht dauerhaft, insofern nur bestimmte Dateien per SVN in TortoiseSVN archiviert werden! Beim SVN-commit wird eine Bemerkung für die SVN-Historie gesetzt. Hier ist zumindest die Wiki-Version als Auslöser zu benennen.
Mit der Branchvariante besteht im Intranet eine parallele Variante. Die Branchversion halten wir bis zu einem bestimmten Zeitpunkt mit der Trunk-Version parallel und werden sie dann gezielt weiterentwickeln. Hierzu planen wir eine Versorgung via TortoiseSVN und mergen nach bestimmten Regeln. Die Branchversion des iX-Wiki wird in der Aufbauphase nicht online gestellt. Dies ist der jeweiligen Trunkversion vorbehalten ⇒ iX-Wiki Onlineversion.
Details zum Zusammenspiel mit TortoiseSVN siehe Abschnitt SVN-Anbindung.
Der verwendete Server (s. Kapitel Doku-Wiki-Voraussetzungen) unterstützt PHP und Dateien (Text-Dateien, CSS, PHP, Mediendateien, …). Durch die Zugangssteuerung im DokuWiki sowie das administrative Ausblenden von nicht öffentlichen Namespaces können auch noch nicht öffentliche Anpassungen an den Webserver übertragen werden. Eine Übertragung an den Webserver ist erforderlich, wenn eine öffentliche Komponente aktualisiert wurde.
Hierzu könnte eine Meldung in SVN erfolgen, die als Trigger für den FTP-Upload genutzt wird (spezieller Commit-Kommentar). Übertragen werden alle Dateien und Verzeichnisse, welche neu oder mit neuerem Datum im Quellverzeichnis vorliegen. Derzeit wird das Serverupdate manuell gestartet. Nur die Trunk-Version wird so öffentlich. Idealerweise sollte der Trunk wöchentlich aktualisiert werden, parallel zu den Patches. Wegen des manuellen Aufwands wird diese Aktualisierung nur auf Anfrage und nach Abstimmung mit der Redaktion erfolgen.
Die Frage, ob der Branch nicht am besten als Kopie des Trunk erzeugt und erst im letzten Quartal mit neuerungsspezifischen Anpassungen und Erweiterungen ergänzt wird wurde zusammen mit SMV diskutiert. Das von SMV eingezogene Zwischenverzeichnis T1-Smv ist derzeit von den Redakteuren nicht in separaten Update- und Commit-Prozessen zu berücksichtigen, es wird automatisch bedient, wenn Update- und Commit-Prozesse für das Trunk-Verzeichnis (Version 20.20.0) ablaufen.
nodisp 2-Klammer vorbereitet werden. Sie sollten dann entsprechend intern auffindbar kommentiert sein (für Volltextsuche vorbereitet). Beispiel: <nodisp 2>FIXME Version BRANCH 20.20.2 …. </nodisp>
Dateilöschungen sollten durch entsprechend sorgfältiges Arbeiten zur Ausnahme gehören. Löschungen sind daher von Anfang an zu kommentieren und müssen manuell begleitet werden. Betrifft die Löschung einer Datei/eines Verzeichnisses eine schon upgeloadete Komponente (Datei/Verzeichnis), muss diese administrativ auch auf dem Server analog gelöscht werden.