Application Lifecycle and Development Models

Understand What Application Lifecycle Management Is

• Three development models are introduced:
  • Change set development
  • Org development
  • Package development
• Best practice is to always make metadata changes in the Sandbox
  • Developing dashboards, reports, and email templates can be safely done in production
  • Some changes can only be made in the Sandbox - writing APEX code, for example
• Move to Change Sets for safer customizations
• Move to Application Lifecycle Management:
  1. Plan Release
  2. Develop
  3. Test
  4. Build Release
  5. Test Release
  6. Release
     
     
• Which of the following can you safely create in production?
  • Reports and dashboards
  • NOT: Apex classes, triggers, workflow rules
• How does using the ALM process help development go faster?
  • The process helps you avoid breaking things, so the work proceeds more smoothly

Learn the Basics of Release Management

• A “Release Management Process” is a way of systematizing what changes get deployed when. Teams commonly have large and small projects in progress, all at different steps in the cycle.
  • Best practice is that releases fall into one of three categories:
    • Patch
      • Bug fixes, simple changes
      • Ex: reports, dashboards, list views, email templates
    • Minor
      • Changes with limited impact
      • Usually require testing, but only limited training and change management
      • Usually delivered within a few weeks
      • Ex: new workflow rule or trigger impacting single business process
    • Major
      • Changes with significant impact, including one or more dependencies
      • May greatly affect the user experience and data quality
      • Require thorugh testing, training, and careful change management
      • Usually delivered once per quarter (Salesforce does it three times per year)
• In change set development, a team’s release artifact is a set of metadata changes (like a diff or delta) relative to what’s in production. If it doesn’t change, its not in the release.
  • Each developer tracks any changes made in their customization for the release (using spreadsheet or a work tracking system)
  • Release managers must discover and include dependent components in the release
  • Migrating profiles and permission sets is tricky for reasons documented in this blog post and this one
• Releases can include multiple projects, and each project might be tested in separate environments. But, before build, changes from all projects should be migrated to the same environment for integration. Then, the changes and customizations in a release travel together as a single integrated change set going to production.
  • The release manager should track changes from all release contributor. S/he should also track any changes made in production that aren’t reflected yet in development or test environments. This way, s/he won’t inadvertently overwrite changes in production.
    
    
• What is a change set?
  • A build of metadata changes, possibly unrelated, to be deployed at the same time.
• How does tracking metadata changes in a release help you avoid problems when you migrate the release change set to a new environment?
  • Some metadata components might not yet be available in Metadata API, so they ahve to be manually migrated.

Manage Changes in Increasingly Complex Releases

• An org development model is a more rigorous change management process (like a version control system).
  • Use it to cope with increasing complexity, and to
  • Perform certain changes that cannot be accomplished using change sets (deleting fields, for example).
• In the org development model, a team gets a major change management improvement by externalizing the changes. They use the Salesforce CLI to extract metadata from a development environment to integrate with a version control system.
  • As with change set development, all three team members still need to track the changes they’re making. The team still needs to know which components change, and some changes aren’t represented in Metadata API and so will need to be recreated manually in the target org.
  • When team members complete their respective development assignments, they use the Salesforce CLI to retrieve the changes instead of using declarative tools to create a change set. Then, they are integrated together using a version control sytem.
  • Once all the changes are compiled, they can be deployed together into the build environment for integration and testing. As before, the result is a single release artifact that is a single consolidated set of changes.
    
    
• How does org development help teams with their change-management challenges?
  • Changes between team members can be merged in a conrolled manner.
• What is true about org development and change set development?
  • The release artifacts contain changed and new metadata components.

Use Package Development for More Flexible Releases

• In package development, different customizations are managed as separate packages, not as one big release of changes to the org
  • Move to this model when integrating many unrelated changes from multiple teams becomes too challenging.
  • Packages contain all the relevant metadata (both changed and unchanged components).
  • Organizing metadata updates by packages helps create a better mental model of how the org’s metadata is structured.
• Package versions are a fixed snapshot of the package contents and related metadata.
• 3 main selling points for package development:
  • Creating a clear audit trail of how org metadata changed over time
  • Gain productivity by freeing up time currently spent tracking setup changes
  • Gain release flexibility, because each package can be developed, tested, and released independently of packages for other projects
• Source of Truth comparison:
  • Package development: metadata in the project package
  • Change set development: combination of metadata already in the environment and the last build of the change set. On its own, a change set isn’t a complete picture. It only includes what has changed.
• Scratch orgs are empty development environments that are easy to create and dispose of as needed (no data or metadata).
  • Can be set up to be different Salesforce editions with different features and preferences.
  • When using scratch orgs, you first push the source from your project in the version control system to sync the scratch org. You can then use Setup for development. Pull down the modifications you made to include them in the project, and then use the version control system to commit all the changes.
• Packages can have separate release schedules. Packages segment ownership of the org metadata, so each project has its own package plus any dependent packages.
  • Each metadata component can only be in one package at a time. If more than one package needs the same component, you can use a modular package strategy for that component.
• Each package (and any dependencies) can be tested in isolation from all other metadata in the org.
  
  
• What metadata changes do you need to track manually when using the package development model?
  • Changes to components not yet supported by source tracking.
• What is a key benefit of a scratch org?
  • You can share its definition file with others.