8
Ausführung eines PowerShell-Scripts aus JIRA initiieren
Hallo,
wir würden gerne bestimmte JIRA-Status festelegen, die dann u. A. die Ausführung eines PowerShell-Script initiieren.
Z. B. Mitarbeiter soll im AD angelegt werden ...
Aus meiner Sicht kann so etwas nur mit ScriptRunner umgesetzt werden, was naturgemäß etwas "pricey" ist.
Hat jemand so etwas schon umgesetzt, kommt ein anderer Ansatz - außer ScriptRunner - in Betracht?
Vielen Dank für eure Meinungen.
LG
Istike
wir würden gerne bestimmte JIRA-Status festelegen, die dann u. A. die Ausführung eines PowerShell-Script initiieren.
Z. B. Mitarbeiter soll im AD angelegt werden ...
Aus meiner Sicht kann so etwas nur mit ScriptRunner umgesetzt werden, was naturgemäß etwas "pricey" ist.
Hat jemand so etwas schon umgesetzt, kommt ein anderer Ansatz - außer ScriptRunner - in Betracht?
Vielen Dank für eure Meinungen.
LG
Istike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7387334972
Url: https://administrator.de/forum/ausfuehrung-eines-powershell-scripts-aus-jira-initiieren-7387334972.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
8 Kommentare
Neuester Kommentar
Würde in der Datenbank Trigger auf die jeweiligen Tabellen bei entsprechenden Inserts/Updates erstellen die dann deine Aufgaben abarbeiten.
Damit solltest du deine Aufgabe in kürze auch ohne Geld zu verbrennen erledigen können.
Gruß
- https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html
- https://stackoverflow.com/questions/1467369/invoking-a-php-script-from-a ...
- https://patternbuffer.wordpress.com/2012/09/14/triggering-shell-script-f ...
Damit solltest du deine Aufgabe in kürze auch ohne Geld zu verbrennen erledigen können.
Gruß
Moin,
@7010350221
Je nachdem, ob Jira On-Premise oder Cloud und dem verwendeten Datenbankmodell, wird das nicht hinhauen. Wenn dann noch eine h2 Datenbank zum Einsatz kommt, hat man in der Regel sowieso andere Probleme.
Gruß,
Dani
Aus meiner Sicht kann so etwas nur mit ScriptRunner umgesetzt werden, was naturgemäß etwas "pricey" ist.
Wer sich für Atlassian Jira entscheidet, sollte von Anfang an klar sein, dass es Kosten mit sich zieht. Das ist wie bei Oracle oder SAP.... da reiben sich viele immer noch die Augen.@7010350221
Je nachdem, ob Jira On-Premise oder Cloud und dem verwendeten Datenbankmodell, wird das nicht hinhauen. Wenn dann noch eine h2 Datenbank zum Einsatz kommt, hat man in der Regel sowieso andere Probleme.
Gruß,
Dani
Vielen Dank für deine Rückmeldung
An sich ist es kein Problem. Wir nehmen es auch in Kauf, wenn es Sinn ergibt. Wenn wir dadurch Effizienz gewinnen, kein Problem. Wir brauchen Lösungen, die für ein relativ großes Team sinnvoll verwaltet werden können und die "mandantenfähig" sind. Wir würden also Workflows einrichten, die am Ende auch von "normalen" Projektleitern gestartet werden können. Wo man also nicht viel manuell basteln muss und wo ich den Kollegen keine Admin-Rechte fürs AD geben solle.
Es geht es um DataCenter Versionen, die normale PostgreSQL-DBs benutzen ...
LG
I.
Quote from @Dani:
Wer sich für Atlassian Jira entscheidet, sollte von Anfang an klar sein, dass es Kosten mit sich zieht. Das ist wie bei Oracle oder SAP.... da reiben sich viele immer noch die Augen.
An sich ist es kein Problem. Wir nehmen es auch in Kauf, wenn es Sinn ergibt. Wenn wir dadurch Effizienz gewinnen, kein Problem. Wir brauchen Lösungen, die für ein relativ großes Team sinnvoll verwaltet werden können und die "mandantenfähig" sind. Wir würden also Workflows einrichten, die am Ende auch von "normalen" Projektleitern gestartet werden können. Wo man also nicht viel manuell basteln muss und wo ich den Kollegen keine Admin-Rechte fürs AD geben solle.
@7010350221
Je nachdem, ob Jira On-Premise oder Cloud und dem verwendeten Datenbankmodell, wird das nicht hinhauen. Wenn dann noch eine h2 Datenbank zum Einsatz kommt, hat man in der Regel sowieso andere Probleme.
Je nachdem, ob Jira On-Premise oder Cloud und dem verwendeten Datenbankmodell, wird das nicht hinhauen. Wenn dann noch eine h2 Datenbank zum Einsatz kommt, hat man in der Regel sowieso andere Probleme.
Es geht es um DataCenter Versionen, die normale PostgreSQL-DBs benutzen ...
LG
I.
Ja und, lokal oder Cloud? ProstgreSQL hat auch Trigger
https://www.postgresql.org/docs/current/sql-createtrigger.html
https://www.postgresql.org/docs/current/sql-createtrigger.html
Moin,
D.h. aber nicht, dass ein Servicebenutzer alles im AD darf. Ganz im Gegenteil. Wir haben für die verschiedenen Aufgaben dedizierte AD Servicebenutzer eingerichtet, die auch im AD nur die notwendigen Rechte haben. Weil ein Berechtigungsfehler im Jira oder Sicherheitslücke und das AD ist in großer Gefahr.
Gruß,
Dani
Wir brauchen Lösungen, die für ein relativ großes Team sinnvoll verwaltet werden können..
groß ist immer relativ. ...und die "mandantenfähig" sind.
Seit wann unterstützt Jira die klassische Mandantenfähigkeit oder redest du von Jira Projects?Wir würden also Workflows einrichten, die am Ende auch von "normalen" Projektleitern gestartet werden können. Wo man also nicht viel manuell basteln muss und wo ich den Kollegen keine Admin-Rechte fürs AD geben solle.
Ich weiß nicht was ihr da so gebastelt habt. Wir nutzen ProForma Workflow + Approval + Scriptrunner. Damit haben wir fast jeder AD Interaktion abgebildet. Damit arbeitet bei uns eine 6stellige Anzahl von Mitarbeitern.D.h. aber nicht, dass ein Servicebenutzer alles im AD darf. Ganz im Gegenteil. Wir haben für die verschiedenen Aufgaben dedizierte AD Servicebenutzer eingerichtet, die auch im AD nur die notwendigen Rechte haben. Weil ein Berechtigungsfehler im Jira oder Sicherheitslücke und das AD ist in großer Gefahr.
Gruß,
Dani
Hallo Dani
vielen Dank für die Info. Den Ansatz finde ich interessant ..
Meinst du mit Proforma Workflow und Approval diesen Weg hier: https://confluence.atlassian.com/proforma/using-proforma-with-approvals- ...
Sind die Optionen (die am Ende mit PowerShell ausgeführt werden) als eine Art Self Service bereitgestellt?`
Wenn also Kollegen bestimmte Sachen (neues Projekt, neue VM, neue AD-User etc.) brauchen, können die entsprechenden Optionen in "Workflow" auswählen, die durch "Approval" akzeptiert werden müssen und am Ende wird es mit einem PowerShell for JIRA Script umgesetzt.
Sind meine Vorstellungen über euer Workflow realistisch?
(möglicherweise könnten wir es auch mit ScriptRunner for PowerShell umsetzen ...)
Neben diesem Ansatz fand ich noch die folgenden "PowerShell-powered" Self-Service Lösungen:
https://www.scriptrunner.com/de/software/portal/
https://github.com/markdomansky/WebJEA
https://au2mator.com/powershell/
Gr. I.
vielen Dank für die Info. Den Ansatz finde ich interessant ..
Meinst du mit Proforma Workflow und Approval diesen Weg hier: https://confluence.atlassian.com/proforma/using-proforma-with-approvals- ...
Sind die Optionen (die am Ende mit PowerShell ausgeführt werden) als eine Art Self Service bereitgestellt?`
Wenn also Kollegen bestimmte Sachen (neues Projekt, neue VM, neue AD-User etc.) brauchen, können die entsprechenden Optionen in "Workflow" auswählen, die durch "Approval" akzeptiert werden müssen und am Ende wird es mit einem PowerShell for JIRA Script umgesetzt.
Sind meine Vorstellungen über euer Workflow realistisch?
(möglicherweise könnten wir es auch mit ScriptRunner for PowerShell umsetzen ...)
Neben diesem Ansatz fand ich noch die folgenden "PowerShell-powered" Self-Service Lösungen:
https://www.scriptrunner.com/de/software/portal/
https://github.com/markdomansky/WebJEA
https://au2mator.com/powershell/
Gr. I.
Moin,
Gruß,
Dani
Meinst du mit Proforma Workflow und Approval diesen Weg hier: https://confluence.atlassian.com/proforma/using-proforma-with-approvals- ...
Yes.Sind die Optionen (die am Ende mit PowerShell ausgeführt werden) als eine Art Self Service bereitgestellt?`
Die Kollegen können über ein Projekt in Jira / JSM entsprechende Aufträge erstellen. Jede Aufgabe durchläuft entsprechend dem definierten Prozess weiteres Tasks, Approval, etc. Welche der Interaktionen in AD, Exchange, Sharepoint, AD FS, Firewall, etc. (nicht) mit PowerShell gelöst ist, weiß nicht. Das Ganze wird durch einen anderen Bereich betreut.Sind meine Vorstellungen über euer Workflow realistisch?
Wenn man genug Ressourcen zur Verfügung hat, Ja. Das Ganze muss bezüglich Sicherheit sehr gut geplant, umgesetzt, geprüft und gewertet werden. Gerade wenn es um AD, Exchange, SharePoint, AD FS, PKI, etc. geht. Weil doch vieles ineinander greift und doch komplexe Abhängigkeiten gibt. Da kann ein grober Fehler ein AD "zum Fallen" bringen. Um so mehr 3rd Party Systeme/Anwendungen eingebunden werden, um so komplizierter wird es. Das ist bei uns auch nicht über Nacht entstanden, sondern von Start bis Ende ca. 5 Jahre mit einem Projekt Team von 100 Leuten entstanden.Neben diesem Ansatz fand ich noch die folgenden "PowerShell-powered" Self-Service Lösungen:
Kenne ich nicht. Kann daher nichts dazu sagen.Gruß,
Dani
Hallo Dani,
herzlichen Dank für deine Rückmeldung.
LG
I.
herzlichen Dank für deine Rückmeldung.
LG
I.
