Design for CD Pipelines about mu

[cplee]

Would we need to prescribe the standard pipeline or could we support their multi-variant stage pipelines? How opinionated do we anticipate this to be?

For an MVP, I'd suggest a highly opinionated, Stelligent "standard" pipeline. I think so long as it was easy for folks to adopt, they'd appreciate all the thought that we've put into how pipelines should work. This is actually one of the more valuable aspect of this project. It's one thing to provide a means to easily get your code running in AWS, but it's another thing to do it in a safe, controlled, and repeatable manner. This is where Stelligent can showcase our expertise with CD pipelines and make them easier for developers to achieve.

Would they want or would we want to support different types of build, orchestration, and other tools?

Good question. Ultimately, the tool is just a CLI that would need to be available from an alternate build system. For example, a CircleCI user would be able to install mu and run it from the circle.yml file to manage environments and services. Maybe would be good to have an example of this type of integration as to gain some adoption without forcing folks to go all in with CodePipeline/CodeBuild?

Do we need to know anything about their source provider?

Need to know the URL to pull from. Could be determined via git remote get-url origin, assuming they are in a git repo when they run the command...otherwise would need to be included in the yaml file. Additionally, a GitHub access token will need to be created and referenced from mu pipeline up.

[PaulDuvall]

Maybe would be good to have an example of this type of integration as to gain some adoption without forcing folks to go all in with CodePipeline/CodeBuild?

Maybe, but a low priority in my opinion.

For an MVP, I'd suggest a highly opinionated, Stelligent "standard" pipeline.

Agreed.