CD4PE Pipeline Patterns

cd4pe_pipeline_patterns.md

CD4PE Pipeline Patterns and Strategies

Recently, a few of us PSEs got together to have a deep dive into CD4PE and see if we could take some of the workflows we've seen from customers and convert them to CD4PE. We've identified a few different patterns and stragtegies and would like input on their validity, supportability, and how well they adhere to CD4PE's intended usage.

Master pipeline, feature pipeline

• This is the most basic pattern we have, and the one we are expecting to deliver as part of a standard jumpstart.
• Consists of two pipelines, Master and Regex.
  • Master:
    • Source is master branch in control repo
    • Triggered via commit pull requests and commits.
    • Default code validation and impact analysis stages.
    • Three deployment stages: development(direct deployment), staging(eventual consistency), and production(eventual consistency) that deploy to the Development, Staging, and Production node groups respectively.
      • Each of these deployment stages requires a manual promotion for the deploy stage to kick off.
  • Regex:
    • Source branch is feature branches found via regex matching feature_.*
    • Triggered via commits.
    • Default code validation stages, no impact analysis.
    • One deployment stage with the feature branch policy.

Simple CI pattern

• This is a pattern for customers who either cannot, or will not, use the deployment feature of CD4PE.
• This was born out of CD4PE and PE being bundled together in sales, and having the customer still get some value out of CD4PE.
• This pattern is good for customers who are familiar with a git-based workflow (current PE customers getting CD4PE for the first time).
• The strength of this pattern is that it will implement PR gates that prevent merges from feature branches until tests are complete, similar to a traditional continuous integration pattern.
• Consists of a single feature branch pipeline.
  • Pipeline:
    • Source is a feature branch that is found via regex matching feature_.*
    • Triggered via commit and pull request
    • Default code validation stages with a pull request gate.
    • Deployment stage (feature branch policy).

👍