Domino 9 und frühere Versionen > Entwicklung

Designkontrolle per Script

<< < (2/3) > >>

Hugi23:
So war das nicht gewollt, dass ich hier nun Stück für Stück die ganzen Gründe und Argumente aufliste, die mich zu dieser Idee gebracht haben. Na klar kann ich eine Versionsnr. einführen. Die nützt mir aber nichts.
Bsp.: der Server A, von dem aus die Schablone repliziert wird, hat in der ACL der Schablone des Servers B Entwicklerrecht. Soweit prima. Aber! Ein leider auch mal Fehler machender Admin hat vergessen, dem Server A auch die Option "Erstellen von pers. LotusScriptAgents" zu geben. So! Nun stelle man sich vor, dass man im Titel oder sonstwo die Versionsnr. hinterlegt. Prima - denn das wird ordnungsgemäß repliziert. Auch eine ggf. geänderte Maske wird 1A repliziert. Aber da ist ein neuer Script-Agent dazugekommen. Den kann der arme Server A nicht in der Schablone von Server B plazieren, weil er die Option nicht hat. D.h. dem Nutzer würde nach der nächsten nächtlichen Design-Anpassung vorgegaukelt, dass die neue Version da ist. Er hat sogar die korrigierte Maske. Aber der Aufruf des (Script-) Agents schlägt fehl. Auf denn zur ewig dauernden Fehlersuche. Davon könnte ich noch viele Bsp. bringen.
Also: ich versuche das mit dem "Item-reinbringen". Danke :-)

Axel:
Hi,

warum replizierst du denn die Schablone durch die Gegend? Lass doch die Schablone auf einem Server. Dieser macht dann das Gestaltungsupdate und bei der nächsten Replikation der Datenbank wird die Gestaltungsänderung an alle Repliken weitergegeben.

So mache ich das schon jahrelang und hatte noch nie Probleme.

Axel

flaite:
Ich halte deinen Vorschlag für offen gesprochen naiv.
Das ganze führt zu einem gewaltigen Verwaltungsaufwand, der den zweifelhaften Nutzen einfach nicht rechtfertigt.
Änderungen in der Gestaltung werden auch nicht irgendwie chaotisch vorgenommen sondern in Folge eines change requests. Design changes in einer Anwendung von realistischer Komplexität heisst aber in der Regel nicht, dass da ein Agent "dazugestrickt" wird. Es betrifft oft die Änderung von einer Menge von Gestaltungselementen. Dh. du müßtest dann auch ein Mapping von dem change request auf die in Folge des change request geänderten Gestaltungselemente erstellen.

Sorge also für einen vernünftigen Testprozess, setze vernünftige Dokumentationsrichtlinien durch und sorg dafür, dass sich alle an diese Prozesse halten.

Qualität ist nix, dass man durch exzentrische, kreative Ideen in eine Organisation hineinbekommt, sondern durch vernünftige Prozesse und eine Kultur, in der diese Prozesse auch befolgt werden. Die Prozesse sollten möglichst einfach sein. Spaß machen sie aber nie. 

Es gehört zur Tragik dieser Branche, dass Entwickler dies viel besser verstanden haben als Manager.

Axel

 

Hugi23:

--- Zitat von: kennwort am 10.11.05 - 14:17:33 ---Ich halte deinen Vorschlag für offen gesprochen naiv.
kennwort

--- Ende Zitat ---
1. Danke für die klare und deutliche Einschätzung.
2. Ich würde die Diskussion über "warum mache ich das eigentlich?" mit diesem Beitrag gern abwürgen. Mir war nicht bewusst, dass man eine technische Frage erst begründen muss, bevor man sie stellt. Aber ich bin noch ein Frischling.
3. Bernhards Aussage war ausreichend. Das Abspeichern des kompletten Designs in einer Teilmaske funktioniert hervorragend. Ein DB-Nutzer kann im Ernstfall jetzt erkennen (und mir das mitteilen), von welchem Stand sein Design ist (Änderungsdatum der Liste) und ob was fehlt (Differenz zwischen Liste und vorhandenen Elementen). Bernhard - nochmals vielen Dank! Die Ursachen eines evtl. veralteten Design-Standes oder einer evtl. Unvollständigkeit wollte ich nicht in diesem Forum klären. Aber - und damit zu
4. Zum allg. und abschließenden Verständnis: Es handelt sich um eine "sehr kleine" Organisation. Wir sind lumpige 120.000 User mit gerade mal 1.500 Servern und einer Unmenge an "administrativen und organisatorischen Fürstentümern", die sich hinsichtlich der Verfügbarkeit von Schablonen, Datenbanken etc. nicht reinreden lassen. Mir kommen bei 'kennworts' wahren Worten nicht mal mehr die Tränen. An dieser administrativen Struktur muss ich leider allzu oft als "Helfer in der Not" vorbei. Würde ich in solchen Momenten erstmal an Disziplin und Ordnung appellieren, würde das den Betroffenen nur ein müdes Lächeln abringen und mich zum Bürokraten abstempeln. So etwas Tolles wie einen zentralen Schablonenserver versuchen wir seit Jahren zu etablieren - leider vergebens. Aber vielleicht klappts mit der Migration auf R7.

flaite:
Ich finde das immer noch naiv.
Kenne eine Menge Organisationen mit größeren Domino-Installationen.
Davon gibt es genau 2 Sorten:
- Sorte a hat begriffen, dass gerade in solchen Organisationen eine effiziente, schlagkräftige Organisation des IT Betriebs zwingend notwendig ist.
- Sorte b diskutiert permanent über Fürstentümer, ihre unglaublich komplexe Topologie, usw.

Ich war selber an einigen "kreativen", "cleveren" Workarounds beteiligt und mußte als Externer permanent ein hohes Risiko nehmen, da in solchen macht- und nicht effizienz-orientierten Strukturen am Ende sowieso immer "der Entwickler" Schuld ist. Ich habs soweit auch hinbekommen.
Nur ist mir dort exemplarisch klargeworden, dass solche Organisationen irgendwann sowieso outgesourced werden.
Wenns wirklich so arg ist, würd ich eine entsprechende Consulting nehmen (ich bin kein Orga-Consulting), die das geradezieht.
Es gibt übrigens Organisationen mit größeren Domino-Installationen, die sich wirklich bemühen den Müll zu entsorgen und das ganze möglichst effizient auszurichten. In nicht-Domino Bereichen, die ich mitbekomme (J2EE, Administrations-Automatisierung), ist ein solches marktkonformes Denken aus meiner Erfahrung stärker ausgeprägt.

Es ist aus meiner Sicht der Schlüssel der IT in einem Hochlohnland wie Deutschland.
Dieser ganze "realistische" Quatsch mit den Fürstentümern, Flexibilität und 120.000 Workarounds mag ihre Welt sein. Mittelfristig überlebensfähig ist es nicht.

mfg Axel Janßen

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete