Understand What Application Lifecycle Management Is

At a high level, all three development models follow the same ALM process. But the models differ in the way that they let you manage changes to your org. Controlling change is a big deal in software development, and you can choose the development model that best suits your situation if you understand your options.

Let’s follow the journey of a Salesforce professional and his company as their development challenges change over time. Over the course of the story, you learn how each development model meets the needs of different situations. Details on how to use the development models are covered in other modules in this trail.

Calvin Green takes on many technical roles for Zephyrus Relocation Services, a talent-mobility firm in Fairfax, Virginia. One of Calvin’s roles is to customize Salesforce for the company’s small but growing Sales team. Using the Setup interface in their production org, he knocks out an impressive variety of new dashboards and reports.

Calvin developed his skills as a Salesforce admin through Trailhead Military, the Salesforce job training and career accelerator program for military service members, veterans, and spouses.

You can safely develop some kinds of new functionality in a production org. Customizations that don’t affect data are safe to create in a production org, such as developing new dashboards, reports, and email templates. However, certain customizations made directly in production can create a mess by deleting data or even worse.

What can happen if you don’t test changes before making them available in production?

• A flow rule accidentally creates an infinite processing loop.
• A change in a field’s type modifies data in ways you can’t undo.
• A logic error in a validation rule prevents you from saving a record.
• Page layout changes confuse people instead of improving their experience.

The safest way to customize your org is to make and test changes using a dedicated environment for development. In fact, some changes must be done in a development environment. For example, you can’t write Apex code directly in a production org.

As Zephyrus continues to grow, the demand for Salesforce customizations grows with it. The company adds another staff member to help out. The increasing volume of customization requests includes new flows and page layouts, and Calvin wisely resists making these changes directly in the production org.

To meet its changing business needs, Zephyrus decides to upgrade to Professional Edition. In Professional Edition, Zephyrus can create and test what it needs using declarative (point-and-click) development tools in a separate development environment.

In the change set development model, Calvin and his colleague Ella can manage their application by using declarative tools. They don’t need to use a command-line interface or a version control system to meet the increasing customization needs of the Sales team they support.

With declarative tools, Calvin and Ella can create lots of nifty things that boost the productivity of the Sales team. For example, Calvin uses Lightning App Builder to create a filter that displays a rich text component on an opportunity page when the Amount is at least $1 million.

Now that customizations are made by multiple people in multiple environments, Calvin considers how he can manage the downstream impact of even minor changes.

For example, the Contact standard object doesn't have a field for Contact Type. Calvin can easily add that custom field and release the new Contact Type field immediately to all users. But should he?

• Does the new Contact Type field conflict with customizations made by someone else?
• Does the Sales team know how to use the new field or do they need training?
• If the field is required, do any integrations or import processes need updating?
• Where does the field appear? On all page layouts? Which list views? Does it show up in any reports or dashboards?
• Should the field be on the Lead object as well? If so, does the Lead conversion process change?
• Is the field required for integrations with other systems? If so, you might need to change middleware, field mappings, endpoints, and so on.

In the Salesforce Trailblazer Community, other members encourage Calvin to look into the application lifecycle management steps Salesforce recommends for developing new and customized apps.

On the Salesforce Developers website, Calvin learns that ALM defines the process of managing an app’s development, from design to final release. ALM also establishes a framework for making app bug fixes and feature enhancements over time.

In a meeting with Ernesto Rondán, the IT department director, Calvin argues for a move to application lifecycle management. ALM provides them with process and policies that help them build apps smoothly and therefore faster, without breaking things. Apps and tools can vary, but the steps in the ALM cycle apply to any Salesforce development project.

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. 

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 (Flow Builder, the Custom Object wizard, and others in the UI) and programmatic tools (Developer Console, Source Code Editor, or Visual Studio Code). 

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. At this point, focus on testing your changes themselves, not on understanding how your changes affect other parts of the release or the app as a whole. 

Step 4: Build Release 

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

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). 

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.