Ci for force dot com
•Descargar como PPTX, PDF•
2 recomendaciones•514 vistas
Using Jenkins for Continuous Integration on the Force.com platform
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Ci for force dot com
Similar a Ci for force dot com (20)
Último
Último (20)
Ci for force dot com
- 1. Continuous Integration for Force.com Projects Don McIntosh @donmac23
- 3. Continuous Integration Automating software build and release processes with built in quality control
- 4. Change Sets
- 5. Sandbox Flow for Small Teams
- 6. Deployment via Changesets Dev Dev QA UAT Prod Dev Dev
- 7. Do I Need Better CI? • IF you: – find it hard to manage changed components – have devs overwriting each other’s code – find collaboration between developers difficult – want earlier/more frequent integration between devs’ work – want a more detailed change history • OR: – are working in independent dev orgs
- 8. Benefits • Supports Agile process well • Scales to large teams • Detailed, auditable version history • Flexible version control • Easy(ish) to set up new Orgs • Works on any set of Orgs, not just related sandboxes + prod
- 9. What Do I Need? • CI Tool (Jenkins, Bamboo, Teamcity…) • Server for CI (or find a hosted service) • SCM (Git, SVN…) • Ant + Force.com Migration Tool • Shared list for manual changes • Development process • Package.xml contents
- 11. Release Management Master (prod) Develop (CI) QA UAT Time
- 12. Basic CI with Jenkins • Automated checks run on each change to source code (and/or config) • Prominent success/failure notification • Easy deployment to multiple Orgs • Build statistics • Build history and status for each Org • Demo…
- 13. Multiple update scenario • Fred: – Deletes field “Segment” from Account and replaces it with standard field “Industry” on Account page layout “Food Service Corporate Accounts” • Don: – Adding the field “SIC Description” to the same page layout
- 14. Salesforce Challenges & Solutions • Reconciling profile changes • Preventing regression back to obsolete config
- 15. Useful Improvements • Automated code analysis (eg: Village Chief’s Codescan) • System tests • Refresh sample records in test Orgs • Reports (eg: metadata summaries) • Direct integration with issue tracking software
- 16. A Few Tips • Pull often, not just when you are about to push • Refresh from prod to bypass manual steps • Expect some road bumps, especially early on • Build light is genuinely useful • Use a physical token for committing changes • Pay some attention to keeping unit tests fast
- 17. Thanks!
Notas del editor
- UAT – usually full copy; QA might be a dev pro or partial copy Some probs: confusion because of decentralised nature Constant version updates as components are added
- Dev process: not talking a lot about it but important to have stuff like peer review and definition of done, test handovers etc part of the process
- In demo: Show how to make a change: Pull Resolve conflicts Commit and push change Red light! Failed build due to old field still existing (didn’t build locally first, didn’t check manual changes) Fix build and push again Green light! Explain: How Jenkins is configured to auto-execute builds How Jenkins can kick off manual builds How you would git merge to test branch to deploy to testing (but don’t bother showing) Jenkins: - Show OC’s Jenkins with more history, scripts, build times chart etc
- Mention blog about unit tests speed up if you have written it