JIRA Workflow – Approfondimenti

Approfondiamo l’argomento

In questo post andremo ad approfondire l’argomento Workflow, già trattato in:

Cercheremo, in questa prima fase, di capire che funzionalità abbiamo a disposizione, cercando in una seconda fase di applicarle a dei casi reali.

Nel dettaglio

Come JIRA Administrator è possibile operare le seguenti azioni su di un Workflow:

  • Triggers –  Si tratta di  impostare delle azioni specifiche da eseguire in determinate condizioni / transazioni.
  • Conditions – possibilità di poter impostare delle condizioni per poter eseguire determinate transazioni.
  • Validators – intesa come validazione dei dati, affinché rispettino determinate condizioni
  • Post functions – intesa come l’esecuzione di operazioni dopo che una issue è passata da uno stato all’altro
  • Properties – si tratta di coppie di valori che possono essere usate per estendere le proprietà, come informazioni aggiuntive del workflow.

Andiamo ad esaminare nel dettaglio le varie componenti.

 

Triggers

Questi strumenti sono utilizzati prevalentemente per integrare determinate azioni del workflow con gli strumenti di sviluppo quali Stash o FishEye/Crucible. La seguente tabella riassume quali azioni possono essere eseguite.

WF-03-01

Di conseguenza, se non si dispone di un link a tali strumenti, i trigger non risultano usabili. Questo lo andremo a verificare con i nostri test. 🙂

 

Conditions

Si tratta condizioni che possono essere impostate nelle varie transazioni di stato del Workflow. Possiamo, ade esempio, impostare le seguenti condizioni:

  • Consentire al solo reporter di eseguire una transizione di stato. Si tratta di una condizione molto rigida: Si consiglia una attenta valutazione prima di impostare una condizione del genere;
  • Consentire ad un insieme di utenti di poter eseguire una transizione di stato. SI tratta di una condizione molto rigida anche questa.
  • Poter eseguire una transizione di stato solo dopo aver eseguito la commit.

Validators

Con questa funzionalità, riusciamo ad impostare una validazione dei dati che sono inseriti prima della transazione di stato. Se questa fase non viene passata, la transazione di stato non viene eseguita e le operazioni successive non sono eseguite.

In questo modo possiamo accertarci di aver inserito correttamente tutte le informazioni, nell’ambito di una issue. Possiamo finalmente avere delle issue complete in ogni fase della lavorazione 🙂

 

Post functions

Si tratta di operazioni, di corollario, che possono essere impostate per essere eseguite dopo che la transazione di stato è stata eseguita. In questo modo possiamo impostare delle funzionalità aggiuntive. SI tratta di una funzionalità non indifferente 🙂

Possiamo settare lo stato di una linked issue, in modo da sbloccarla in … automatico. Questo sicuramente ci può aiutare nella sincronizzazione dei gruppi di lavoro. Supponiamo che una nostra issue blocca il lavoro di un altro gruppo. Con questa semplice azione possiamo segnalare in automatico che possono procedere con la lavorazione di una determinata anomalia. Immaginatevi se i gruppi di lavoro sono a distanza l’uno dall’altro.

Possiamo anche andare a settare un campo in funzione del contenuto di un’altro. Le possibilità sono molteplici. 😀

 

Properties

Si tratta di coppie di valori (codice/valore) che sono usate per estendere le proprietà di un workflow.

Un possibile uso può essere quello di impostare delle restrizioni in base ai valori delle properties impostate.

 

Conclusioni

In questo post siamo andati un in profondità sui Workflow. Abbiamo visto come è possibile estendere queste nuove funzionalità, come poter impostare diverse condizioni, validazioni ed estendere il Workflow con nuove proprietà. Nei prossimi post andremo a vedere un esempio di utilizzo di queste, applicandoli a situazioni già descritte.

 

Likes(0)Dislikes(0)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *