Salesforce Application Lifecycle Management

Salesforce application development requires a thorough understanding of the Application Development Lifecycle. This lifecycle is a comprehensive framework that guides developers and administrators through the process of creating, testing, and deploying applications that meet the evolving needs of their customers. Whether you’re working on a small project for a local business or managing a large-scale deployment for a multinational corporation, understanding this lifecycle is crucial for success. 

This blog provides an in-depth look at the stages of the Application Development Lifecycle and how it can be applied across various development models in Salesforce.

By reading this blog, you will:

• Understand the fundamental stages and their significance in Salesforce development.
• Gain insights into the essential activities involved in each phase, from planning and development to testing and release.
• Discover how the lifecycle applies to change set development, org development, and package development.
• Learn about the best practices to ensure efficiency and effectiveness throughout the development process.
• Explore a practical example illustrating the application of the lifecycle in integrating a new department into an existing Salesforce org.

Let’s get started!

Application Development Lifecycle

• The Application Development Lifecycle consists of the development tools and release processes used to make changes to your org to meet your customer’s requirements.
• The lifecycle should be developed to suit the needs of your customer, whether it is a small business, or a large organization with many departments, or a wider external user base.
• Application Lifecycle Management can be applied to the three primary development models: Change set development, Org development, and Package development.

Phases of the Application Development Lifecycle

Key phases and typical activities include:

1. Plan Release

• Develop a Release Plan.
• Gather requirements, requirements analysis, and design specifications.
• Determine what orgs will need to be available for development and testing.

2. Develop/Build

• Perform the build in a development environment, following the design specifications.
• The development environment should have a copy of the production metadata, but not a full set of production data.

3. Test

Test the build in an isolated development environment, ensuring that the individual components are functioning correctly (unit testing).

4. Build Release

Create a release artifact by selecting assets to include in the deployment.

5. Test Release

• Test the deployment in a staging environment that resembles production, including full or partial production data.
• Test the integration points by running end-to-end tests of business processes.
• Perform final regression testing, performance tests, and user acceptance testing.

6. Release

• Deploy to production
• Provide end-user training to effectively manage change and increase adoption.

Key Milestones in Application Development Lifecycle

Gather Functional Requirements

• Identify the current processes, including personas, workflows, and use cases.
• Write User Stories and Acceptance Criteria to describe how this will be implemented in Salesforce.

Design Application Business Specifications

• Work with Stakeholders to define the high-level goals or measurements of success for the project.
• Define what functionality should be delivered, as well as the scope boundaries, risks, assumptions, and dependencies.

Development (Salesforce declarative and programmatic features)

• Build the functionality required using the appropriate tools.
• Declarative tools include Process Builder, Flow Builder, Custom Object wizard or others in the UI.
• Programmatic tools include the Developer Console, Source Code Editor, or Visual Studio Code.

Unit Testing and Functional Testing

• Before code can be deployed to a production org, it must pass 75% code coverage.
• Functional testing can be performed by a QA team to test technical processes.

UAT (End User Testing)

• End-to-end testing by system users.
• Following test scripts to confirm that the Acceptance Criteria is met and the functionality delivered is fit for purpose.

Communication Plan and End User Training

• A Communication Plan should include key milestone dates about testing phases and deployment dates.
• Training will ideally be performed on an org that has a partial or full replica of the production data so that the end-users can more easily relate it to their tasks and business processes.

Release Features and Notify Users

• Upon successful deployment to the production org, end users can be notified and resume business as usual.

Release Types

Release typically falls into one of the three categories:

Patch Bug Fixes

• Can include changes such as reports, dashboards, list views, and email templates. Requires unit (isolated) testing.
• Can be deployed more frequently because they are typically smaller changes.
• Provides benefits to end-users to have issues resolved more regularly than the full release cycle.

Minor Change with Limited Impact

• Can include changes such as workflow rule or trigger impacting a single business process. 
• Requires limited training and change management. 
• These releases can also occur more frequently than major releases because they are low risk.

Major Changes with Significant Impact

• Includes changes with dependencies that have greater risk and require more testing, training, and release management.
• Have a greater effect on user experience and data quality.
• A major release might occur monthly or quarterly, depending on factors such as system complexity, the number of end-users, etc.

Application Development Lifecycle Development with Multiple Sandboxes

Plan

• A different Release Plan may be required when using multiple sandboxes, as different development teams could be working on different orgs.
• Greater coordination will be required to build a release as the deployment package will have multiple contributors.

Build

• Use scratch orgs for isolated development by the developers.
• Scratch orgs are ideal for rapid development that emulates production metadata and code and can be disposed of as per requirement.

Test

• A scratch org can be used for unit testing and to develop test coverage because there will not be any dependencies.
• Commit changes to a source control system (VCS).

Build Release

• Use change sets or metadata API integration to sync changes between scratch orgs and a common sandbox.
• Specify which assets are to be included by including them in change sets or a manifest file.

Test Release

• QA testing needs to be done in the sandbox, which will have a copy of the production metadata and a partial copy of business data. It is generally the partial copy sandbox. 
• This environment should be used for both system integration testing, regression testing, and user acceptance testing.

Release

• Test the release deployment to a full copy staging environment, which can also be used for end-user training.
• The final step will be a deployment to production that is coordinated with key stakeholders and business users.

Use Case

Cosmo Property has a procurement department that buys land for commercial or residential developments. This group uses Salesforce for Contacts but tracks these procurements and complex calculations offline in spreadsheets. 

How can Application Lifecycle Management be applied to integrate this department into the org? The suggested solution will use Accounts, Contacts, Opportunities, custom Objects, and custom Lightning Web Components for in-app calculators.

Solution: Scratch orgs can be used to develop the configurations and functionality for different objects and components.

The code can then be merged into a sandbox for testing and to ensure that the individual assets are integrated between each other, as well as the existing org.

Once passed testing, the full deployment can be released to a staging environment where the procurement users can be trained on running their business processes in Salesforce before the release into production.

Reason: This process describes an Application Development Lifecycle that safely integrates new functionality into existing org and manages change to onboard a new department onto an existing Salesforce platform.

Conclusion

In conclusion, mastering the Application Development Lifecycle is crucial for anyone looking to excel in Salesforce development. Understanding each phase, from planning to release, ensures that your applications not only meet customer requirements but also adhere to best practices for a seamless and efficient deployment process. Whether you’re a seasoned developer or new to the Salesforce platform, this lifecycle is your roadmap to successful application development and deployment.

Elevate your Salesforce skills with saasguru. Sign up now for a free trial and gain access to over 18 Salesforce Certification Courses, 50+ Mock Exams, and 50+ Salesforce Labs for hands-on learning. Don’t miss this opportunity to deepen your understanding and expertise in Salesforce, ensuring you’re equipped to tackle any project with confidence. 

Start your journey to Salesforce mastery with saasguru today.