Add an option to notify people (configurable) when a deployment is done

[silverstripe-archive]

Add an option to notify people (configurable) when a deployment is done

[sminnee]

...and started. I would love to see this for some of the deploys that I'm involved with but don't do myself.

It's possible that the pipeline functionality could be used for this? I'd prefer we go down the path of making pipeline function simple enough to use in all cases, rather than providing ways of avoiding its use.

[ss23]

@sminnee We provide an extension point in #16 for this already, though I believe the pipelines feature may not work quite properly at this.

This isn't the best place, but as it is, pipelines adds an unreasonable overhead. It's not practical to ask people to use it until it becomes a lot easier. Improvements to this kind of thing are worth doing, as I don't expect pipelines to become usable in the near future.

[sminnee]

I guess my issue is that we essentially wind up doubling our maintenance effort, and it would be worth digging into what the overheads of pipeline are and can those be resolved.

I know that #100 is one example of pipeline issues. Perhaps the absence of a simple, default pipeline is another?

[tractorcow]

A pipeline could very well be a simple one step "do the deployment" pipeline and this gives you all these notifications. It is overhead though, which is why I'd prefer to modularise pipelines out completely, so you could substitute your own deployment workflow as necessary.

[sminnee]

I disagree that pipeline should be an optional bolt-on, because making it optional increases the overall complexity dramatically. It's like having plugins for different ways of designing build steps in TeamCity.

• It means that rather than being able to rely on pipeline to provide a set of steps, we have to always think "what's the no-pipeline experience?"
• It means that we need to build 2 different UIs for a lot of things (#100 is a great example of how this can go wrong if we forget to do this)

I don't see why pipeline can't be refactored/polished so that a 1-step pipeline is simple enough to use as the default option.

[tractorcow]

Point taken. As long as the core code is clean and works well that's good enough.

Would you prefer a simple one-button-activated template, or a template system that builds a pipeline (or pipelines) from a form submission?

[sminnee]

In the short term, I'd probably suggest we:

• Making the front-end UX for that pipeline as simple as possible
• Make the admin UX for that pipeline as simple as possible

Perhaps @ss23 could expand on where the unreasonable overhead of pipeline exists? I can think of a few things:

• The YAML is hard to build, it's not nice to have to maintain this on a project-by-project basis.
• There's no deployment history screen that is meaningful if you're using pipelines (#100).
• The ability to "skip the pipeline and just do the deploy" or "use the pipeline" in the front-end is a bit weird. To be honest I like the idea of having a few different pipelines available better - so you have "regular approval" or "emergency".
• The fact that it's got its own job management system might make it hard to keep track of progress after it's kicked off? I'd need to get feedback from @ss23 about that.
• I believe there's a delay between pipeline steps is probably a bit sub-optimal.

Ideally we can get to the point where a pipeline that contains only a "deploy step" is just as simple as a pipeline-less deployment.

Once that is done, then I'd suggest we make it possible to include a default pipeline into the site's yaml config.

---

Later on, something like allowed_pipelines approach that mirrors allowed_backends, although that would only work if most projects are choosing between a handful of different pipeline schemes. If user-specific data like email addresses are baked into the pipeline, then that wouldn't really work, although the work for #67 might help with that.