Projektübergreifend effizient arbeiten

Auch wenn ich diesen Artikel in die Kategorie Nebensachen eingeordnet habe, sollte man das Thema nicht komplett ignorieren, denn es ist ein wichtiger Aspekt von effizientem Arbeiten. Es gipfelt in der Frage: Wie schaffe ich es, meine Arbeitsumgebung quasi mitzunehmen, also immer dort, wo ich gerade arbeite, verfügbar zu haben? Konkret will ich mich in diesem Artikel auf die MZ-Tools beziehen, aber generell stellt sich diese Frage natürlich auch unabhängig davon.

Wir alle wissen, wie wichtig effizientes Arbeiten ist, und vor allem wie schön es ist 🙂 Wenn ich zum Beispiel an die MZ-Tools denke, dann bin ich jedes mal wieder dankbar dafür, wie einfach es ist, eine neue Funktion anzulegen und diese mit meiner Standard-Fehlerbehandlung zu versehen. Etwas Schreibarbeit, ein Mausklick, und das war’s. Dafür muss ich nur die MZ-Tools einmal richtig einrichten, und schon flutscht das. Aber was bedeutet dieses „nur“?

Routine

Manche Entwickler arbeiten immer an dem selben PC, tagein – tagaus, und das vielleicht sogar jahrelang. Auch wenn sie ab und zu neue Hardware bekommen (was eher selten passiert), kann man von einer relativ stabilen Umgebung ausgehen. Bei mir ist das nicht der Fall, denn ich habe …

  1. meinen PC im eigenen Büro
  2. einen Laptop für gelegentliche Spontaneinsätze
  3. einen PC bei einem Kunden

… und je nach aktueller Projekt-Hektik vielleicht noch einiges mehr. Ich wiederhole meine obige Frage: Was bedeutet es, „einfach nur“ die MZ-Tools einzurichten? Auf jedem Rechner neu? Jedes mal nach dem Hardwarewechsel? Bei jedem Kunden? Und das ist nicht einfach mit ein paar Mausklicks erledigt!

Die Antwort ist meiner Ansicht nach recht einfach: Nutzen wir doch einfach das, was wir ohnehin (hoffentlich) jeden Tag benutzen — die Quellcodeverwaltung. Was liegt näher, als dieses wunderbare Werkzeug auch für die Konfiguration der MZ-Tools einzusetzen? Die erste Frage dazu lautet natürlich: Wo und wie speichern die MZ-Tools ihre Einstellungen? Auch diese Frage ist einfach zu beantworten:

%appdata%\MZTools Software\MZTools8\

Zumindest ist das der Standard-Speicherort, der in den Optionen allerdings nicht nur angezeigt wird, sondern auch verändert werden kann. Eine solche Veränderung stellt die Idee hinter diesem Artikel keineswegs in Frage, es muss dann eben dieses andere Verzeichnis verwendet werden.

Dort liegt dann standardmäßig eine XSL-Datei (XML-Stylesheet) und zwei Ordner: VB6 und VBA (jedenfalls in der Variante, die ich benutze). Darunter gibt es jeweils „PersonalOptions“ und „TeamOptions“. Und darin wiederum liegen eine Reihe von XML-Dateien, die freundlicherweise bereits menschenlesbar (Zeilenumbrüche und Einrückungen) und somit quellcodeverwaltungstauglich formatiert sind. Perfekte Voraussetzungen also.

Tja dann, los geht’s:

%homedrive%
cd "%appdata%\MZTools Software\MZTools8"
git init
git add .
git commit -m "Füge Standard-MZ-Tools-Konfiguration hinzu"

Fertig. Selbstverständlich geht das auch mit TortoiseGit auf der graphischen Oberfläche, und ebenso mit jeder beliebigen anderen Quellcodeverwaltung.

Jetzt müssen wir uns „nur noch“ eine Stelle im Netz aussuchen, wo wir dieses Repository hinschieben („git push“). Dafür gibt es eine Reihe von Cloudanbietern, wie z.B. Bitbucket, Github oder Gitlab.

Mein Repository liegt hier.

Nach der Installation

Nach der ersten Installation der MZ-Tools wird es an der oben genannten Stelle eine Standard-Konfiguration geben. Wer diese ignorieren möchte, kann seine eigene Konfiguration aus dem Git-Repository darüber clonen (vorher Access beenden und die an der o.g. Stelle bestehenden Dateien löschen, da Git sonst meckert).

Und nach jeder Änderung solltest du diese committen und pushen, damit diese Änderungen später auch in deinen anderen Umgebungen verfügbar sind. Dort sollte dann natürlich ein pull erfolgen, sonst hat man nichts davon. Aber da dieses Repository vermutlich nur von dir selbst genutzt werden wird, solltest du selbst am besten wissen, wann du was tun musst.

Ausblick

Hierzu bietet es sich vielleicht an, einen Blick auf meine Idee Gitnote (Blogpost, Repository) zu werfen. Möglicherweise lassen sich die dafür benötigten Mechanismen mit der Konfigurationsverwaltung kombinieren.

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

One thought on “Projektübergreifend effizient arbeiten

  1. Pingback:

Kommentar verfassen