SlideShare a Scribd company logo

Ladies Be Architects: Study Group IV: Project and System Governance

•Download as PPTX, PDF•
•
G
gemziebeth

In April 2018 the group voted to study the Development Lifecycle and Deployment Designer certification topic of governance.

Related slideshows

Introduction to Salesforce Platform - Basic
Introduction to Salesforce Platform - BasicIntroduction to Salesforce Platform - Basic
Introduction to Salesforce Platform - Basic
 
Microsoft and Nintex Forms
Microsoft and Nintex FormsMicrosoft and Nintex Forms
Microsoft and Nintex Forms
 
Microservices Architecture
Microservices Architecture Microservices Architecture
Microservices Architecture
 
1 of 24
STUDY GROUP IV: PROJECT AND SYSTEM GOVERNANCE GEMMA EMMETT
Your Ladies Be Architects profile here
APRIL CHAMPIONS:
Ladies Be Architects: Study Group IV: Project and System Governance
AGENDA • What does Governance mean? • Centre of Excellence • Release Management • Design Standards • Source Control • Deployment Best Practices
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
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
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
FORMING YOUR CENTRE OF EXCELLENCE… https://trailhead.salesforce.com/modules/app_deployment/units/app_deployment_gove
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
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
ENVIRONMENTS : INCIDENT RELEASE (ENTERPRISE) Build & Deplo y Hotfix sandbox TestSIT UseProduction
ENVIRONMENTS : DAILY RELEASES (ENTERPRISE) Build and Use Production
ENVIRONMENTS : MINOR RELEASES (ENTERPRISE) Build and deploy Production Support sandbox Deploy and Test SIT sandbox UseProduction
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
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
DESIGN STANDARDS: WHERE DO I NEED THEM? • In code and integrations • Documentation • In testing • When dealing with large data volumes
DESIGN STANDARDS: EXAMPLES • Use descriptions and standard naming conventions • Keep consistent data architecture for every project • Bulkify code • Agree a standard deprecation method
DESIGN STANDARDS: ENFORCEMENT • Communicate them – and their importance • Build them into your automated testing software • When QA-ing, take them into consideration consistently
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
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)
QUESTIONS?
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!
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 

More Related Content

Ladies Be Architects: Study Group IV: Project and System Governance

  • 1. STUDY GROUP IV: PROJECT AND SYSTEM GOVERNANCE GEMMA EMMETT
  • 2. Your Ladies Be Architects profile here
  • 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
  • 12. ENVIRONMENTS : INCIDENT RELEASE (ENTERPRISE) Build & Deplo y Hotfix sandbox TestSIT UseProduction
  • 13. ENVIRONMENTS : DAILY RELEASES (ENTERPRISE) Build and Use Production
  • 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 

Editor's Notes

  1. And….
  2. Depends on the company culture, frequency of releases, rules around when things can be released
  3. Depends on the company culture, frequency of releases, rules around when things can be released
  4. Depends on the company culture, frequency of releases, rules around when things can be released
  5. 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.