Version control systems such as the open source Subversion (SVN) can be used to keep track of changes made to JobScheduler objects. The following example illustrates how this can be done using SVN:
- JobScheduler objects are usually administered in a development environment, either using
JOE-I, the now superceeded ManagedJob interface or using a code editor. - Make the JobScheduler "live" folder known to the SVN repository and check in the objects. Das Repository liegt auf einem "zentralen" Server.
- Authorise the users for SVN.
- Changes in the "live" folder are, after testing (and eventual approval), included (committed) in the repository by an authorised user.
- Objects are added to the production environment from the repository using the export or update functions. This can either be done for all or for individual selected objects. The XML files are then to be marked as being "read-only". It could be worthwhile to write a job to carry this out automatically and periodically. This means that a change to the production environmet is only possible via the repository.
- The repository reporting functions can then be used to determine "who, when, what, why and how" was a change made.
Users are asked to provide a reason for a change being made during the "commiting" process such as the change request or ticket id. At the same time the user and what has been changed is recorded in the repository. This also applies for other SVN functions. In addition to providing version control, SVN also provides a tool for comparing versions.
Note that both checking in objects to the repostory and their addition to the production environment can be carried out using scripts (ANT or command line scripts) or using the tortoiseSVN GUI.
Note also that the two stage process described here could easily be extended to three with quality control and approval testing forming the second stage.
In the longer term it is plaanned that JobScheduler will not only be able to access file system objects but also directly access the repository.
<!--Es ist möglich über den Einsatz eines Versions-Control Systems, wie zum Beispiel Subversion (SVN; open source). Dabei kann, am Beispiel SVN, wie folgt vorgegangen werden:
- Die Pflege der JobScheduler-Objekte erfolgt grundsätzlich in der Entwicklungsumgebung, entweder mit JOE (JobScheduler Object Editor), mit der ManagedJob Oberfläche oder mit einem beliebigen Editor.
- Das live-Verzeichnis ist im SVN-Repository bekannt, die Objekte sind eingecheckt. Das Repository liegt auf einem "zentralen" Server.
- Autorisierte Nutzer sind eingerichtet.
- Änderungen im live-Verzeichnis werden, nach Test (und evtl. Abnahme), von den dazu autorisierten Nutzern in das Repository übernommen (committet).
- Auf der Produktionsseite werden die Objekte aus dem Repository in das live-Verzeichnis der Produktion übernommen (Funktion export oder update). Dies können entweder alle oder ausgewählte Objekte sein. Die XML-Files sind danach als "read-only" zu markieren. Eine solche Übernahme könnte auch durch einen (noch zu erstellenden) Job automatisch und zyklisch erfolgen. Eine Änderung in der Produktionsumgebung ist damit zunächst nur über das Repository möglich.
- Reporting-Funktionen des Repositories können verwendet werden, um nachzuweisen, "wer, wann, was, wozu und wie" verändert hat.
Bei jedem "commit" gibt der Nutzer einen Grund (zum Beispiel die change-request- oder ticket-id) an. Gleichzeitig merkt sich das Repository, welcher Nutzer wann etwas geändert hat. Dies bezieht sich auch auf andere Funktionen des SVN. Gleichzeitig ist auch eine Versionierung der Objekte realisiert sowie die Möglichkeit, Versionsstände zu vergleichen (Funktion compare).
Sowohl das einchecken in das Repostory als auch das übernehmen in Produktion kann script-gesteuert (ANT, command-line scripts) oder per GUI (tortoiseSVN) erfolgen.
Das hier beschriebene zwei-stufige Verfahren kann auch erweitert werden zum drei-stufigen, wobei dort die zweite Stufe dann die Qualitätssicherung und der Abnahmetest sein kann.
Perspektivisch ist es gedacht, daß der JobScheduler nicht nur auf Objekte im File-System, sondern zum Beispiel auch direkt auf das Repository zugreifen kann.-->