Slide deck from my talk to the London Salesforce Developers on deploying in Salesforce
Text of Deploying to the Salesforce1 Platform
Deploying to the Salesforce1 Platform July 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 Doesnt 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
