Continous Delivery Plugin w/ manual steps?

[Turbo Fredriksson]

I have the need to create a "(Almost) Continuous Delivery" pipeline for a number of GitHub repositories

that together forms "The App". They should (hopefully, the devs are currently in the process of refactoring

the code to make this possible) be possible to test, build and deploy independently.

However, since we don't have enough automated tests, I can't deploy the software all the way to live

(Feature Flags is also something that's on the TODO for the "somewhat-near" future).

So I have four environments the software should pass through. It needs to be successfully deployed

and tested in each of them to proceed to the next stage.

They are: Test (very simple "ping" automated test), Preview (the "full monty" tests - we're working on that),

Validation (which is currently manual tests by the testers - this will be decommissioned if/when we have

"The Full Monty" tests running in a few years) and Live.

Now, because "Test" and "Preview" is where all the automated tests happen, I want this to be automatic.

That is, it should first deploy to Test, configure the software (using puppet) and run the "ping" test. If that

succeeds, I want it to start deploying to "Preview", configure the software and run what automated unit

tests we have.

But then the automatic part should stop! I want "simple PLAY button" for it to be deployed into "Validation"

(and once that's succeeded, another "PLAY" button should appear next to "Live").

I also have three "Demo" environments (one for "selected customers", for the sales people and one for

our internal colleagues in the rest of the organisation so they can see what's happening).

Those three should be "available" (with a PLAY button) at the same time it starts deploying to "Test".

There's two problems with the current "Delivery Pipeline" plugin and Jenkins:

    1. It's only possible to have _ONE_ manual step

        https://issues.jenkins-ci.org/browse/JENKINS-26282

    2. I get "circular dependencies" when I try to setup the dependency between the "Test"

        part of the pipeline and "Preview".

I've tried the "Pipeline" plugin, but that don't seem to have a manual step for me/someone to click on.

To add insult to injury, I also need this to be compact. I could possibly do this as one, long, flat pipeline,

but that won't show on the big wall monitor/TV we're ordering. I want the devs to be involved in this, to

make them _see_ what's happening to their commit.

So with the "Delivery Pipeline" module, I grouped my different part of the stages by setting the "Stage Name"

and "Task Name" in the "Delivery Pipeline configuration" setting.

Looks pretty and exactly what I want. However, that's where I'm getting the circular dependency.

So at the moment, "Test" and "Preview" launches at the same time, in parallel.

Is there another plugin that might do what I want to do?

[Turbo Fredriksson]

This is a huge blocker for me and the company I work for at the moment.

Is there anyone that could be persuaded to help us implement something

like this for a box of chocolates :)

[Daniel Beck]

> On 07.03.2017, at 12:38, Turbo Fredriksson <fran...@gmail.com> wrote:
>
> I've tried the "Pipeline" plugin, but that don't seem to have a manual step for me/someone to click on.

What about this?

https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for-interactive-input

Wrap in a timeout if you only want it to be around a limited time.

[Turbo Fredriksson]

On Thursday, March 16, 2017 at 11:57:09 PM UTC, Daniel Beck wrote:

https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for-interactive-input

Wrap in a timeout if you only want it to be around a limited time.

Tried that, but we don't know when (or even IF) a deploy to the next environment even SHOULD

take place. And with _a lot_ of commits (at the moment), there's going to be a lot of waiting... 

[suresh kumar]

Hi Daniel Beck,
Is there a concept of "promoted builds" in pipeline as code. Do we have any document or notes to achieve this scenario.
As input step is not working as existing "promoted builds" at least promoting a selected build based on user interaction.

-Thanks,
Suresh

[Daniel Beck]

> On 17.03.2017, at 11:40, Turbo Fredriksson <fran...@gmail.com> wrote:
>
> And with _a lot_ of commits (at the moment), there's going to be a lot of waiting...

This doesn't cost notable resources if you do it right, i.e. outside node blocks.

[suresh kumar]

Yes Daniel, when configured properly with "agent none" pipeline is not occupying any executor and as you said it is not occupying notable resources.

My Suggestions in this regard are below:

1. Adding a new status to the build called "Paused" besides to the existing statuses Success, Failure, Aborted, Unstable.
2. In Blue Ocean theme, Status icon showing as Paused and where as if we see the in the build history of the Job's placeholder the icon is blinking forever until some one acted.

                         Blue Ocean it shows Pause icon
                  
                         Build History it shows InProgress icon
                        

May be above suggestions might be in your future active development list, but just wanted to bring up now my observations.

-Suresh

[suresh kumar]

Other observations: As build is still running, the build duration is keep on increasing and as it is in inprogress completed is empty.

[Daniel Beck]

> On 17.03.2017, at 15:54, suresh kumar <pskum...@gmail.com> wrote:
>
> your future active development list

I am not working on either Blue Ocean or Pipeline, and this isn't where you ask for changes anyway.

[suresh kumar]

Sorry about that, I didn't frame sentence properly.
 What I mean "Jenkins future active development list".

Ok it is not the right place to ask changes, but what I felt is it is correct thread and context exactly suits.

-Suresh

[Turbo Fredriksson]

Perhaps, but it's bound to be very confusing - X number of jobs seemingly "running".

In our current phase of development, we have _at least_ ten commits a day. We work in sprints

of two weeks. So the QA people will be one sprint behind. That means the timeout needs to be

at least two weeks (plus one day, but preferably all through THEIR two weeks sprint).

That means that when QA picks up, there will be 10 jobs * (10 [working] days + weekends) * 2 sprints

(one for dev, one for QA).

Which of those was the correct commit they where supposed to QA?! Finding the right one

of all those "running" jobs, will be a nightmare!

Not to mention it is going to be difficult to find out from all those 200+ running jobs to distinguish

really stuck ones from the ones that's waiting for input. Not to mention the fact that I kill of all

Jenkins executors automatically at night (to save us some money :) and spin up new, fresh ones

in the morning (weekdays only). So those "running" jobs will "vanish" anyway.

That being said, this is _MY_ "vision" on how I would like it to be. My vision might be blurred, so

feel free to correct me or give me a better option..