 |
Doctor Deploy: software deployment, - distribution, repackaging, msi, windows installer, client management, installation, setup : forum - discussion boards
|
| Author |
Message |
RPL
Melchior

Joined: 13 Jun 2004
Posts: 6
Location: Germany
|
Posted:
Fri, 27.Oct.2006, 00:49 |
 |
Hi IBI, hier wie eben zugesagt,meine "Aufklärungsarbeit" im OffTopic.
Gruß
Roman
1 Einleitung
Die Softwarepaketierung wird oftmals als „Nebenbei-Tätigkeit“ angesehen. Im Laufe der letzten Jahre hat sich allerdings das Bild etwas gewandelt. Die Softwarepaketierung ist mittlerweile ein eigenständiges Berufsfeld mit expliziten Spezialisten-Profilen (wie selbst die Gartner Group im Rahmen ihrer Analysen feststellte).
Diese Erkenntnis hat stand Heute nur ansatzweise den Markt durchdrungen. Aufgrund dieser (in gewisser Weise) Falscheinschätzung, treten häufig in vielen Situationen die gleichen Probleme auf:
- Paketierung wird Unterschätzt.
- Paketierung wird an verschiedenen Stellen im Unternehmen durchgeführt
- Know How muss demzufolge an verschiedenen Stellen redundant aufgebaut und gepflegt werden.
- Fehler auf Grund Know How Mangels treten auf.
- Der Gesamtprozess leidet auf Grund einer mangelhaften oder nur ausreichenden Qualität.
- Der Service „Paketierung / Anwendungsbereitstellung“ entwickelt sich zum Reizwort in den Unternehmen.
Die Mitarbeiter in der Paketierung sind in letzter Konsequenz für einen erfolgreichen Applikationsbetrieb verantwortlich, da nur durch ihren (qualitativ hochwertigen Output – das Paket – ) die entsprechende Applikation automatisiert verteilbar und installierbar ist.
Wenn der Softwarepaketierer nicht in der Lage ist, sich in dem Paketierungs-Workflow sicher zu bewegen, dann steigt die Wahrscheinlichkeit, dass sich das Unternehmen / die Abteilung / der Softwarepaketierer in kurzer Zeit mit einer Vielzahl von Problemen konfrontiert sieht.
In den nachfolgenden Abschnitten wird versucht, die Rolle des Softwarepaketierers greifbarer und verständlicher zu machen.
2 Die Rolle des Softwarepaketierers
2.1 Definition
Der Softwarepaketierer ist Mitarbeiter einer Softwareverteilung oder Softwarepaketierung eines Unternehmens. Er erstellt nach Vorgaben seines Kunden Softwarepakete zur automatischen Verteilung und Installation durch ein Softwareverteilungssystem.
2.2 Einordnung nach ITIL
Sollte eine Einordnung dieser Rolle nach ITIL erfolgen müssen, so sind die Paketierungsmitarbeiter dem Anwendungsentwicklungsbereich oder einem Entwicklungsnahenbereich untergeordnet.
Nach ITIL ist das Application Management für die Erstellung von Softwarepaketen verantwortlich. Diese Behauptung beruht vor Allem auf der Tatsache, dass für die Entwicklung einer Installationsroutine oftmals Anwendungsentwicklerwissen gefordert ist. Das Release Management ist für den Release-Test und die Release-Verteilung zuständig. Das Change Management wiederum übernimmt die Kontrolle und die Steuerung.
Oftmals wird auf Grund des Spezialistenprofils „Softwarepaketierer“ die Tätigkeit der Softwarepaketierung in einem eigenen Bereich angesiedelt. Dieser Bereich muss sowohl systemnah als auch anwendungsbezogen agieren.
Die Tätigkeit der Paketerstellung setzt in erster Instanz keine Beherrschung einer Programmiersprache voraus, so dass mit Recht das ITIL Modell an dieser Stelle teilweise in Frage gestellt werden kann bzw. sollte.
In der Praxis wird die Tätigkeit der Paketerstellung fast überwiegend im Bereich des Release Managements (RM) angesiedelt. Dieses ist begründet durch die Tatsache, dass eine Release Unit im normalen Sprachgebrauch mit einem Paket gleichgesetzt wird.
Da das RM für die Erstellung und den Test der Release Units (und des Releases) zuständig ist, kann dadurch begründet werden, dass ein Paketierer ein RM – Mitarbeiter sein kann / sollte.
Letztendlich gibt ITIL an dieser Stelle jedoch nur Hinweise und keine Vorgaben!
2.3 Qualitätssicherung
Der Softwarepaketierer ist ausschließlich für die technische Funktionsfähigkeit seines Pakets verantwortlich. Er hat durch geeignete Qualitätssicherungsmechanismen sicherzustellen, dass sein Paket die durch seinen Kunden definierten Anforderungen erfüllt.
2.3.1 Test des Pakets
Der Softwarepaketierer sollte sein Paket auf einem entsprechenden Referenzsystem so produktionsnah wie möglich und nötig auf Umsetzung der Vorgaben und technische Lauffähigkeit hin überprüfen.
2.4 Applikationsbetrieb
2.4.1 Betriebsverantwortung
Der Softwarepaketierer ist ausschließlich für das Erstellen (und Testen) der entsprechenden Pakete zuständig. Alle Belange, die den direkten oder indirekten Betrieb einer Applikation betreffen, obliegen weder seiner Zuständigkeit noch seiner Verantwortung.
Er stellt im Unterstützungsfall eine erhöhte (2nd Line oder 3rd Line) Supportstufe des Applikations-Supportes dar.
2.4.2 Anwendungsverantwortung
Jede eingesetzte Applikation besitzt (im Optimalfall) einen Anwendungsverantwortlichen (Person / Gruppe oder Abteilung).
Ein Anwendungsverantwortlicher / Produktverantwortlicher ist der erste Ansprechpartner für alle Belange des produktiven Einsatzes der betreffenden Applikation.
Er entscheidet über die Konfiguration der Applikation (oftmals in Zusammenarbeit mit anderen IT-Abteilungen oder Fachbereichen).
2.4.2.1 Einbindung in den Beschaffungsprozess
Darüber hinaus ist der Anwendungsverantwortliche oftmals in den Beschaffungsprozess eingebunden, in dem er (in Zusammenarbeit mit den Fachbereichen) die angeforderten Funktionalitäten bewertet und im Rahmen der Beschaffung Produktempfehlungen abgibt.
2.4.2.2 Anwendungsverantwortung in der Anwendungsentwicklung
Bei Unternehmen mit einer eigenen Anwendungsentwicklung ist es ratsam, die Anwendungsentwicklung mit der Anwendungsverantwortung zu betreuen. In der Regel besitzen die Entwickler tiefere (über die Kenntnisse eines normalen Anwenders hinaus) Einblicke in die zu betreuende Applikation
Überlegenswert ist in diesem Zusammenhang ebenfalls, die Teilung der Anwendungsverantwortung in Technik (AE) und Anwendung (User), damit Anforderungen der Anwender durch diese in den AE-Prozess einfließen können.
2.4.3 Produktfreigabe durch den Anwendungsverantwortlichen
Der Anwendungsverantwortliche nimmt mit dem Paketierer zusammen die Applikation auf Lauffähigkeit und Umsetzung seiner Vorgaben hin ab.
Durch die Abnahme (welche entsprechend archivierbar erfolgen sollte) übernimmt der Anwendungsverantwortliche die Betriebsverantwortung seiner Applikation.
2.4.3.1 Installationsroutine und Anwendung
Während die Anwendung in der Produktion im Verantwortungsbereich des Anwendungsverantwortlichens liegt, sollte die Installationsroutine (das Paket) trotzdem in Verantwortung der Paketierung verbleiben.
An dieser Stelle sollte beachtet werden, dass das Paket, welches die Anwendung beinhaltet, an sich ebenfalls eine Anwendung darstellt.
2.4.4 Softwarepaketierer und Anwendungsverantwortlicher in einer Person
Obwohl es nicht ratsam ist, kann unter gewissen Umständen keine andere Möglichkeit bleiben als die Rollen des Anwendungsverantwortlichen und des Paketierers zu kombinieren.
In diesem Fall übernimmt der Softwarepaketierer die Pflichten und die Verantwortung des Anwendungsverantwortlichens.
Das Risiko dieser Konstellation liegt in den zwei unterschiedlichen Spezialistenprofilen (Anwendungsverantwortlicher / Softwarepaketierer) begründet.
Das Paketieren eines Paketes erfordert tief greifende Kenntnisse sowohl in Systemtechnik als auch in Automatisierungstechnologien. Sollte der Prämisse „Konzentration auf das Kerngeschäft“ gefolgt werden, ist die zusätzliche Paketierung oder (im Umkehrschluss) Anwendungsverantwortung eine Abweichung vom Kerngeschäft. Diese Anweichung hat zur Folge, dass entweder zwei Spezialistenprofile gelebt (im Sinne von beherrscht) werden müssen oder das Kerngeschäft durch die jeweils andere Tätigkeit beeinträchtigt wird.
2.4.5 Softwarepaketierung durch externe Dienstleister
Stehen in einem Unternehmen nicht genügend eigene Ressourcen zur Verfügung, ist es durchaus sinnvoll, die Softwarepaketierung mit Hilfe externer Unterstützung zu realisieren.
Gerade durch die Spezialisierung auf den Bereich der Softwarepaketierung können Dienstleister Berater / Softwarepaketierer anbieten, die in der Lage sind ein Spezialisten Profil „Softwarepaketierer“ professionell zu erfüllen und umzusetzen.
Überlegenswert sind ebenfalls Planungen, die Paketierung durch solche Spezialisten begleiten zu lassen und über diesen Weg eigene qualifizierte Ressourcen aufzubauen.
Aus Sicht des Dienstleisters darf an dieser Stelle ein externer Paketierer NIEMALS für den Applikationsbetrieb einer Applikation verantwortlich sein.
3 Spezialisten Profil Softwarepaketierer
3.1 Allgemeiner Teil
Nachfolgend wird auf die allgemeinen Fähig- und Fertigkeiten eines Softwarepaketierers näher eingegangen.
3.1.1 Benötigt ein Softwarepaketierer NetInstall Kenntnisse?
Die Fragestellung mag im ersten Schritt etwas sonderbar klingen, aber durch die nachfolgenden Punkte soll klargestellt werden, dass ein Softwarepaketierer sich in erster Linie durch andere Fähigkeiten definiert.
3.1.1.1 NetInstall
NetInstall zeichnet seit jeher die leichte Erlernbarkeit des Paketierungsprozesses und ein sehr mächtige Skriptsprache aus.
Der Prozess einer Paketerstellung kann (von der Paketerstellung her) mit keinem anderen Tool günstiger, schneller und effektiver gestaltet werden.
Die NetInstall Skriptsprache stellt mit Ihrer „Drag & Drop“ Programmierung eine Möglichkeit dar, ohne Programmierkenntnisse ein Paket (eine Automatisierung der Installation) zu programmieren.
Durch die Art und Weise der Skript-Erstellung und Skript-Bearbeitung werden gerade NetInstall Anfänger sehr schnell in die Lage versetzt, professionellen Output zu erzeugen.
3.1.2 Voraussetzungen
3.1.2.1 Systemtechnik
Einen guten Softwarepaketierer macht vor allem eines aus:
Der Softwarepaketierer muss seinen Client im Griff haben!
Gerade bei der Paketierung mittels Delta-Analyse ist es elementar und unabdingbar, nach erfolgreicher Erstellung der Delta-Analyse (NetInstall – Spy) das Skript von Einträgen zu säubern, die zwar Aufgezeichnet wurden, jedoch nicht in das Skript gehören.
Unter Umständen können diese Einträge dazu führen, dass bei einem Rollout dieses Paketes die entsprechenden Zielsysteme irreparabel beschädigt werden. In diesem Fall müssten diese Systeme neu installiert werden.
3.1.2.2 Betriebssystem Kenntnisse
Ein guter Softwarepaketierer sollte in erster Instanz die Betriebssysteme beherrschen, für die er im Rahmen seiner Tätigkeiten Softwarepakete erstellt.
In zweiter Instanz ist es sicherlich ratsam, sich mit anderen Betriebssystemen oder Betriebssystemversionen zu beschäftigen, da der nächste Rollout / Umstellung mit Sicherheit kommen wird.
Beherrschung ist in diesem Zusammenhang wie folgt definiert:
• Registry
Die Windows System Registrierung darf kein Fremdwort sein.
Ein guter Softwarepaketierer muss mit den Standardwerten im HKLM und HKCU vertraut sein. Für eine SPY Analyse ist gerade diese Fähigkeit von elementarer Bedeutung.
• Windows Dienste
Ein Softwarepaketierer muss in der Lage sein, Windows Dienste zu verstehen und diese Dienste ggf. in seinem Skript zu behandeln / zu verändern.
Ungemein hilfreich sind Kenntnisse in WMI. Mittels WMI (und dem NetInstall Befehl für WMI Abfragen) ist es zum Beispiel möglich, nach einer Installation den Status des installierten Dienstes abzufragen und ggf. auf diese Informationen im Skript entsprechend zu reagieren.
• NTFS Rechte und Benutzerverwaltung
Gerade in der Fehleranalyse ist es eine Notwendigkeit, dass Fehler erkannt werden, die auf mangelnde Berechtigung (Betriebssystem) zurückzuführen sind.
• DOS Kenntnisse
Jeder Softwarepaketierer sollte zumindest in der Lage sein, die DOS Grundbefehle zu beherrschen. Trotz aller Mittel bleibt ab und zu nur noch die Befehlszeile als letzter Ausweg.
• Skriptsprachen
Skriptsprachen sind wünschenswert aber nicht Grundvoraussetzung (zumindest in der normalen Paketierung).
Wenn ein Softwarepaketierer in der Lage ist, VBS, JS, KIX, AUTOIT etc. anzuwenden, eröffnen sich ihm technisch vollkommen neue Möglichkeiten. Mit diesen Möglichkeiten lassen sich dann Probleme bewältigen, die zuvor als unlösbar gegolten haben.
“Geht nicht, gibt’s nicht!“ Ist eine Funktion in NetInstall nicht nativ enthalten, kann diese Funktionalität über eine Skriptsprache (meistens) abgebildet werden.
• Netzwerkprotokolle (TCP/IP)
“Gesunde Grundkenntnisse“ im Bereich „Internetworking“ sollten ebenfalls vorhanden sein. Ein Softwarepaketierer sollte in der Lage sein, Fehler entweder entsprechend zu Analysieren bzw. zu Qualifizieren oder diese selber zu beheben. Zu diesen Fertigkeiten gehören ebenso Kenntnisse im Bereich des grundlegenden „IP Troubleshootings“.
• Grundverständnis für Applikationen generell
Alle Applikationen ähneln sich im Grundaufbau. In der Regel gibt es Menüpunkte, in denen (und über diese) sich die Anwendung konfigurieren lässt. Die meisten Anwendungen schreiben ihre Werte in die Registrierung.
Mit diesen zwei Erkenntnissen ist ein Softwarepaketierer in der Lage, eine Anwendung aus Paketierungssicht zu betrachten und eine entsprechende Paketierung anzugehen (Installationstechnologien wie MSI etc. werden später behandelt!).
• Grundverständnis für Client Server Netzwerke und Netzwerkbetriebssysteme
Spätestens, wenn eine Applikation für einen Server (oder Terminalserver) paketiert werden soll, sollte der Softwarepaketierer mit den Grundzügen des entsprechenden Serverbetriebssystems vertraut sein.
3.1.2.3 Installationstechnologien
Grundsätzlich können folgende Arten von Installationstechnologien unterschieden werden:
- MSI
Die Microsoft Installer Technologie entwickelt sich zum „defacto“ Standard in der Softwareinstallation. Ein MSI Paket stellt eine transparente Installationsroutine mit starken QS-Mechanismen dar.
MSI Pakete vereinfachen ein „Application Repair“ oder die Deinstallation einer Anwendung. Viele Produkte steuern sogar die Anwendungsmigration auf ein neues Release vollkommen automatisch.
Ein MSI Paket sollte nicht (im Sinne von dürfen) mittels einer Delta-Analyse repaketiert werden. D. H. aus einer MSI Installationsroutine darf / sollte kein NetInstall SPY Paket erstellt werden. Die systemtechnischen Zusammenhänge einer MSI Installation sind sehr komplex und die kompletten QS-Mechanismen der Microsoft Installer Technologie können ausgehebelt werden.
- Setup.exe (Legacy Setup / Parametrisierte Installation)
In der Regel bedeutet eine solche Setup.exe (und damit sind nicht die Installationen gemeint, die über eine Setup.exe eine MSI Installation aufrufen!), dass für dieses Paket eine Delta-Analyse erstellt werden muss.
Ggf. kann diese Setup.exe auch parametrisiert aufgerufen werden.
Gerade Install Shield Setup – Routinen bieten die Funktion, eine Antwort-Datei für die Applikationskonfiguration zu erzeugen, welche wiederum im Rahme einer Verteilung zur automatischen Konfiguration verwendet werden kann.
ABER:
Bevor solch ein Verfahren eingesetzt wird, sollte die Frage gestellt werden, wie das Paket von der erfolgreichen Installation einer solchen Applikation erfährt (oder besser, wie ein NetInstall Paket mit einer fehlgeschlagenen Installation umgehen soll)? Ebenfalls sind in diesem Zusammenhang Timeout-Fehler zu beachten. Es ist möglich, dass die Installation (über eine parametrisierte Setup.exe) noch aktiv ist, der NetInstall Installer jedoch einen Timeout-Fehler bekommt und die Skriptausführung abbricht.
- Skriptprogrammierung (z. B. NetInstall)
Hin und wieder (z. B. wenn nur ein paar Dateien kopiert werden sollen) kann auf eine Delta-Analyse verzichtet werden und die Installationsroutine sollte manuell über z. B. die NetInstall Skript Sprache abgebildet werden.
3.1.3 Flexibilität
Gerade in der Softwarepaketierung ist Flexibilität ein unbedingtes MUSS!
Fast nirgends wird man schneller regelmäßig mit neuen Herausforderungen konfrontiert, wie in der Softwarepaketierung. Routine und Softwarepaketierung passt nur bedingt zusammen. Routine in der Softwarepaketierung dagegen ist unverzichtbar.
Im Grunde genommen kann jede Paketierungsanforderung bzw. sollte jede Paketierungsanforderung als eigenes Projekt behandelt werden. Jedes Projekt birgt Risiken und Stolpersteine. Weiterhin verlangt jedes Projekt Flexibilität, um sich schnell auf neue Situationen und Veränderungen einzustellen.
3.2 Spezieller Teil / Kompetenzen
In diesem Abschnitt werden Kompetenzbereiche und Fertigkeiten / Kenntnisse aufgeführt, die ein Softwarepaketierer besitzen sollte. Unstrittig ist, dass diese Angaben kein MUSS für jeden Mitarbeiter darstellen, sondern nur eine Empfehlung ist, welche Bereiche in der Softwarepaketierung adressiert werden.
Aufgeführt sind an dieser Stelle nur die Bereiche, nicht die Tiefe, die in den einzelnen Bereichen erforderlich ist. Eine solche Tiefenbetrachtung sollte separat auf die Bedürfnisse der DAK hin angefertigt werden.
Auf der Basis der daraus gewonnenen Informationen können für Mitarbeiter gezielt Fördermöglichkeiten / Fördermaßnahmen herausgearbeitet werden, die sich im Wissensbereich eines Softwarepaketierers bewegen.
Diese Informationen beruhen auf der Befragung von ca. 30 Mitarbeitern in der Paketierung (Softwarepaketierer und Entscheider / technische Verantwortlich).
3.2.1 Fachkompetenz
3.2.1.1 NetInstall
Erforderliche Kenntnisse sind:
a) Handhabung des NetInstall Managers
b) NetInstall Delta-Analyse (SPY)
c) NetInstall MSI-Paketierung
d) NetInstall Skriptsprache
e) Handhabung des NetInstall Monitors
f) Fähigkeit zur Analyse von NetInstall Logfiles
g) Handhabung des NetInstall Installers
h) NetInstall Scripting für Terminal / Citrix Server
i) Andere Script- und Programmiersprachen
a. AutoIt
b. VBS
c. Dos Batch
d. KIX
e. Java Script
f. Visual Basic
3.2.1.2 Betriebssysteme Client
Erforderliche Kenntnisse sind:
a) Windows NT 4 Workstation Installation und Konfiguration
b) Windows NT 4 Workstation Administration
c) Windows 2000 Professional Installation und Konfiguration
d) Windows 2000 Professional Administration
e) Windows XP Professional Installation und Konfiguration
f) Windows XP Professional Administration
3.2.1.3 Betriebssysteme Server
Erforderliche Kenntnisse sind:
a) Windows NT 4 Server Installation und Konfiguration
b) Windows NT 4 Server Administration
c) Windows NT 4 Domänen Benutzerverwaltung
d) Windows NT 4 Terminal Services
e) Windows 2000 Server Installation und Konfiguration
f) Windows 2000 Server Administration
g) Windows 2000 Terminal Services
h) Active Directory Administration (Ressourcen) W2K und W2K3
i) Windows Server 2003 Installation und Konfiguration
j) Windows Server 2003 Administration
k) Windows Server 2003 Terminal Services
3.2.1.4 Applikationen Client
1) Installation und Konfiguration
a. MS Office 2000 / XP / 2003
b. MS Access
c. MS Excel
d. MS Outlook
e. MS Powerpoint
f. MS Visio
g. MS Winword
h. MDAC
i. Internet Explorer (mit IEAK)
j. MS Hotfixes und Servicepacks
k. Adobe Acrobat (Reader und Vollprodukt)
l. Lotus Notes
2) Handling
a. Lotus Notes
b. MS Winword
c. MS Excel
d. MS Powerpoint
e. MS Visio
f. Adobe Acrobat
3.2.1.5 Applikationen Server
a) MS SQL Server
b) MS Internet Information Server
c) Windows Update Services
d) Citrix Presentation Server Administration
e) Citrix Presentation Server Applikationshandling
f) Citrix Presentation Server SSDK
3.2.1.6 Microsoft Technologien
a) Windows Registry
b) MSI Technologie
c) WMI
d) Treiber Installation und Handling
e) Ressource Kit(s)
f) Dienste Installation und Konfiguration
3.2.1.7 TCP/IP
a) TCP/IP Konfiguration am Client
b) TCP/IP Troubleshooting
c) Grundwissen DHCP
d) Grundwissen DNS
e) Erkennen und beheben von IP-Adresskonflikten am Client
3.2.2 Methodenkompetenz
3.2.2.1 Präsentation
a) Aufbau und Gestaltung einer Präsentation
b) Vorbereitung einer Präsentation
c) Durchführung einer Präsentation
3.2.2.2 Projektvorgehensmodelle
a) Projektsetup
b) Meetingkultur
c) Protokoll-Erstellung
d) Eskalation
e) Zeitmanagement
f) Priorisiertes Arbeiten
g) Berichtswesen
h) Erstellung von Dokumentationen
3.2.2.3 Prozessverständnis
a) Rollenverständnis
b) ITIL Grundwissen (ggf.)
c) Kontinuierlicher Verbesserungsprozess
3.2.3 Soziale Kompetenz
a) Kommunikation
b) Teamfähigkeit
c) Kritikfähigkeit
3.2.4 Persönliche Kompetenz
a) Erscheinungsbild / Auftreten
b) Eigeninitiative
c) Kreativität
d) Englisch
e) Dienstleistungsverständnis
f) Problemlösungsorientiertes Handeln
g) Eigenständiges Aneignen von Wissen
h) Kenntnisse der Fachterminologie |
_________________ Regards
Roman Pelzel
ITIL Service Manager,
NetInstall Certified Engineer
Member of the Ni-Support Community |
|
   |
 |
Lobsi
Piccolo

Joined: 01 Oct 2007
Posts: 1
|
Posted:
Mon, 01.Oct.2007, 08:51 |
 |
Hallo,
Ich wollte mich an dieser Stelle für diesen Text bedanken, ich habe mich einiger Passagen davon bedient, um der Arbeitslosenkasse meine Einarbeitungszeit und deren Notwändigkeit klar zu machen!
Es hat dann niemand mehr gezweifelt, dass Software paketieren jeder rasch mal machen kann, und schon garnicht von wem, der seine Brötchen bisher als Supporter verdient hat!
Super geschrieben und unmissverständlich, das find ich Spitze!
Mit freundlichen Grüssen
Lobsi |
_________________ Ein Boot tut gut, drum hab Mut zum Boot!
------------------------------------------------ |
|
  |
 |
|
|
|
|
|
View next topic
View previous topic
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Service provided by flatbyte.com
::
Powered by phpBB
:: FI Theme
:: Imprint ::
All times are GMT + 1 Hour
| |