Das Notes Forum

Best Practices => Diskussionen zu Best Practices => Thema gestartet von: smoky am 10.01.12 - 15:34:17



Titel: Datenbank Änderungen protokollieren
Beitrag von: smoky am 10.01.12 - 15:34:17
Hallo,

Ich stelle meine Frage mal zu Best Practices da mir vorkommt als würde es passen :-)

Ich suche den besten Weg um jede Datenbank Änderung zu notieren und auch wieder zu finden, leider mußte ich feststellen das ich mir doch nicht alles merke was ich so tue.
Bei manchen Datenbanken habe ich Änderungen direkt vermerkt für andere habe ich noch "fliegende" Notizen, ich war in den letzten Jahren nicht sehr konsequent und Pflichtenhefte hatte ich nur bei den ersten DB's.
Also meine Frage: Wie geht man hier am besten vor? Was könnte mal als "Best Practices" vorschlagen?

schöne Grüße aus Wien
Christine


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: smokyly am 10.01.12 - 16:01:15
Also wir haben ein Ticketsystem mit angeschlossener Knowledge-DB.
Darüber wird alles dokumentiert. Besser gesagt - sollte.
Mit Vorher-Nacher und Auftraggeber / Problem-Melder, Zeiten, Fertigstelltermin, etc...

Gruss


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: koehlerbv am 10.01.12 - 16:09:45
Das ist ein weites Feld, Louise Christine ...

Ich glaube, hierfür wird es keine zwei Organisationen geben, die das jeweils identisch handhaben.
Es diskussionswürdiges Thema für AtNotes ist das aber allemal (IMHO).

Erstmal Fragen zu Deiner Umgebung, denn jede Theorie ist hier witzlos:
- Wieviel Leute sind an der Entwicklung beteiligt?
- Sind diese alle unter einer Kontrolle?
- Was muss überhaupt protokolliert werden?
- Welche Vorstellungen hast Du für eine Systematik der protokollierten Änderungen?
- Wie komplex sind die Anwendungen?
- Wer wird die Protokolle später lesen*?
- Stehen Dir Notes-spezifische Tools zur Verfügung (insbesondere von Teamstudio), die Dich im Prozess der Änderungs-Dokumentation unterstützen können?

*) Mir als Entwickler reicht beispielsweise ein aussagekräftiger Header (warum, wie, was kommt raus, Ersteller, letzter Änderer und eine *komplette* Liste der wesentlichen Änderungen in der jeweiligen Routine). Was in Ansichten oder Masken geändert wurde, ist mir i.d.R. wurscht, hier protokolliere ich nur, wenn etwas auf den ersten Blick komplizierter aussieht als nötig und erläutere das Warum dahinter.

Ich gehe bislang davon aus, dass Du mit "Datenbank-Änderung" Design-Änderungen meinst. Musst Du ggf. auch (systembedingte) Dokument-Änderungen gegenüber einer Revision darlegen? Da sieht die Sache schon wieder ganz anders aus.

Bernhard


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: sral am 10.01.12 - 16:12:15
Hallo Christine,

wir haben ein Release System, welches von den Schablonen eine Kopie auf ein Netzlaufwerk erstellt.
Der Entwickler ändert die Schablone...dokumentiert das im Release Dokument...erstellt die Kopie...übergibt die Änderung an den Admin, der dann die Schablone signiert und einspielt.  
Wenn dann etwas nicht funktioniert, kann der Admin das Vorgängerrelease wieder einspielen.


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: smoky am 10.01.12 - 16:23:22
Hallo Bernhard,

Also mir persönlich geht es hauptsächlich um Änderungen bei Felder, Masken und Ansichten. Wir sind nur zu zweit die Änderungen machen, also persönlich absprechen wäre nicht das Problem, nur eben das merken.
Z. B. habe ich vor ein paar Monaten eine Änderung bei einem Feld in unserer Auftrags DB gemacht und heute habe ich zwei Stunden gebraucht bis mir das wieder eingefallen ist :-) solange habe ich mich gewundert warum in dem Feld was anderes steht. Also das Protokoll dient dann nur den Programmierer.
Deshalb dachte ich mir es wird Zeit das ordentlich zu machen.

Edit: Tools habe ich keine dafür, aber vielleicht bekomme ich heuer ein kleines Budget dafür.


lg
Christine


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: koehlerbv am 10.01.12 - 16:25:15
Lars: Das sollte jeder halbwegs ernsthafte Programmierer und Admin so machen. Aber eine Protokollierung ist das nun nicht, sondern eine Backup-/Rollback-Strategie. Natürlich sehr wichtig - aber etwas anderes.

Bernhard


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: koehlerbv am 10.01.12 - 16:27:41
Servus Christine,

kannst Du diesen speziellen Fall genauer erläutern? Über Item-Values wundere ich mich in der Regel nicht (oder erkenne einen Programmierfehler), mit vorigen Änderungen hatte das noch nie was zu tun (das "Wundern" meine ich).

Beste Grüsse entlang der Westbahn nach Wien,
Bernhard


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: smoky am 10.01.12 - 16:54:36
Hallo Bernhard,

In dem speziellen Fall hatte ich die Maske so angepasst das die Werte einmal in Euro und in einem anderen Feld in der jeweiligen Landeswährung angezeigt wird und das nur für jene Db's der gleichen Art die in Ländern mit nicht Euro Währung verwendet werden. Das heißt eigentlich hat mich nicht der Inhalt gewundert sondern das Währungszeichen.
Im Prinzip hätte ich festhalten müssen das es nun zwei Schablonen gibt die dahingehend abweichen das es einmal ein Währungsfeld gibt und bei der anderen zwei, wobei hier das zweite immer berechnet wird.

Ich habe mir jetzt die Seiten vom Teamstudio angesehen und da sind ja einige interessante Tools dabei, ich fürchte zwar es ist zu teuer, ich habe aber mal nach dem Preis gefragt  :-)


Christine


Titel: Re: Datenbank Änderungen protokollieren
Beitrag von: ata am 11.01.12 - 09:54:04
... die Tools von TeamStudio haben ihren Preis - können aber auch vieles, was du sonst nicht analysieren kannst. Für ein technisches Versionshandling wirklich sehr gut - nur Logik, PseudoCode und ähnliches bekommst du damit nichts hin. Du kannst damit zum Beispiel eine Volltextsuche machen um herauszufinden, wo überall eine Ansicht, Feld, Teilmaske verwendet wird.

Es gibt noch NotesDoc - Abwandlung zu JavaDoc, daß in der Lage ist Kommentare als HTML zu reporten - bedingt aber, daß die Kommentare entsprechend einer Semantik überall aktuell gepflegt und hinterlassen sind.

Und dann kannst du natürlich noch eine eigene Semantik entwerfen und über DXL auswerten - großer Aufwand in der Programmierung...

Daher sind Bernhards Klärungspunkte wichtig...

Toni