Domino 9 und frühere Versionen > ND6: Entwicklung

Update procedure for database updates

<< < (2/2)

ata:
... so sehe ich das auch. Bei mir sind mehrsprachige Datenbanken und Global Workbench im Spiel, dazu ein Konklumerat an Datenbanken, die alle unterschiedlich zu handeln sind. Agenten benötigen je nach Situation die unterschiedlichstenb ID's usw. usf.

Toni

koehlerbv:

--- Zitat von: michanp am 28.03.07 - 09:00:33 ---Wir bekommen allerdings keine vernüftige - um nicht zu sagen gar keine - Doku dazu, so daß regelmässig was schief geht.
--- Ende Zitat ---
Vollkommen unverständlich. Warum nehmt Ihr den Schrott dann ab oder an?


--- Zitat von: michanp am 28.03.07 - 09:00:33 ---Z.B. Replace or Refresh Design, ACL-Änderungen, notwendige Signaturen, Installationspfade etc...
--- Ende Zitat ---

- Replace oder Refresh sollte eigentlich egal sein - oder der Programmhersteller muss eindeutig darauf hinweisen. Replace schadet aber nie.
- ACL-Änderungen: Diese müssen nun wirklich vom Programmhersteller genannt werden - da kann hier niemand helfen!
- Installationspfade: Wenn sich da bei einem Update etwas ändert ... Herrjeh, das weiss nun wirklich nun der Programmhersteller.

Wenn Euch der Programmhersteller dermassen im Stich lässt, dann solltet Ihr vielleicht mal grundsätzliche Überlegungen anstellen. Die Forumsgemeinschaft  kann da nicht helfen.

Bernhard

flaite:
Im Unified Process Umfeld spricht man hier wohl von supportability (adaptability, maintainability, internationalization, configurability).
Da drückt oft der Schuh und zwar nicht nur im Notes Umfeld.
Die Checkliste mußt du dir wohl selber erstellen. Kann man als Wiki machen. Word Dokument geht aber auch. Mit der Zeit solltet ihr dann einen realistischen Überblick bekommen. Eventuell können einzelne Schritte durch Skripte automatisiert werden. Aber das hat seine eigenen Probleme.

Ich hab mal in einer großen Organisation gearbeitet, in der die das automatisiert haben. Es gab mehrere Skripte, viel als ausgelagerte lss Datei. Erschwerend kam dort hinzu, dass neue Releases an mehrere, im Grunde eigenständige Organisation verteilt wurden. Die "große Organisation" war aber z.T. eben für die IT von den eigenständigen Organisationen zuständig.
Das Skript selbst war aber so komplex und vielleicht auch nicht so gut dokumentiert, dass sich da keiner so recht rantraute. Die Verantwortlichkeiten dafür waren auch imho unterspezifiziert.
Das sind die Risiken von automatisierten Lösungen.
 
Falls ihr Produkte/Projekte eingekauft habt und die sind schwer zu administrieren/upgraden, solltet ihr die Punkte sammeln und gut vorbereitet ein bischen Druck auf euren Ansprechpartner von denen ausüben. Vielleicht konzentrieren sie sich dann auf diesen Punkt, für den berechtigter- und rationalerweise die Anforderungen der Anwenderorganisationen steigen.

Eigentlich muss man bei der Programmierung jeder einzelnen Komponente sich Gedanken über die Betriebskosten machen. Es ist nicht einfach, aber es geht. Und es ist wichtig.

Im Lotus Umfeld kommt dann oft "Ja, aber es gibt doch Schablonen". Und im Java Umfeld "Ja, aber es gibt doch ant und maven". Das ist aber so einfach nicht wahr. Der Teufel steckt im Detail.

Lange Rede, kurzer Sinn: Erstell dir mal eine realistische Liste. Trag das Wissen in eurer Organisation zusammen. Das ist zwar voll langweilig, lohnt sich aber imho.

Micha-BRLN:
Hi,

Erstmal Danke für die rege Beteiligung. Ich kann Eure Meinungen nur nachvollziehen.

Mal informationshalber ´ne grobe Situationsbeschreibung: eine unserer Abteilungen ("Wir verdienen hier das Geld!") hat sich ein paar osteuropäische Entwickler eingekauft und schmeisst uns jetzt mit Applikationen zu. "Entwickler-Doku gibt es nicht; ist zu teuer!"; nicht mal eine Versionierung gibt es... Am schlimmsten - diese Abteilung hat sich auch noch durch gesetzt, Apps werden nun kommentarlos eingespielt (nach der Versicherung, daß die App./ das Update dem Notessystem nicht gefährlich wird....) Die technische Schnittstelle aus dieser Abteilung ist ebenfalls nicht kooperativ....  :-(

Ich bin jetzt dabei eine kleine Applikation zu schreiben, in der neue Apps oder Updates als Reuqest hinterlegt werden. Für die entsprechenden Maske hatte ich jetzt nach einem groben Procedure als Grundlage gesucht... Nach dem Motto - warum das Fahrrad zweimal erfinden?

Aber Ich merke schon - muss wohl selbst ran   8)

Beste Grüße,

Micha

Dann werd ich mich mal an die Arbeit machen.

Navigation

[0] Themen-Index

[*] Vorherige Sete