deploying to the salesforce1 platform
DESCRIPTION
Slide deck from my talk to the London Salesforce Developers on deploying in SalesforceTRANSCRIPT
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