O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Deploying to the Salesforce1 Platform

1.240 visualizações

Publicada em

Slide deck from my talk to the London Salesforce Developers on deploying in Salesforce

Publicada em: Tecnologia
  • Entre para ver os comentários

Deploying to the Salesforce1 Platform

  1. 1. Deploying to the Salesforce1 Platform July 23rd 2014 Keir Bowden, Chief Technical Officer, BrightGen @bob_buzzard
  2. 2. Deployment • Moving release artifacts • Salesforce tools only • Not distribution – Your org(s) • “To position troops in readiness for battle”
  3. 3. Force.com IDE
  4. 4. Force.com IDE • Eclipse Plugin • Deploys through metadata API • Summer 14 version available • Open source
  5. 5. Pros • No setup • Deploy to any server • Backs up destination • Destructive Changes
  6. 6. Cons • Entirely manual • Slow – Locks Eclipse – Progress in main UI • Not repeatable – Redeploy = latest versions
  7. 7. When to Use • Infrequently • Very small changes • Unconnected Orgs • 1 person team
  8. 8. Change Sets
  9. 9. Change Sets • Standard UI • Point and Click
  10. 10. Pros • No developer skills • Audited • Dependency assistance • Infinitely repeatable
  11. 11. Cons • Doesn’t scale well • No automation, destructive changes • Can be slow to appear – 30 mins plus • Connected Orgs Only • Profiles behave unexpectedly
  12. 12. When to Use • Frequently • Small to medium changes • Administrator only skillset • One-off deliveries • Separation of Duties
  13. 13. Migration Tool
  14. 14. Migration Tool • Ant extension • Scripted
  15. 15. Pros • Deploy to any server • Integrates with source control – Repeatable • Integration with CI tools • Can be automated
  16. 16. Cons • Up front setup cost – Scripts are software • Requires developer skillset • Password stored in cleartext – On-premise only
  17. 17. When to Use • Frequently • Large changes • Repetitive deployments • Multi-stage release process • Existing build/release process
  18. 18. Managed Package
  19. 19. Managed Package • Container for Salesforce components • Create from developer edition
  20. 20. Pros • Manages dependencies • Install into any org • Upgradeable • Namespaced • Easy rollback through uninstall
  21. 21. Cons • Separate codebase • Limited customisation • Consumes limits – E.g. tabs • 75% test coverage to upload
  22. 22. When to Use • Rarely • Multi-org strategy – Fixed starting point – Common Configuration • Locked down • Centrally managed
  23. 23. Unmanaged Package
  24. 24. Unmanaged Package • Container for Salesforce components • Create from developer edition
  25. 25. Pros • Manages dependencies • Install into any org • Customize installed components • Easy rollback through uninstall
  26. 26. Cons • Separate codebase • Not namespaced – Increased likelihood of conflicts – Some auto renaming • Not upgradeable • 75% test coverage to upload
  27. 27. When to Use • Very rarely • Multi-org strategy – Common starting point – Autonomy for customization • Production org without sandbox
  28. 28. Gotchas
  29. 29. Upgrade Windows • Three Salesforce releases/year • Multi-week rollout • Different source/target versions • Tools can become flaky
  30. 30. Manual Changes • Not everything is deployable • Manual changes are required • Document in release instructions • Four eyes principle
  31. 31. Rolling Back • Not possible on Salesforce! • Strategy depends on tool • Create “undo” artefacts/instructions • Production deploy – refresh sandbox – Complete snapshot of original config
  32. 32. And finally • Technology is part of the solution • Governance may influence decision • Soft requirements: – Communication – Training – User Lockout
  33. 33. Thank You

×