Deploying to the Salesforce1 PlatformJuly 23rd 2014

Keir Bowden,Chief Technical Officer, BrightGen@bob_buzzard

Deployment• Moving release artifacts

• Salesforce tools only

• Not distribution– Your org(s)

• “To position troops in readiness for battle”

Force.com IDE

Force.com IDE• Eclipse Plugin

• Deploys through metadata API

• Summer 14 version available

• Open source

Pros• No setup

• Deploy to any server

• Backs up destination

• Destructive Changes

Cons• Entirely manual

• Slow– Locks Eclipse– Progress in main UI

• Not repeatable– Redeploy = latest versions

When to Use• Infrequently

• Very small changes

• Unconnected Orgs

• 1 person team

Change Sets

Change Sets• Standard UI

• Point and Click

Pros• No developer skills

• Audited

• Dependency assistance

• Infinitely repeatable

Cons• Doesn’t scale well

• No automation, destructive changes

• Can be slow to appear – 30 mins plus

• Connected Orgs Only

• Profiles behave unexpectedly

When to Use• Frequently

• Small to medium changes

• Administrator only skillset

• One-off deliveries

• Separation of Duties

Migration Tool

Migration Tool• Ant extension

• Scripted

Pros• Deploy to any server

• Integrates with source control– Repeatable

• Integration with CI tools

• Can be automated

Cons• Up front setup cost

– Scripts are software

• Requires developer skillset

• Password stored in cleartext– On-premise only

When to Use• Frequently

• Large changes

• Repetitive deployments

• Multi-stage release process

• Existing build/release process

Managed Package

Managed Package• Container for Salesforce

components

• Create from developer edition

Pros• Manages dependencies

• Install into any org

• Upgradeable

• Namespaced

• Easy rollback through uninstall

Cons• Separate codebase

• Limited customisation

• Consumes limits– E.g. tabs

• 75% test coverage to upload

When to Use• Rarely

• Multi-org strategy

– Fixed starting point

– Common Configuration• Locked down• Centrally managed

Unmanaged Package

Unmanaged Package• Container for Salesforce

components

• Create from developer edition

Pros• Manages dependencies

• Install into any org

• Customize installed components

• Easy rollback through uninstall

Cons• Separate codebase

• Not namespaced– Increased likelihood of conflicts – Some auto renaming

• Not upgradeable

• 75% test coverage to upload

When to Use• Very rarely

• Multi-org strategy– Common starting point– Autonomy for customization

• Production org without sandbox

Gotchas

Upgrade Windows• Three Salesforce releases/year

• Multi-week rollout

• Different source/target versions

• Tools can become flaky

Manual Changes• Not everything is deployable

• Manual changes are required

• Document in release instructions

• Four eyes principle

Rolling Back• Not possible on Salesforce!

• Strategy depends on tool

• Create “undo” artefacts/instructions

• Production deploy – refresh sandbox– Complete snapshot of original

config

And finally• Technology is part of the solution

• Governance may influence decision

• Soft requirements:– Communication– Training– User Lockout

Thank You