You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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:

  1. 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.
  2. Das live-Verzeichnis ist im SVN-Repository bekannt, die Objekte sind eingecheckt. Das Repository liegt auf einem "zentralen" Server.
  3. Autorisierte Nutzer sind eingerichtet.
  4. Änderungen im live-Verzeichnis werden, nach Test (und evtl. Abnahme), von den dazu autorisierten Nutzern in das Repository übernommen (committet).
  5. 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.
  6. 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.

  • No labels