continuous build to continuous release - experience

Purpose : Make Teamwork a Fun

To Simplify, we all need to transform ourselves continuously from

"Me Vs You" to

"Competing within Ourselves" to

"Winning Together As a Team"

Purpose

• To Derive the right Frequency of Delivery/Deployment, keeping in mind the Big Picture & Different needs (changing & evolving)• What should be the deployment cadence to Production

(Stories & Defects)

• Who are the Stakeholders & How would they get impacted? Best way to collate their inputs

People First

•People

•Process

•Tools/Methodologies & Environments

Ecosystem – People & Teams

• 3 Geographies (India, China, SJ)

• 7 Global Teams • GTM• POs+BAs• Scrum Teams – R&D+Product Support, OKTA, Cloud Convergence, LPE, Intgeration/Reporting, CPLL• UI/UX• VKM• MuleSoft• QA Team (Dev+System)

• Hand Off Process between Teams & Geographies • GTM to Product Mgmt, Product Mgmt. to BA, BA to Dev & UX/UI, • UX to UI UI to Dev, Dev To QA, QA To Support, Support To Production

Stakeholders, Needs & Impact

# Stakeholders Needs

1 96 Hrs Intimation to Customers before Deployment when there is Downtime

2 Customer Issues - How Fast it can be addressed

3 How Fast Stories, Defect Fixes Happens in Production

4 Aligning DoD, DevBox & Deployment Routines

5 Turning Off VMs to save Cost

6 Deployment Pipeline

7 Defect Fixes that are needed immediately

8 Reduction of Development Environments

9 ???


11 Need Time in creating UI Assets


Ecosystem – Process

Code Build Integrate Release Deploy

Continuous Build

Continuous Delivery/Release

Continuous Deployment

Compile + Unit Test + Package Deploy +

API / Functional Tests

Ready For Production Deployment

Continuous Integration

Ecosystem Dev Environments to Delivery Pipeline

Dev Environment – Laptop

Individual

(Feature Branch)

Dev Environment Cloud

Integration - Scrum Teams

(Release Branch)

Delivery Pipeline

(QA + UAT+ Production)

Scrum of Scrum

(Master Branch)

Ecosystem – Environments

Dev Environment :Local Laptop : Community Driven @Individual• Every developer is expected to

have a Local DevBox Setup in his/her laptop.

• It's based on Vagrant.• Developer is expected to

Manage/Understand the local development environment

• It's community driven. • No dedicated support will be

provided.• There is a Spark Room.

Dev Environments : Cloud : @Scrum Teams• Every Scrum Team is

expected to push the code with Automation tests & Features to a continuous Integration Environment

• It's owned by the Scrum Team.

• It's an intentional setup to bring in Ops mindset to the developers.

• There is no dedicated support for this

Delivery Pipeline :Cloud : QA to UAT to GA @Product • Working code from which

all test pass gets merged to master and deployed to QA.

• QA will do round of testing & after all Automation, Regression & Manual Tests pass will promote to UAT.

• In UAT, BA & Product Owners Test the Functionality & after Acceptance gets promoted to Production

Ecosystem – Dev EnvironmentsLaptop to Cloud

Source Code Commit

(Feature Branch)

ManualBuild

ManualDeployment

Local DevBox(Automated) Unit Tests

AutomatedAPI Tests

Regression Tests Pass

Source Code Commit

(Release Branch)

Automated Build

Automated Testing

Successful Build, DoD Met

Report Test Results

DoD Met ? Unit Tests API, UI Functional Tests

Ecosystem - Delivery Pipeline

Compile & Unit Test

Build

Deploy To QA

Functional Tests

API Tests

Code Quali

ty Chec

ks

Deploy To

UAT

Functional Tests

API Tests

Code Quali

ty Chec

ks

UAT

Deploy To GA

Compile &

Unit Test

Build

Deploy To QA

Functional Tests

API Tests

Code Quality Checks

Deploy To UAT

Functional Tests

API Tests

Code Quality Checks

UAT

Deploy To GA

Ecosystem – Delivery Pipeline

Clicks Button To Deploy

Successful ?

Merge Code To Master

Automated Build, Unit Tests, Deploy,API & Functional

Tests

Report QA Verification

QAContinuous Integration

Successful QA Qualification ?

Promote Binary To UAT

UAT Report on UAT Verification

UATContinuous

Delivery

SuccessfulUAT ?

Promote Binary To GA

Manual Smoke Test

Successful Sanity -Ready for Use

GAContinuous

Delivery

Source Code Commit

(release_ck)

Automated Build

AutomatedCode Quality + Unit Test Coverage Tests

Continuous Build

DoD Met ? Unit Tests Quality Gates Pass

API, UI Functional Tests Regression, TCs Pass

UAT TCs Pass

Sprint Rhythm

M T W TH F S S M T W TH F S S M T W TH F S S M T W TH F S S M T W TH F S S

QA QA UAT UAT GA QA QA UAT UAT GA QA QA UAT UAT GA

Sprints

Current

Delivery

Pipeline

5Days

1Day

Sprint-3(Dev)

5Days 5Days 5Days

Sprint-3Deployment

2Days 2Days

Sprint-1(Dev) Sprint-2(Dev) Sprint-3(Dev)

Sprint-1Deployment Sprint-2Deployment

Common Minimum Process

RL setups upcoming Prod drop dates in rally.2.

Eng team updates the user stories with appropriate drop dates.

Deployment to QA happens everyday from release branch

QA validates the feature in QA env along with functional tests (as applicable)

Once the feature is completed, SL merged the code from release branch to master, so that it would be lined up for deployment pipeline.

QA cycle completes in 1.5 PDs (Assumption: S1=S2=S3=0). On any Priority issues, the respective feature will slip this cycle.

UAT deployment after successful QA certification

PO signs off in UAT env (1-2 PDs) & stories accepted in Rally

User stories/Defects are delivered in GA, Pilot environments.

Thanks

QA UAT GA

Cloud-1

Cloud-2

Until Movement To Cloud

Chef Chef Chef

Ansible Ansible Ansible

Milestone 2 Milestone 3 Milestone 4

continuous build to continuous release - experience

Engineering