Masterthese

TODO

• UML Deploy Diagramm
• Softwarebücher: Deploy, Installation
• Recherche: Installability
• Fowler Patterns: Deploy, Command Pattern
• Anforderungen an Deployer

Externe Service

Ist eine externe Komponente in der Deploy-Liste nicht angeben und ist diese nicht als deployed gekennzeichnet (im letzten deploy) => Fehler

Ist die externe Komponente angeben, aber ohne version, erfolgt nur check ob deployed, sonst auch version.

Sematik von Deploy externer Komponenten: Check-Script oder Check-URL erfolgreich!

deploy ausgewählter componenten

wenn nicht in Deploy-Liste angegeben, erfolgt nur Check ob Komponente deployt ist (Version ist egal).

Soll auf bestimmte version geprüft werden, dann mit Version, ohne Redeploy angeben.

rollback

neue deployment entität, previous zeigt auf fehlgeschlagenes deployment. is_rollback auf true gesetzt. checks werden ausgesetzt.

Ideen

• Version: welche Version deployt ist, lässt sich an der pom Datei herauslesen, die im Zuge der maven compile Phase in das META-INF Verzeichnis kopiert wird. Anhand der Version kann auch ermittelt werden, welche Daten-Migrations-Vorgänge ausgeführt werden müssen.

• Config für Container muss auch Feld für args haben (z.b. bei Glassfish: -domain xy)
• Config für Timeout bei deploy (dann gilt es als fehlgeschlagen), überschreibbar auf Applikations-Ebene

• maven plugin: um z.b. via hudson mit mvn d4u:deploy deployen zu können

• wenn application nicht in repository, sondern nur einzelne komponenten, muss mit versionsangaben der komponenten deployt werden können

• Javadoc in Masterthese als Anhang!

TODOs

• testen von deployment
• testen von rollback
• reparieren config-service (i.e. merge), inkl. rechte für stageManager
• service für suche
• service für get-status

Service Attribute (richtiger Begriff? TODO: recherchieren)

• Abhängigkeiten: weiche, harte (i.e.: Version muss passen oder Komponente muss nur verfügbar sein)
• Abhängigkeiten: müssen zur Laufzeit vorhanden sein, oder müssen bei Systemstart verfügbar sein
• Soziale Aspekte: Akzeptanz (ad Tool Verwendung: z.b. EA ist allgemein bekannt, mehr Chancen dass ein modellbasierter Ansatz erfolgreich ist bei dessen Verwendung)

Begriffe

• Node entspricht z.b unter Tomcat einem Context
• Für Tomcat vermutlich eher nicht sinnvoll dass ein Job nur einen Server enthält, aber mehrere Nodes
• Für GF eventuell sinnvoll: Cluster mit einem Artifact, einem Server, auf mehrere Kontexte verteilt
• Daher ist Node-Name => Context-Name unter Tomcat, Applications-Name unter Glassfish
• Für Tomcat wird daher das war-file in node-name + extension vom artifact umbenannt
• Backups bei Tomcat daher für jeden context(=node) extra
• Node-Name darf daher nicht unique sein, aber kombi node-name<->stage schon
• für domains bei glassfish: für jede domain eigener server!
• Server: Service-Name sowie start/stop script ist in RUN_CONTROL gespeichert

windows remote command exection

• für powershell scripts

invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1

• sonst mit schtasks.exe

 schtasks.exe /Create /S 7-90 /SC Einmal /TR c:/temp/test.bat /TN test /ST 10:36
=> Problem: /TN taskname, bleibt auch nach ausführung bestehen. /ST muss angegeben werden