March 7, 2019
Reduce Salesforce Deployment Time to Minutes

Reducing Salesforce Deployment Time With Flosum

One of the major pain points in building applications on the Salesforce platform is that the deployment time takes way too long. Although developers may find it quick and easy to build applications on the platform, they unfortunately find it time-consuming and difficult to deploy code. While the platform does support rapid application development, the Salesforce deployment is actually quite hard.

Consequently, developers can end up spending countless hours working on this. In fact, it usually entails evenings and weekends at the office since the deployment cannot be done during business hours without interrupting business activities. But that’s a story of the past because, with Flosum, it doesn’t have to be that way anymore.

There are several components that can combine to create this time crunch problem:

  • First of all, creating multiple “deployment units” and planning the deployment is a very lengthy process.
  • Secondly, just the deployment of the code itself takes a really long time. In addition, if there is any failure during deployment, developers have to restart the whole development process, causing a lot of agony and frustration.
  • Last, but not least, the deployment on the production org is quite different from deploying on the sandbox due to a variety of reasons.

Luckily, there are many solutions today that can be adopted and implemented by the development team in order to ensure that the Salesforce deployment is smooth, quick, and easy. With the help of Flosum and Salesforce, deployment times can finally be reduced by leveraging several different strategies during the application development lifecycle. This article identifies four key areas to focus on and details several sub-sections within each to alleviate and conquer these problems.

  1. Planning
    • Sandbox strategy
    • Adopt continuous integration
    • Work on the same baselines
  1. Testing strategies
    • Test on the real data set
    • Test often
    • Test, test and test
    • Executing tests in parallel
  1. Deployment strategies
    • Deploy the least amount of code
    • Expect different results on a production org
    • Create right-sized deployments
    • Exclude unnecessary components
    • Ensure system availability
    • Monitor system availability
  1. Optimizing test classes
    • Leverage quick deploy
    • Unbulkify tests
    • Code refactor
    • Choose the right test parameter
    • Code coverage

1. Planning

Proper planning is a key part of the process that must not be overlooked. As the old saying goes, people don’t plan to fail – they fail to plan!

Consider keeping clear communication between developers throughout the planning stages of a project. Remember, spending a little time on early planning can save a lot of time in the overall release cycle.

SANDBOX STRATEGY

Sandbox strategy should not be an afterthought. IT teams should have a set of dedicated developer orgs and sandboxes for testing. The refresh schedule for these developer orgs should be predetermined and aligned with the release schedule so that the orgs are available for testing as per the schedule.

This article is not recommending the purchase of additional full sandboxes or partial data sandboxes, however, according to our experience, we see a sub-optimal use of sandboxes and developer’s org in most environments. Without a proper sandbox strategy, testing is really hard and deployment is more error-prone.

ADOPT CONTINUOUS INTEGRATION

During the sprint cycle, developers typically work in isolation. Each of the developers is working on their own user story, application feature, or bug without regularly communicating with other developers. Towards the end of the release, developers come together to merge their code and deploy it to production org. At the time of merging, developers realize that the same component has been modified by multiple developers. This typically leads to last minute modifications in which developers merge their changes in the same copy and have to tediously rewrite the test classes to accommodate for all the scenarios.

Yet, if the developers would have “integrated the code” throughout the sprint cycle, they would have prevented the last minute collision and the code quality would have been much better. Not to mention the major reduction in time spent at the office.

WORK ON THE SAME BASELINES

Nothing reveals more issues than doing the deployment on “actual code”. However, it is imperative to test on the same code-line as the “final code-line”.

For example, if the November release is going to be deployed on top of the October release, which is already in production org, there is no point in testing the November release on a sandbox that has the August release installed. Similarly, it is prudent for developers to create the code changes on an org that has the same baseline as the October org. If the sandbox does not have the same release, it should be at least close to it. Developers should not be developing the application on an org that has not been refreshed from production recently.

2. Testing Strategies

The importance of testing is crucial in all stages of development.

TEST ON THE REAL DATA SET

Most customers don’t refresh their developer orgs often because their data gets wiped out. Flosum offers a data migration solution which takes a subset of the data from production and pushes it to developer orgs. During migration, the entire hierarchy is migrated so that the developers have a subset of real data to test their applications with.

One of the determining factors of code coverage is the data in the organization. Deploying the code on a full-data sandbox that is exactly the same as the production org will reflect code coverage that will be similar to that in the production org.

TEST OFTEN

Flosum has made testing easy. With the right refresh sandbox strategy, developers can deploy their code on a production replica and iron out most of the code issues upfront. Instead of finding issues close to deployment in production, a developer org can be quickly refreshed, tested with the code changes, and then have the latest release applied to production.

TEST, TEST AND TEST

Deployment of the release is very easy and can be achieved at the click of a button by using Flosum. The problem with other technologies, such as ChangeSets, is that the deployment units have to be created over and over again. Nothing finds real issues better than doing the actual deployment on the same code line as your “final baseline”.

EXECUTING TESTS IN PARALLEL

It sounds like a great idea to execute tests in parallel to speed up development. However, parallel test execution can result in data contention issues and can further delay deployment.

This typically happens when the test classes update the same records at the same time. Updating the same records typically occurs when tests don’t create their own data and turn off data isolation to access the organization’s data.

When you deploy to production, the tests are not run in parallel; hence, it will likely take longer to run all of them. If you are running in parallel in the sandbox, you can switch to not running the tests in parallel; this gives you a better idea of how long the actual deployment will take.

3. Deployment Strategies

There are several different strategies to select from when using Flosum with Salesforce.

DEPLOY THE LEAST AMOUNT OF CODE

