[jboss-jira] [JBoss JIRA] (DROOLS-1355) a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes

[James Strachan (JIRA)]

     [ https://issues.jboss.org/browse/DROOLS-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Strachan updated DROOLS-1355:
-----------------------------------
    Description: 
[Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.

Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :) 
https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for-interactive-input

What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:

{code}
// lets wait for approval or timeout/fail if not
droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")

// now promote to production
...
}
{code}

then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.

The various key/value pairs can then be used to associate promoting a project of a certain name in  a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.

Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out. 

I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.

We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :) 

We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.

e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.

  was:
Jenkins Pipelines are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.

Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :) 
https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for-interactive-input

What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:

{code}
// lets wait for approval or timeout/fail if not
droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")

// now promote to production
...
}
{code}

then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.

The various key/value pairs can then be used to associate promoting a project of a certain name in  a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.

Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out. 

I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.

We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :) 

We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.

e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.



> a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1355
>                 URL: https://issues.jboss.org/browse/DROOLS-1355
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: James Strachan
>            Assignee: Edson Tirelli
>
> [Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.
> Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :) 
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for-interactive-input
> What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:
> {code}
> // lets wait for approval or timeout/fail if not
> droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")
> // now promote to production
> ...
> }
> {code}
> then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.
> The various key/value pairs can then be used to associate promoting a project of a certain name in  a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.
> Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out. 
> I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.
> We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :) 
> We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.
> e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)