Page History

Version Control Systems

• 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.

Steps

1. JobScheduler objects are usually administered in a development environment, either using 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.

1. Das live-Verzeichnis ist im SVN-Repository bekannt, die Objekte sind eingecheckt. Das Repository liegt auf einem "zentralen" Server.

1. Autorisierte Nutzer sind eingerichtet.

1. Änderungen im live-Verzeichnis werden, nach Test (und evtl. Abnahme), von den dazu autorisierten Nutzern in das Repository übernommen (committet).

1. 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.

1. 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.

1. or using a code editor.
   • Ensure that the JobScheduler "live" folder is known to the SVN repository and check-in the objects. The repository usually resides on a central server.
   • Authorise users for SVN.
2. After testing (and eventual approval) of changes to the live folder then they will be are committed to the repository by an authorised user.
3. 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 individually selected objects. 
   • The XML files are then to be marked as being read-only. 
   • It could be worthwhile to write a job to carry-out an automated task for this at regular intervals. 
   • This means that a change to the production environment is only possible via the repository.
4. The repository reporting functions can then be used to determine "who, when, what, why and how" a change was made.

Users are asked to provide a reason for a change being made during the "committing" 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.

Notes

• Note that both the check-in of objects to the repository and the update of objects in the production environment can be carried out using scripts (ANT or command line scripts) or using the tortoiseSVN GUI.
• Note that the two stage process described here could easily be extended to three with quality control and approval testing forming the second stage

...

• .