(DevOps) How to select a relevant Application Lifecycle Management (ALM) Salesforce model for your organisation?

 

How to select a relevant Application Lifecycle Management Salesforce Model for your organisation?

Salesforce provides many different development tools and process to help meet customer requirements and needs. As many companies use Salesforce and Application Lifecycle management (ALM) processes, Salesforce has introduced three different models to manage ALM process within the organisation as shown below:

• Change set development

• Org development

• Package development

From the surface all the above three development models follow the same ALM process. However, the models differ in the way they allow changes to your org and how you manage these changes. Controlling change is a huge deal in software development, and you could choose the development model that best suits your organisation needs and requirements.

Firstly, let us understand what is the meaning of ALM for an organisation. Application Lifecycle Management is an integrated system of people, tools and processes that supervise a software application from its initial planning and development through testing and maintenance and into decommissioning and retirement. 

This article focuses on the journey of a Salesforce DevOps professional and what are the various development and operations challenges faced by organisations over a period of time. I will also explain and provide examples of how to use each development model to meet the needs of different situations with your salesforce org.

If you are an admin or a developer in a growing team, do you have the following challenges?

• You are required to make lot of customisations in production environment on critical dashboards and reports for Leadership.
• Most of the development work is done in one or two sandboxes and it becomes difficult to track who made each change and what stage of release each change belongs to.
• If it involves a lot of manual process in plan and release changes into production
• In the absence of a versioning and source control, team members unwittingly overwrite each other's changes and run into conflicts
• You spend a lot of time recreating inbound change sets for outbound deployment and adhere to long waiting for change sets to be uploaded to your target orgs.
• Although your team may be successful with releases, you need lot of additional resources in order to overcome chaos and the ensure the projects in the pipeline do not increase.

 If your team experiences any of the above challenges, Salesforce offers Application Lifecycle Management process which establishes a framework for developing new and customised apps and allowing bug fixes and feature enhancements quickly over time. 

Source: trailhead.salesforce.com

In order to overcome project chaos and bring an order to complex release cycles, ALM provides us with process and policies that help build apps smoothly without breaking things in the salesforce org. Although apps and ALM tools could vary but the steps to follow ALM process remains same to all Salesforce development projects. The stages of ALM are:

1: Plan the Release - Start your project with a plan by gathering customer requirements, creating technical and design specs, set up the sandbox (if not already available) to create the release.

2. Develop Changes - Develop the necessary components as per the design specs in the sandbox which contains a copy of the production org's metadata with no production data. If you are using Salesforce Lightening you could use a combination of declarative and imperative tools (process builder, custom object wizard, vs code and other UI tools) to build your components quickly.

3. Test Changes - This is an important step in ALM process. Each functionality would need to be individually tested and tested with integration to understand how these changes affect other parts of the release or the app as a whole.

4. Build Release - Aggregate all the assets you have created or modified during the development stage into a single release artefact: a logic integrated bundle of customisations or app that represents a release you will be delivering to the customer.

5. Test Release - Run full regression tests, performance and user acceptance tests to ensure that your test environments mimic all the external systems on the integrated release build.

6. Deploy Release - When you have completed testing and the you obtain approvals for meeting all  quality benchmarks, deploy this build into customer's production environment.

What is a Release?

Before we start discussing the ALM development models, let us first understand the three categories of a release:

a. Patch bug fixes and simple changes - the changes to reports, dashboards, list view and email templates fall under this category of simple changes.

b. Minor changes with limited impact - Adding or updating workflow rules, triggers, or creating or changes impacting a single business process fall under this category of minor changes. 

These releases typically require some testing but have only limited change management and training requirements. This type of changes are ideally delivered by teams within few weeks.

c. Major changes with significant impact - Any changes which impact one or more dependencies such as a new business process, complex workflows would fall under this category of major changes which have significant impact on customer's salesforce org. This type of changes require extensive testing, training and careful change management. Major release are typically delivered fewer times in a year. 

