continuous integration for salesforce1 platform

CONTINUOUS INTEGRATION ON THE SALESFORCE1 PLATFORM

Kevin GeeDirector of Product Management

TechSophy, Inc.

Release Management Streamlined Confidential AutoRABIT (Rapid Automated Build Install & Test)

The Problem

• Too many administrators• Lack of coordination• Changes made directly in production• Mostly manual steps for deployment• Manual testing with limited test coverage• Multiple production orgs with no common

code

…SLOW RELEASE VELOCITY


Manual Process with Slow Release Velocity

Manual Release Process

Quarterly release

17 member deployment team

11 day deployment time

40 page deployment process

DEMO: SANDBOX TO PRODUCTIONWITH CONTINUOUS DEPLOYMENT


24X Increase in Release Velocity

Manual Release Process Continuous Deployment

Quarterly release 2X weekly

17 member deployment team 3 member deployment team

11 day deployment time 1 day deployment time

40 page deployment process 4 page deployment process


Manual Build Process

Longer Manual Test Cycle

Longer Manual Deployment

Process

More Changes in Build


Accelerated Build Process

Longer Manual Test Cycle

Longer Manual Deployment

Process

More Changes in Build

Automate Testing

Automate Deployment

Fewer Changes per Build


Continuous Deployment

Version Control Build Test Track Deploy

Changes can go from Dev to Production using automated pipeline

Philosophy is automate and coordinate as much as possible

Plan




Changes can go from Dev to Production using automated pipeline

Plan


First Step: Change Management

• Change Management Team– Functional Leaders– Business Analysts– Technical Architects– Power Users

• Release Management Strategy– What is allowed in each branch– Who is allowed to make changes where

Production

Test

Feature A

Feature B

Feature C

Dev Dev Dev Dev Dev Dev DevDev

Feature Team A

Feature Team B Feature Team C

BranchingStrategy

Tests

Tests

Tests

Release Management Strategy


Version Control Demo


• Changes can be rolled back• Changes are grouped by branch to minimize

conflicts• Treat metadata as code

Plan

Production

Trunk(Test Org)

Feature A

Feature B

Use Version Control Tool to Implement Branching Strategy


Automated Build Demo


Build on commitScheduled builds

Manual builds

Plan


Automated Builds


Automated Testing Demo


Changes get promoted when they pass automated tests

Plan

• Unit test• Functional Test• User Acceptance Test


Reporting


Reporting and Dashboard forTeam and Key Decision makers

Plan


Dashboard


Automated Deployment Demo


Deploy vertically from Sandbox to ProductionDeploy horizontally from Sandbox to Sandbox

Plan

HOW DO WE GET THERE FROM HERE?

Level Build Process Environments and Deployment

Testing Reporting

Level 4 • All build issues addressed through automation

• Continuous deployment to production• Feature sandboxes• Automated provisioning

• 100% code coverage• All testing automated• Code tested against large

number of potential configurations

• Real-time visibility

Level 3 • Triggered builds• Code, meta-data,

documentation, requirements subject to version control

• Separate Dev, Test, and Prod environments• Single button

deployment

• Very high test coverage• Test interaction between

code, meta-data, and data• Users create automated

test scripts

• Report trend analysis

Level 2 • Build on commit• Dependencies

managed

• Standardized deployment process• Full Sandbox• Selective Promote,

Change sets• Some automated

deployment

• Automated daily functional tests

• On-demand reporting

Level 1 • Source control utilized• Automated build

process

• Documented deployment process• Defined branching

strategy

• Large amounts of testing done at build

• Reports visible to entire team

Level 0 • Manual or semi-manual build process

• Changes made directly to Production

• Manual or no testing • Status visible only to individual developer


Single Org Manual Process

• Single Production Org• Multiple Admins• Manual Build Process

• Change Management• Version Control,

Central Repository• Automate Testing


Multiple Org Manual Process

• Multiple Production Orgs

• Multiple Admins• Manual Build Process• Desire to Consolidate

• Change Management• Version Control,

Central Repository• Automate Testing

Initial Stateof System

The Challenge is Greater when Migrating Changes between Very Different Orgs

Change B Metadata B

Change AMetadata A

Initial Stateof System

The Challenge is Greater when Migrating Changes between Very Different Orgs

Change B Metadata B

Change AMetadata A

THERE ARE KNOWN SOLUTIONS TO THIS

PROBLEM


Multiple Org Manual Process

• Multiple Production Orgs

• Multiple Admins• Manual Build Process• Desire to Consolidate

• Change Management• Version Control, Central

Repository• Automate Testing• Designate One Org as

Trunk• Gradually add other

Features to Trunk• Migrate Users and Data

when Trunk meets Requirements

Trunk

Test

Feature A

Feature B

Feature C

Dev Dev Dev Dev Dev Dev DevDev

Feature Team A

Feature Team B Feature Team C

BranchingStrategy

Tests

Tests

Tests

Release Management Strategy:Gradually Migrate Features from Other Orgs into Trunk

Org C



Manual Release Process Continuous Deployment

Quarterly release 2X weekly

17 member deployment team 3 member deployment team

11 day deployment time 1 day deployment time

40 page deployment process 4 page deployment process

Version Control Build Test Track DeployPlan

24X Improvement in Release Velocity vs Manual Deployment

Q&A

#[email protected]

continuous integration for salesforce1 platform

Software

automated code

coderelease management

sandboxrelease management

dashboardrelease management

dev toplanproduction

deployment manual testing

manual process

code coverage