- CD Pipeline includes: Git => Jenkins => CI (w/ Static Code Analysis, SAST, etc.) => Docker Registry => Spinnaker
- CD Pipeline design should be optimized for Developer Experience and Overall Speed of Deployment to the target lifecycle, without compromising on Quality or Security
- In an ideal world, a developer should be able to perform "Write Code, Build Code, Test Code" loop on their local machine
- A Developer should be able to push code directly to Dev Cluster (only Dev) without going through CD Pipeline
- A Developer should NOT be allowed to push code directly to all other lifecyles (including and especially Prod lifecycle)
- Developer writes software using GitHub flow with one master branch and multiple short-lived feature/, bugfix/ and hotfix/ branches
- Kubernetes Resources will have different values for different lifecycles. Use of a template-based approach to generate YAML files is highly encouraged
- Technical Leads should have the ability to control the transition of a software from Dev to all other lifecyles (including and especially Prod lifecycle)
- Technical Leads should have the ability to deploy multiple softwares together (aka Snapshot) from Dev to to all other lifecyles (including and especially Prod lifecycle)
- Delivery teams should be able to deploy code using any of the following Deployment Strategies: Rolling Update, Blue/Green and Canary
- Delivery teams should be able to deploy code to any environment, on-premise or public cloud
- Delivery teams store their software code in DVCS (Git). Worst case, SVN
- Master branch should always show the latest software running in Prod
- Every change committed and pushed should automatically trigger the CD pipeline into Dev
- Delivery teams should capture their CI Pipeline along with their code (Jenkinsfile)
- Software should be promoted to Stage using Binary Artifact Reference deployed to Dev (either most recent or any old version)
- Software should be promoted to Production ONLY using the latest Binary Artifact Reference deployed to Stage
- Each Application should be setup as a Spinnaker Project (OPTIONAL)
- Each Software (or Microservice) within an Application should have at least one Spinnaker Pipeline that gets triggered by Jenkins (or at the end of CI)
- Should we dynamically bind container image tags within the Kubernetes YAML file(s) within Jenkins and/or Spinnaker or should they be statically defined? Especially for Production deployment
- Kustomize
- Telepresence.io
- Skaffold
- Helm Charts without Tiller. References: What you YAML is what you get, Helm vs Kapitan vs Kustomize
Here is the article that inspired this piece: What should be proper (local) development workflow?