We’ve all been there. You work hard to put the right tools in place for your organization, and the needs change. The applications that were a perfect fit a short time ago now need to be updated quickly and efficiently. Those new applications might be enhanced versions of the ones you use today, or they may be completely new applications. When developing and deploying those applications, you want everything – the development, testing, and deployment – to go smoothly. When things don't go smoothly, you lose time and money.

Do the following scenarios sound familiar?

  1. Developers complaining about overwriting each other’s work.
  2. New features working in test environments, but not when moved to production.
  3. New features failing in production deployments.

If you’re nodding your head, chances are your organization could benefit from a more efficient application lifecycle management process.

Application lifecycle management is the process of managing an application's development, from design to final release, and establishing a framework for managing changes. The lifecycle typically begins with the addition of a new feature to an existing application or a request for a change. A plan is then developed to create that new feature or customization, and the new feature or customization gets designed and tested. Finally, it's placed into the production environment for consumption by end users. The cycle repeats for every new feature or customization.

Making changes in Salesforce                                                            

Developing on the Force.com platform makes it easy to circumvent the application lifecycle process, leading to the scenarios above. Here are some common issues that can end up costing your business time and money:

1)    Multiple developers can work in a single sandbox and make changes to the same metadata, increasing the likelihood of overwriting changes. Because Force.com lacks native support for versioned changes, overwriting changes becomes a big issue.

2)    Governor limits can cause business logic to behave differently based on data volume, so code that works in a test environment could fail to work in a production environment.

3)    Finally, because Force.com makes it easy to customize your applications directly in production, it can be tempting to bypass traditional release management practices and make those changes directly in production, causing your production environment to get out of sync with its sandboxes.

At Trifecta, we recommend using a version control system and continuous integration process, along with the following tips to ensure a smooth release of new features to your end users.

Require developers to develop in separate sandboxes                    

Generally, Salesforce developers working in the same sandbox overwrite each other’s changes. Versions of changes are not stored, meaning that the last switch to an object or field is the change that persists. When developers work in separate sandboxes, they each receive separate copies of objects and fields, lessening the chance that they will overwrite changes made by another developer. 

Test new features in a full-copy sandbox                                                 

New features might work well when operating on a small set of data. However, those same features can potentially fail when working on a large set of data. The reason for this discrepancy is mainly attributable to Salesforce governor limits. To ensure that your new features will work in both test and production environments, it’s best to test them in an atmosphere that most directly reflects your production environment: a full-copy sandbox, which includes the same set of data as in production.

Limit changes made directly in production                                                      

When you remove object fields and activate workflow rules in production without replicating those changes back into sandbox environments, you run a high risk of incurring deployment errors when it comes time to deploy new features to production. For example, if you activate a workflow rule in production, but do not activate it in sandbox environments, a unit test for a new feature may succeed in the sandbox environment, but cause the production deployment to fail. This is because the current workflow rule in production causes the unit test to behave differently. For this reason, it’s best to make new changes in a sandbox and deploy those changes to production. Alternatively, you can track production changes and make sure to replicate those changes back into sandbox environments.

Summary                                                                                                               

A proper application lifecycle management process in Salesforce can alleviate unexpected problems, such as overwriting changes, new features working in a test but not in production, and failing deployments. This process, in turn, makes the development of new features, the testing of those features, and the deployment of those features to production run much more smoothly. In the long-term, these proven tips for working in Salesforce can save you both time and money.

Share this