Some organizations deploy each and every component during the sprint cycle. If the organization has 20K components, and only 400 components have changed in the spring cycle, it is prudent to deploy only the changed components. Deploying all the components increases the deployment by a huge factor and exponentially increases the chances of deployment failure. Not to mention that troubleshooting and debugging will take a lot more time.

EXPECT DIFFERENT RESULTS ON A PRODUCTION ORG

Deployment depends on a number of different factors including the size of data, metadata, and type of organization. Just because the deployment succeeded in the sandbox, it does not necessarily mean that the deployment will also work in production. For example, the test cases can be skipped in sandbox, but Salesforce runs the tests classes to ensure that your code meets the code coverage percentage requirement. This greatly increases the deployment time.

In addition, the test cases take longer to run on a production org compared to the sandboxes. This happens primarily because the data set is different in production compared to that in the sandboxes.

CREATE RIGHT-SIZED DEPLOYMENTS

ChangeSets don’t allow the packaging of code from different developer orgs. Furthermore, ChangeSets don’t allow all the metadata types in the same change units. With Flosum, you can package the change from multiple developer orgs and include all the various types of components in the same package.

From the overall effort of the team, it may make sense to have fewer — albeit slightly longer running — deployments rather than having a lot of deployments. For example, if 5 developers have to deploy apex code, it might make sense to merge them in the same ChangeSet so that the apex classes run just once instead of 5 times. This could affect the overall manageability as well as the ability to manage test cases.

EXCLUDE UNNECESSARY COMPONENTS

Salesforce metadata components have a lot of overlap. For example, custom fields, workflow definition, and layouts are part of custom objects. With ChangeSets, if you have to deploy a custom object, you have to include all the custom fields, validation rules, etc. With Flosum, you can just include the custom object and it will deploy all the underlying objects. Alternatively, you can just include validation rules or custom fields for deployment if you don’t want to deploy all the components.

Deploying the optimal size and kind of components helps to reduce deployment time since Salesforce takes less time to calculate dependencies and calculate the test classes that should be run.

ENSURE SYSTEM AVAILABILITY

Finally, Salesforce ensures that only one deployment is executed at a time. If the users submit multiple deployments at the same time, Salesforce automatically puts one of the deployments on a ‘hold’ status.

However, it is possible that you deploy a change that could take a long time. For instance, when you are making a change to the object and adding a validation rule, yet the object is widely used by users. Salesforce may hold the deployment until it can “lock” the object for changes, deploy the change, and then make the object available for use to users again.

Salesforce also offers a feature to notify the users of upcoming “Internal Releases” so that the users are kept aware of upgrades.

MONITOR THE STATUS OF YOUR DEPLOYMENTS

The size and complexity of the metadata components always affect the deployment time. To track the status of deployments that are in progress or have been completed in the last 30 days, from Setup, simply enter Deployment Status in the Quick Find box and then select Deployment Status.

The Deployment Status page shows you the real-time progress of your current deployment. The deployment status page shows the components deployed and the number of components with errors.

4. Optimizing Test Classes

Another important part of the entire process is the optimization of test classes. Even the best planned executions cannot anticipate the precise outcome; therefore, it is ideal to do extensive testing, whenever possible, in all stages of production and deployment. Testing is an absolute necessity and not doing so is only asking for trouble!

LEVERAGE QUICK DEPLOY

For most large, enterprise customers, the longest piece of a deployment is the time taken to run test classes. The time taken to run the test classes can be reduced by validating the deployments 72 hours in advance of the actual deployment. During the validation phase, all the test classes are executed. If there are no code changes as part of the deployment, then the deployment of the code is incredibly quick. Customers have reduced their deployment times from 8 hours to a mere 10 minutes simply by using this feature.

UNBULKIFY TESTS

Create the minimal amount of records required to run a test. It is good practice to create test data rather than use org’s data for running your test classes.

CODE REFACTOR

Remove methods and code that are no longer needed so you don’t have to add additional tests for code coverage.

CHOOSE THE RIGHT TEST PARAMETERS

During deployment, it is best to run the ideal set of test cases. Flosum allows you to run the minimal set of test classes by providing the following parameters:

No Test Run — With this parameter, no test classes are run. This test level applies only to deployments on development environments, such as sandbox, Developer Edition, or trial organizations. This test level is the default for development environments.

This parameter can be used when the team is building their release and wants to ensure that the code will be deployed without any errors.

Run Specified Tests — Only the tests that you specify in the runTests option are run. Code coverage requirements differ from the default coverage requirements when using this test level. Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code coverage. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.

Run Local Tests — All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.

Run All Tests In Org — All tests are run. With these parameters, Flosum executes all tests in your organization, including tests from the managed packages.

No Group Tests — Salesforce allows developers to specify a set of test cases that should be run during deployment. With no group tests, Flosum passes a “No test classes” option so that no test cases are run. This feature can also be used in production.

CODE COVERAGE

One of the major reasons for deployment failures is because the code coverage in the destination organization/target organization is not sufficient. If the code coverage is less than 75%, your deployment will ultimately fail.

It would be best to refresh a developer organization or a sandbox organization from production so that they have exactly the same data, metadata, Apex test classes, and managed packages, etc. It is highly recommended to make sure that the code coverage in this stage of the organization passes before a deployment is attempted on the production organization.

Flosum: Complementing Salesforce

Though this is just the basics, by now it should be evident how essential Flosum can be for success and significantly reduce Salesforce deployment time in your applications. Flosum is the only 100% native app for release management and continuous integration on the Salesforce.com platform. We are constantly striving for ways to improve the Salesforce experience.

Please stay tuned for updates and for additional information on this topic and other important issues regarding application building and maintenance.

Next Steps