Deploying to the Salesforce1 Platform

  • View
    487

  • Download
    3

Embed Size (px)

DESCRIPTION

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
  • Thank You