Change Set Development: 

Let us now understand what is Change set development and what are the typical scenarios in which this ALM model is used.

The change set development contains customisations that you want to send from one organisation to another organisation. These customisations can include new components or modifications to existing components such as apps, objects, reports or Apex classes and triggers. A change sent cannot be used to delete or rename components in another organisation.

The typical scenarios where a change set development is recommended are when your team's artifacts consist of mostly meta data changes and customisations provided via Setup UI to create changes in development environment and migrate these changes between sandbox environments as they progress through ALM steps. For example, any changes or updates to workflows, apex classes and triggers, role hierarchies will be part of change set development.

Org Development:

As with the change set process, the release artifact they are creating is relative to their production org. However, in the org development model, the team can get to push major change management improvements by externalising the changes they are making. Using Salesforce CLI to extract metadata from a development environment via scripts and integrate these changes with a version control system.

There are some similarities between change set development model and org development model where the team members need to track the changes they are making. The team needs to know which components change, whether they add these components to change set or retrieve them from sandbox environments via Salesforce CLI. Some customisations cannot be deployed to another org because they include changed components which are not represented in Metadata API. These components or changes would need to be manually re-created and added to the target org. So, it is important to keep track of changes in build environments.

When team members complete developing changes, they would need to move their changes to a build environment for integration. By now they would be using Salesforce CLI to retrieve changes from their respective development sandboxes instead of using declarative tools to create a change set. The version control system helps integrate changes so that they can be committed and tracked for each version.

Each change committed and tracked in the version control system is a key benefit to the team which prevents accidental overwrites and conflicts could be identified before a change gets overwritten. Going into the build step, the customisations from the team are already integrated into the project on the source control. From the version control system, these changes are deployed together to create a build for integration and testing. The changes are consolidated together into this build for creating a single release artifact. The team uses Salesforce CLI to retrieve the artifact from the build environment to move to the next environment. 

Though additional tools are used in org development model, the basic ALM steps; the change set concept, the environments used for development, testing and integration are the same.

Package Development:

Unlike the org development model where all changes are consolidated into a single release, the package development model manage different customisations as separate packages. When a release becomes complex and has many unrelated changes, it makes sense to manage the changes in org as multiple containers. 

If your team is already building modular artifacts for release, they will find some similarities with package development model. Customisations such as custom force.com apps, extensions to sales cloud, service cloud , etc., extensions to existing AppExchange apps, updating shared libraries and functionality fall under the category of major changes (discussed above) and would require separate packages to be released.

When you are working in a package development model, you build a release artifact that you can test and release independently in the build environment. Instead of testing each individual set of changes relative to production org, your team creates a package that contains all the relevant metadata changes which includes both changed and unchanged components. 

If the metadata updates are organised as a separate package, it also helps to create mental models of the metadata is structured in your org. If you want to manage your org as multiple containers, each package represents one of those containers.

A package version is a fixed snapshot of components and related metadata. The package version allows you to manage what is different each time you release and deploy a specific set of changes added to the release. If you are introducing metadata changes to an already deployed package, you upgrade the current package version to a new version of the package.

In package development model, you can maintain separate release schedules for each package. You use packages to segment the ownership of org metadata, so each project has its own package plus any dependent packages. You could upgrade individual segments independently through each sub-segment package versions, allowing you to manage separate release schedules.

However, with this method, package dependencies occur where a metadata component can only be in one package at a time. If more than one package needs the same component, you could devise a modular package strategy for that component. A package containing one or more metadata components shared by multiple packages is called a package dependency.

Each package should be tested in isolation from all other metadata in the org. Isolating the metadata into packages gives flexibility to version these set of changes (metadata) independently. This provides the flexibility to release the packages independently. 

Depending on the changes and your organisations needs , one of the three relevant ALM models could be adopted to manage and deploy changes into the target org.