Masterthese

TODO

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

Fragestellungen

• Lässt sich aus einem Modell automatisiert Konfiguration erstellen (bzw. wie weit ..)
• Können Abhängigkeiten so abgebildet werden, dass diese beim Deployment berücksichtet werden
• Kann festgestellt werden, ob ein Deployment erfolgreich war (bezogen auf Abhängigkeiten)
• Kann die Atomarität eines Deployments gewährleistet werden
• Kann ein Rollback automatisiert erfolgen

=> bei den Anforderungen, dort allerdings als Fragestellungen formulieren (... ergeben sich folgende Fragestellungen)

=> bei den Anforderungen im Architekturteil darauf eingehen und Anforderungen ableiten!

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!

• Tests: mit Arquillian könne Tests direkt am Server im EE Umfeld ausgeführt werden. Dafür wird eine Konfigurationsdatei benötigt. Diese kann z.b aus DSL generiert werden.

• Wenn Datenbank aus Deployment-Diagramm beim XMI Export betrachtet wird, können auch gleich Entity Klassen generiert werden

• Artifakt Setup: Maven Modul kann auch via DSL generiert werden (pom.xml, struktur, entities, services, webservice)

• Scheduling von Deployments: Deployment Jobs persistieren und via Webservice übermitteln: zusätzlich zu normalen parameter müsste nur ein zeit-fenster übermittelt werden, in einer job tabelle der request samt zeitpunkt persistiert werden.

• Modellierung kann für automatisiertes Provisioning genutzt werden

Benefits

• D4U kann in einem CI Tool verwendet werden, um nach einem Build ein automatisiertes Deployment auf eine Stage durchzuführen, auf der beispielsweise Acceptence Tests laufen

• flexible nutzung: via webservice z.b. scheduling von deployment-jobs möglich

• möglichkeit: generierung von deploy-controller

Einschränkungen

• Scripts werden lokal (auf host, auf dem d4u läuft) ausgeführt!

=> einbauen dass via ssh oder schtasks etc.
=> eventuell: flag "run-remote" um anzuzeigen dass script remote ausgeführt werden soll

• Berechtigungskonzept: Eigentümer könne Rechte für JEDE Stage vergeben => soll nicht sein!
• Berechtigungskonzept2: Stage-Manager soll für diese Stage Rechte vergeben können

• beim Deploy von Komponenten kann jede Version gewählt werden, unabhängig davon ob das technisch funktioniert (Versionen zusammen passen). genauso kann eine einzelne Komponente in einer Version deployt werden und das Deployment wird funktionieren, wenn eine Abhängigkeit (irgendeiner Version) bereits deployt ist. Das ist der Trade-off von Flexibilität und Funktionssicherheit (todo: formulierung).

• round-trip engineering nicht möglich

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
• rechte testen: deploy und config (stage-manager, etc. )
• wrapper um service zu stoppen/starten
• version-filter bei stage: bei deploy implementieren
• wenn die ausführung eines jobs weder success noch failed nachsich zieht (weil z.b. abgeschmiert .., runtime-error, blocked, ..) kriegt der deploymentManager das nicht mit: daher periodisch checken welche jobs schon über das timeout hinaus laufen, diese auf failed setzen
• <<redundant>> stereotyp im deployment diagramm (bzw. xmi) auswerten => mehrere nodes generieren

Thesis TODOs

• check-url: monitoring servlet
• irgendwo beschreiben wie checks und datenmirgation gelöst sind
• bei diskussion: flexibilität, daher auch für clould-deployments möglich

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 (Tomcat-Controller macht fallback auf server-name)

windows remote command exection

• für powershell scripts

invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1
Invoke-Command -ComputerName 7-90 -ScriptBlock { start-process "C:\temp\test.bat" }
=> problem: powershell muss verfügbar sein und verwendet werden und richtig konfiguriert sein,

möglicher Fehler:

CategoryInfo          : Sicherheitsfehler: (:) [Invoke-Command], PSSecurityException
FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.InvokeCommandCommand

oder, wenn winrm nicht konfiguriert ist:

+ CategoryInfo          : OpenError: (7-90:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : CannotConnect,PSSessionStateBroken

• 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

• oder windows remote management

winrs -r:REMOTECOMPUTERNAME command to run
=> Problem: muss configuriert werden