DevOps Demo - CI/CD Flow

# DevOps Demo

#### CI/CD Flow

---

---

[🗺️](#/diagram)

# Plan

* [SAFe - Break features into stories 🔗](./safe-devops.md#feature-stories)

------

## Team Backlog

* Using GitHub Project (link)
* This is a team level backlog
* Backlog is groomed with top items DoR

------

## Lean Agile Mindset

* Limit WIP
* One small feature at a time

---

[🗺️](#/diagram)

# Code

* This is the **core work**
* Done in the Dev's local environement
* Consider the Developer Experience (DX)

------

## Version Control

* Using GitHub
* Repositories: [github.com/dr3dr3 🔗](https://github.com/dr3dr3)
* DevOps Demo - Solution Design (link)

------

## Local Dev Environment

* Clone to own developer environment
* `npm run setup`
* `npm run start`
* `npm run build`
* `npm run start` (i.e. serve locally)

------

## Cloud Dev Environment

* Use GitHub Codespace in repo
* Everything setup
* Same for everyone
* Still a work-in-progress
* If use SLFB... create a codespace for it

------

## Developer Experience

* From nothing-to-committing is easy
* Disposable dev environments

---

[🗺️](#/diagram)

# Commit - Locally

* Commit "locally" first

---

[🗺️](#/diagram)

# Build - Locally

* Built within dev environment
* `npm run build`
* `npm run start` (i.e. serve locally)

---

[🗺️](#/diagram)

# Test - Locally

* Tested within dev environment
* `npm run lint`
* `npm run test`
* Part of shift-left for quality

Note: This just runs the standard tests that comes with Reveal-MD

---

[🗺️](#/diagram)

# SLFB

* Optional
* Once coding is completed locally...
* Create **short-lived-feature-branch**
* Useful when multiple changes at same time
* Example: multiple devs / teams

---

[🗺️](#/diagram)

# Commit (SLFB)

* Once branch created...
* Push commits to SLFB
* `on-pr-approved`
* Triggers **continuous integration** workflow
* Will get deployed to Sandbox environment
* SBX environments can be ephemeral

---

[🗺️](#/diagram)

# Build

* **Build based on SLFB**
* Same commands for all solutions
* `npm run build` 
* Output to `_site` folder
* [SAFe - Continuous code integration 🔗](./safe-devops.md#code-integration)

---

[🗺️](#/diagram)

# Test

* For build based on SLFB
* **Pre-deployment tests**
* Run automated tests on build output
* Unit tests (for the solution)
* Example: Check for broken links
* WIP: Contract tests against stubs

Note: Dont have contract tests in place yet. To do some as an example. Also, what tests are run is configurable in GitOps repo.

---

[🗺️](#/diagram)

# Deploy - SBX

* Automatically deploy (if tests pass)
* Call this environment "Sandbox" (SBX)
* Is an **ephemeral environment**
* WIP: Ephemeral environments & lifecycle
* Deploys built package based on SLFB

Note: Emphemeral environment is a future feature. Currently deploys to "CI" environment, being the solution repo's GitHub Pages. May create codespace in the GitHub repository. Team can run the codespace, serve the _site folder, and do manual testing (exploratory). Update: Will deploy to Surge.Sh and have a workflow to manage the life (temporary) of that ephemeral environment.

------

## Emphemeral Environments

---

[🗺️](#/diagram)

# Release

* Using **dark launches** & **features flags**
* Set for on (to test change)
* But also need to test when off
* WIP: Feature flags using [Featurevisior 🔗](https://featurevisor.com/)

Note: What config (including flags) is needed for testing and what needs to be tested in the SLFB and emphemeral environment

------

## Dark Launches

* Incomplete code not exposed to users
* [SAFe DevOps - Dark Launches 🔗](./safe-devops.md#dark-launches)
* Example: `slides-draft` folder
* Example: React component not used
* WIP: React components in Storybook

------

## Feature Flags

* Using [Featurevisior 🔗](https://featurevisor.com/)
* "Feature management for devs with GitOps"
* DevOps Demo: [flags.andredreyer.com 🔗](https://flags.andredreyer.com/)
* Repo on [GitHub - dr3dr3-demo-ff 🔗](https://github.com/dr3dr3/devops-demo-ff)
* Flags enabled per environment
* [SAFe DevOps - Feature Flags 🔗](./safe-devops.md#feature-flags)

---

[🗺️](#/diagram)

# Observe

* Ephemeral environments (lifecycle)
* SLFB branches (exist, age, etc)
* WIP: Using KeepHQ for "single pane of glass"
* Fun integration to [IFTTT 🔗](https://ifttt.com/)

------

## IFTTT Integration

* CI/CD Workflow calls IFTTT webhook
* IFTTT activates scenes on Nanoleaf lights
* Shows when CI/CD kicked off
* Shows SBX deployment (success/fail)
* Shows CI deployment (success/fail)
* Shows STG deployment (success/fail)
* Shows PRD deployment (success/fail)

---

[🗺️](#/diagram)

# Test

* Post deployment tests
* WIP: Smoke testing for SLFB PR change
* WIP: Security tests (DevSecOps)

---

[🗺️](#/diagram)

# Trunk

* Change to `Main` from either:
* Approved PR to merge SLFB to Main
* Commit direct to Main (trunk-based dev)
* WIP: Setup gated commits? (pre-commit)

Note: How is PR created? Is this automated?

------

## Trunk Based Development

* Main branch always in a releaseable state
* [SAFe - Trunk Based Development 🔗](./safe-devops.md#trunk-based-development)

---

[🗺️](#/diagram)

# Commit (Main)

* Will get deployed to CI
* Integrates changes within micro-frontend

Note: CI is commit (remote, either SLFB or Trunk) to deploy to CI. Could argue that deploy to STG is "integration" (across whole solution). Continuous Deployment could cover deploy to SBX/CI/STG/CAN/PRD. Continuous Delivery is up to deploy to PRD.

---

[🗺️](#/diagram)

# Build

* Build package for the micro-frontend
* Package is stored in **artifact repository**
* Stored after tests on build done

Note: Currently need to merge to trunk for the CI flow. May need to look at building off the SLFB once PR is ready to go (so before merge to trunk).

---

[🗺️](#/diagram)

# Test

* Run automated tests, including:
* Unit tests for micro-frontend
* Example: Check for broken links
* WIP: Contract tests against stubs
* Store package after tests pass

Note: Contract tests are not there yet, but want atleast some as an example

------

## Artifact Repository

* Packages stored in GitHub repo
* Tar.gz file in GitHub release
* Deployments use this package
* For CI, STG, and PRD environments

---

[🗺️](#/diagram)

# Deploy - CI

* Continuous Integration (CI) environment
* Purpose is to test specific micro-frontend

---

[🗺️](#/diagram)

# Release

* Code under dev toggle not available
* Feature flags for CI setup
* Flags "on" so can test new features

Note: How automate CI testing with flags on and off?

---

[🗺️](#/diagram)

# Observe

* Deployment markers
* WIP: Use [Logz.io 🔗](https://logz.io/)

---

[🗺️](#/diagram)

# Test

* Post deployment testing for CI
* WIP: Smoke tests
* Triggers **continuous deployment** workflow

Note: Don't have these setup yet... need some examples.

---

[🗺️](#/diagram)

# Deploy - STG

* Deploy to Stage (STG) environment
* Automated if CI deployment passes
* Purpose is to test whole front-end (together)
* Stage is "production like" as possible

---

[🗺️](#/diagram)

# Release

* Feature flags for STG setup
* Flags set for what want in PRD (Blue)
* Test flag combinations across whole frontend

Note: How automate STG testing with flags on and off?

---

[🗺️](#/diagram)

# Observe

* Stage is always running
* Check its health / heart beat?
* Deployment markers

------

## Performance testing

Is this part of observe?

---

[🗺️](#/diagram)

# Test

* Post deployment testing for Stage
* Automated functional tests (i.e. PVT)
* Manual exploratory tests?

Note: Do we have a stage gate for exploratory testing. No! Do in Canary (PRD - Blue)

---

[🗺️](#/diagram)

# Deploy - PRD (blue)

* Deploy to Production environment
* Using [blue/green approach 🔗](./devops-demo-blue-green.md)
* Blue is for deploying latest changes
* Released to customers (small %)
* Mitigates risk in real world conditions

------

## Blue / Green Deployment

* [SAFe DevOps - Blue / Green Deployments 🔗](./safe-devops.md#blue-green-deployment)
* AWS Route 53 for blue/green routing of domain
* Blue limited to small % using [weighted routing 🔗](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html)
* (Optional) Blue could use [geolocation 🔗](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html)
* (Optional) Could use automated [failover routing 🔗](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-failover.html)
* [SAFe DevOps - Selective Deployments 🔗](./safe-devops.md#selective-deployment)

------

## Self-Service Deployment

* [SAFe DevOps - Self-Service Deployments 🔗](./safe-devops.md#self-service-deployment)
* Manually trigger workflow in GitHub Actions
* Within the `ss-pipeline` repo
* WIP: Can target a specific build

---

[🗺️](#/diagram)

# Release

* Feature flags for PRD(Blue) setup
* Flags set for what want in PRD (Blue)
* Use flags to do **canary release**

------

## Canary Releases

* Flags for Prod cover both blue and green
* Can use flags to release to subset of users
* Canary releases covers both blue and green

---

[🗺️](#/diagram)

# Observe

* Full observation of production environment
* Prod Blue/Green share same observation scope

Note: No obs setup yet. What could I cover?

---

[🗺️](#/diagram)

# Test

* Post deployment testing for Prod (Blue)
* Failures block PRD Green deployment

------

## Automated "Andon Cord"

* Ops issues trigger "Andon Cord"
* PRD Green deployments blocked
* Resolve issues in STG and PRD Blue
* Close "Andon Cord" to continue

---

[🗺️](#/diagram)

# Deploy - PRD (green)

* Deploy to production (Green) environment

---

[🗺️](#/diagram)

# Release

* Released to customers (all)
* Feature flags for "release" (blue & green)
* Features flags decouples deployed vs released

------

## Deployed vs Released

---

[🗺️](#/diagram)

# Observe

* Full observation of production environment
* Prod Blue/Green share same observation scope
* Observation = Continuous Testing

Note: No obs setup yet. What could I cover?

---

[🗺️](#/diagram)

# Test

* Post deployment testing for PRD (Green)
* But also continuous monitoring / testing
* WIP: Automate rollbacks

------

## Rollback Approaches

* Turn off features via feature flags
* Switch beteen blue/green
* Instant rollback (i.e. in Vercel)

------

## Blue / Green Switching

* [SAFe DevOps - Blue / Green Switching 🔗](./safe-devops.md#blue-green-switching)
* WIP: Automate via GitHub Actions Workflow
* Controlled via GitOps (configuration version control)
* Automates changes to AWS Route 53 routing
* Changes target for deploying active (blue) changes

---

[🗺️](#/diagram)

# Feedback

* Shifting left = Faster Feedback

---

[🗺️](#/diagram)

# Plan

* Feedback factors into planning
* Continuous improvement
* Both of Features and Enablers