Deploying to the Salesforce1 Platform
•Télécharger en tant que PPTX, PDF•
5 j'aime•1,294 vues
Slide deck from my talk to the London Salesforce Developers on deploying in Salesforce
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Deploying to the Salesforce1 Platform
Similaire à Deploying to the Salesforce1 Platform (20)
Plus de Keir Bowden
Plus de Keir Bowden (20)
Dernier
Dernier (20)
Deploying to the Salesforce1 Platform
- 1. Deploying to the Salesforce1 Platform July 23rd 2014 Keir Bowden, Chief Technical Officer, BrightGen @bob_buzzard
- 2. Deployment • Moving release artifacts • Salesforce tools only • Not distribution – Your org(s) • “To position troops in readiness for battle”
- 4. Force.com IDE • Eclipse Plugin • Deploys through metadata API • Summer 14 version available • Open source
- 5. Pros • No setup • Deploy to any server • Backs up destination • Destructive Changes
- 6. Cons • Entirely manual • Slow – Locks Eclipse – Progress in main UI • Not repeatable – Redeploy = latest versions
- 7. When to Use • Infrequently • Very small changes • Unconnected Orgs • 1 person team
- 8. Change Sets
- 9. Change Sets • Standard UI • Point and Click
- 10. Pros • No developer skills • Audited • Dependency assistance • Infinitely repeatable
- 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. When to Use • Frequently • Small to medium changes • Administrator only skillset • One-off deliveries • Separation of Duties
- 13. Migration Tool
- 14. Migration Tool • Ant extension • Scripted
- 15. Pros • Deploy to any server • Integrates with source control – Repeatable • Integration with CI tools • Can be automated
- 16. Cons • Up front setup cost – Scripts are software • Requires developer skillset • Password stored in cleartext – On-premise only
- 17. When to Use • Frequently • Large changes • Repetitive deployments • Multi-stage release process • Existing build/release process
- 18. Managed Package
- 19. Managed Package • Container for Salesforce components • Create from developer edition
- 20. Pros • Manages dependencies • Install into any org • Upgradeable • Namespaced • Easy rollback through uninstall
- 21. Cons • Separate codebase • Limited customisation • Consumes limits – E.g. tabs • 75% test coverage to upload
- 22. When to Use • Rarely • Multi-org strategy – Fixed starting point – Common Configuration • Locked down • Centrally managed
- 24. Unmanaged Package • Container for Salesforce components • Create from developer edition
- 25. Pros • Manages dependencies • Install into any org • Customize installed components • Easy rollback through uninstall
- 26. Cons • Separate codebase • Not namespaced – Increased likelihood of conflicts – Some auto renaming • Not upgradeable • 75% test coverage to upload
- 27. When to Use • Very rarely • Multi-org strategy – Common starting point – Autonomy for customization • Production org without sandbox
- 28. Gotchas
- 29. Upgrade Windows • Three Salesforce releases/year • Multi-week rollout • Different source/target versions • Tools can become flaky
- 30. Manual Changes • Not everything is deployable • Manual changes are required • Document in release instructions • Four eyes principle
- 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. And finally • Technology is part of the solution • Governance may influence decision • Soft requirements: – Communication – Training – User Lockout
- 33. Thank You
Notes de l'éditeur
- Predicts dependencies but doesn’t manage them can’t know the status of the org you are going to deploy into, so suggests everything.
- No destructive changes (outside of ISV on the app exchange – not distribution remember).