5. AGENDA
• What does Governance mean?
• Centre of Excellence
• Release Management
• Design Standards
• Source Control
• Deployment Best Practices
6. WHAT DOES GOVERNANCE MEAN?
• Management of the Salesforce org
• Management of releases
• Setting goals that align with the goals of the business
• Working together to achieve those goals
7. A CENTRE OF EXCELLENCE…
• Brings together:
• The right people
• The right knowledge
• To make the right decisions about changes to the org…
• …based on business goals…
• …and aligning with IT best practices
8. AN GOOD CENTRE OF EXCELLENCE…
• Reviews feedback from users
• Responds to enhancement requests
• Is transparent about goals and best practices
• Develops and shares the roadmap
10. WHAT YOUR CENTRE OF EXCELLENCE NEEDS
• A prioritised backlog:
• Bugs
• E.g. Fix an issue with a page taking too long to load
• Enhancements
• E.g. implement duplicate management
• E.g. approval process for opportunities
• A charter
• Business goals
• Strategies
• Principles
11. RELEASE MANAGEMENT PROCESS
• Hotfixes (Incident release plan)
• When stuff breaks
• Daily Releases
• E.g. Bug fixes, user management, changes to reports/dashboards, list views
• Minor Releases
• Changes without a big impact, e.g. fixing a simple workflow
• Need testing but no big change management considerations
• Major Releases
• Significant changes to the org such as introducing a new team or key business process
• Must be tested thoroughly and require change management and training
14. ENVIRONMENTS : MINOR RELEASES
(ENTERPRISE)
Build
and
deploy
Production
Support
sandbox
Deploy
and
Test
SIT
sandbox
UseProduction
15. ENVIRONMENTS : MAJOR RELEASES
(ENTERPRISE)
Build & Test
Dev
sandbox
•Peer QA
•Test
•Code Reviews
•Regression
Tests
SIT
sandbox
End user testing
& feedback
UAT
sandbox
•Deployment
tests
•Data migration
Staging
sandbox
UseProduction
16. GUIDING PRINCIPLES
• Think: are there any other projects going on?
• Test your stuff first!
• Keep sandboxes in sync
• Stick to the design standards given by architects
17. DESIGN STANDARDS: WHERE DO I NEED
THEM?
• In code and integrations
• Documentation
• In testing
• When dealing with large data volumes
18. DESIGN STANDARDS: EXAMPLES
• Use descriptions and standard naming conventions
• Keep consistent data architecture for every project
• Bulkify code
• Agree a standard deprecation method
19. DESIGN STANDARDS: ENFORCEMENT
• Communicate them – and their importance
• Build them into your automated testing software
• When QA-ing, take them into consideration consistently
20. SOURCE / VERSION CONTROL
• Each developer (or clicker!) checks their metadata into a repository
• You can specify a branch to check your changes into e.g. Feature, Hotfix, Default
(Production)
• Easy deployment of latest version into each sandbox – keeping them in sync
• Easy automated testing of items within the branch
21. DEPLOYMENT BEST PRACTICES
• Tools:
• Change sets: daily and minor releases – used by clickers
• IDE: Major and minor releases – used by coders
• DX: Command-line deployment – used by coders and seasoned retro fans
• Jenkins: for continuous integration (a drip feed of changes)
23. NEXT STEPS
• Check out the architecture Trailmix for the Development Lifecycle and
Deployment Designer certification
• Complete the Git and GitHub basics badge
• Work on a project with a multi-step release management process
• Having problems? Implement the process!
24. THANK YOU FOR COMING!
• Join our Trailblazer Community group
• Visit the website: www.archladies.com
• Post your exam successes into the group / on Twitter
• If you tweet, use #LadiesBeArchitects and mention @ArchLadies
• Get Involved –
• Run your own study group
• Speak about your experience
• Buy some swag & wear it to a Salesforce event
• Submit a member story
Notas do Editor
And….
Depends on the company culture, frequency of releases, rules around when things can be released
Depends on the company culture, frequency of releases, rules around when things can be released
Depends on the company culture, frequency of releases, rules around when things can be released
Depends on the company culture, frequency of releases, rules around when things can be released, other projects going on. This scenario is for when there are other projects going on and a minor release is needed.