Application Lifecycle Management

Note - You can use Jenkins as a continuous integration platform to push data to the Integration Org and execute unit test whenever changes are detected in a code repository.

Org Development model:

source repo reflects what they are delivering

Salesforce DX Project:

In addition to source files, the project contains a configuration file, sfdx-project.json. This file contains project information and enables you to leverage Salesforce DX tools for many of your development tasks.

You can think of the DX project as your outbound change set, where you’re managing and collecting the changes that you want to send to your production org.

Step 1: Plan Release

Start your customization or development project with a plan. Gather requirements and analyze them. Have your product manager (or equivalent) create design specifications and share them with the development team for implementation. Determine the various development and testing environments the team needs as the project progresses through the ALM cycle.

Step 2: Develop

Complete the work, following the design specifications. Perform the work in an environment containing a copy of the production org’s metadata, but with no production data. Develop on Lightning Platform using an appropriate combination of declarative tools (Process Builder, the Custom Object wizard, and others in the UI) and programmatic tools (Developer Console, Source Code Editor, or Visual Studio Code).

Note:

Each developer tracks any changes made in their customization for the release. The tracking tool can be anything from a spreadsheet to a work tracking system.

Eg:

A developer lists any manual changes required in the org pre- and post-deployment. These changes include metadata that can't be deployed, for example, profile and permission set assignments.

Use the Salesforce Extensions for VS Code to retrieve metadata from their development environments. Then they store the changes they make in the source control system. Once changes are in source control, they can create automated processes for testing and deploying to production.

Note: update .gitignore to ignore the below hidden files

.sfdx .vscode

to retrieve metadata from authorized developer sandbox org to local file systems

eg:

sfdx force:source:retrieve --metadata CustomObject:Language_Course_Instructor__c,CustomField:Language_Course__c.Course_Instructor__c

Metadata saved in the VSC can be deployed onto the dev org:

eg:

sfdx force:source:deploy --metadata CustomObject:Language_Course_Instructor__c, \ CustomField:Language_Course__c.Course_Instructor__c

Sandbox used - Each team member has their own Developer sandbox to create their assigned customization. Developer sandboxes contain no production data.

• Stage the changes

• Commit the changes to source control

• Push the changes committed to remote repository

• Create PR

• Request a code review

• Merge the changes to the remote branch

Step 3: Test (Unit Testing)

Exercise the changes you’re making to check that they work as intended before you integrate them with other people’s work. Do your testing in the same type of environment as you used in the develop step, but keep your development and integrated testing environments separate.

Step 4: Build Release(Build environment for integration, changes from all projects)

Aggregate all the assets you created or modified during the develop stage into a single release artifact: a logical bundle of customization that you deploy to production. From this point on, focus on what you’re going to release, not on the contributions of individuals.

Build the Release Artifact

It will have only changes made for this release.

Steps:

Convert source format to metadata forma

sfdx force:source:convert --rootdir force-app --outputdir tmp_convert

Create the .zip file of your changes:

jar -cfM winter19.zip tmp_convert

Note - Within the .zip file is a project manifest (package.xml) that lists what to retrieve or deploy

Delete the output directory, tmp_convert.

Test the release artifact in the Integration env.

sfdx force:mdapi:deploy --zipfile winter19.zip --targetusername partial-sandbox \ --testlevel RunSpecifiedTests --runtests TestLanguageCourseTrigger

Sandbox used - Each team member migrates their customizations from their respective Developer sandboxes to a shared Developer Pro sandbox for integration. Developer Pro sandboxes don’t contain production data, but you can seed them with testing data.

Step 5: Test Release(Staging(Full) Sandbox)

Test what you’re actually going to deploy, but test safely in a staging environment that mimics production as much as possible. Use a realistic amount of representative production data. Connect your test environments with all the external systems they need to mimic your production system’s integration points. Run full regression and final performance tests in this step. Test the release with a small set of experienced people who provide feedback (a technique called user-acceptance testing).

Sandbox used - For user-acceptance testing, the team uses a partial/full sandbox to create a complete replica of production (with/without production data).

Steps:

Run all local (regression) tests to validate the deployment without saving the components in the target org.

sfdx force:mdapi:deploy --checkonly --zipfile winter19.zip --targetusername full-sandbox \ --testlevel RunLocalTests

Test the actual production deployment steps in the staging sandbox.

sfdx force:mdapi:deploy --checkonly --zipfile winter19.zip --targetusername full-sandbox \ --testlevel RunSpecifiedTests --runtests TestLanguageCourseTrigger

Next, tests the quick deploy using the job ID returned in the previous step.

sfdx force:mdapi:deploy --targetusername full-sandbox --validateddeployrequestid jobID

Step 6: Release To Production

When you’ve completed your testing and met your quality benchmarks, you can deploy the customization to production. Train your employees and partners so they understand the changes. If a release has significant user impact, create a separate environment with realistic data for training users.

Sandbox used - After the release is in production, the team can use the full sandbox to train users without the risk of altering production data. A full sandbox includes a copy of production data

Steps:

Perform Pre-Deployment Tasks Listed in Deployment Run List

Check the deployment run list and see that any pre-deployment tasks to complete.

Set up the quick deploy:

sfdx force:mdapi:deploy --checkonly --zipfile winter19.zip --targetusername production-org \ --testlevel RunSpecifiedTests --runtests TestLanguageCourseTrigger

Run the quick deploy:

sfdx force:mdapi:deploy --targetusername production-org --validateddeployrequestid jobID

Perform Post-Deployment Tasks Listed in Deployment Run List

Org Development:

To learn more - https://trailhead.salesforce.com/content/learn/modules/org-development-model