Table of contents
Salesforce makes app development accessible for users of different tech proficiency levels, providing both advanced and point-and-click tools. Salesforce deployment usually takes a fraction of the overall implementation time but if done recklessly, it can entail unpleasant consequences.
Any change deployed within a Salesforce organization can challenge the integrity of the entire infrastructure. It’s no wonder Salesforce consultants name Salesforce deployment one of the trickiest and riskiest parts as it can affect:
- Business continuity: Even a small part missing, like an object or a validation rule, can break other parts of a Salesforce organization thus disrupting workflows, preventing users from doing their job, and compromising security.
- Compatibility: The existing features and integrations can be incompatible with the new changes and cause serious malfunctions, as well as interfering with data synchronization and automatic uploading.
- User adoption: New developments are there to make users’ lives better, but in many cases users experience difficulties with Salesforce adoption. For instance, they can require additional training when dealing with newly-developed functionality.
Salesforce deployment options
As a rule, Salesforce implementation starts in a developer sandbox. Then changes are pushed to the testing and staging environment, and once testing is done, the changes get deployed in the production environment.
There are three deployment options in Salesforce:
- Change sets
- Metadata API
- Ant Migration Tool
Let’s overview their characteristics and use cases.
Change sets
A change set is a group of features, components, and customizations that can be moved from one Salesforce environment to another—from one sandbox to another or from a sandbox to production—and deployed.
It works like that. Two organizations are configured to send and receive changes between each other. The user chooses which objects in the source organization to deploy, thus building a change set right in the Salesforce UI. When a change set is created, it can be deployed in the target organization, where it’s possible to accept the changes. As a result, the two organizations will have the same metadata described in the change set.
By its nature, change sets are a friendly option for non-tech users and smaller companies who need to implement quick changes without developer assistance. At the same time, if there are a few environments and many people working on Salesforce development, change sets make it hard to cooperate. They don’t support release management control and version control, which might entail errors and chaotic change tracking. What’s more, change sets don’t support a number of object types like sales processes, email addresses, divisions, and more. So in order to complete a deployment, it’s necessary to move such components manually, which is an extremely cumbersome and error-prone process.
Metadata API
Metadata API is a set of objects that help manage customization information, or metadata, like custom objects or page layouts, in order to:
- Export customizations from your Salesforce organization as XML metadata files
- Migrate configuration changes between organizations
- Modify existing customizations in your organization
- Move metadata from a local file system to a Salesforce organization
- Create your own tools for managing organizations and app metadata
Metadata API is a great instrument for managing customizations and building tools that can manage a metadata model, not the data itself. Salesforce also provides Ant Migration Tool to simplify access to the Metadata API functionality.
Ant Migration Tool
Ant Migration Tool is a Java/Ant-based command-line tool used for process automation. It can help perform repetitive deployments that use the same components and can be scripted.
The Ant Migration Tool is designed for developers; less tech-savvy users would have to face a steep learning curve before grasping it. It requires considerable time and efforts but at the same time it provides greater control over deployment and supports CI/CD.
The tool comes in particularly handy in the following use cases:
- Populating a test environment with a great amount of setup changes
- Repetitive deployment with the same parameters
- Iterative building, testing and staging prior to going to production
- Scheduling batch deployments
Note that the tool can be used only in a specific development environment, so it’s not suitable for distributed teams.
Turn your Salesforce deployment
into a seamless experience with Itransition.
Salesforce deployment dos and don’ts
To free deployment from its status of the riskiest Salesforce implementation stage, consider the following deployment best practices.
Do plan everything in advance
Say no to random releases and changes that can disrupt business continuity and confuse users. Instead, plan all the changes and their possible implications prior to going live.
The plan is particularly important when you work with multiple sandboxes at the same time. In such a situation, the plan lets everyone know what is going to happen and when, while keeping accountable the actors who initiate and implement changes.
It’s much easier to control your deployment and leave room for maneuver when you:
- Know in advance who’s going to be on the deployment team and what tools you’re going to use: change sets, command-line tools, manual configurations, etc.
- Plan a go-live for the least busy time with the majority of users off the system, like a weekend or a Friday night, to avoid work disruption.
- Take into account how much time you will need for testing and manual configurations necessary when working with change sets.
It’s also important to make sure in advance that you have the right data and calculate data loading time, as it can take a few days in case of legacy data migration. You also need to think how to communicate changes to end users to let them know when changes are coming, how to account for them when planning their day, and where to seek help in case of any difficulties.
One more essential point to consider when creating a deployment strategy is a roll-back plan. Sometimes things don’t work as expected and jeopardize continuity, so with the help of version control tools, it’s possible to get back where you’ve started, analyze, and fix errors.
To sum it up, it’s recommended to answer the following key questions when building your deployment strategy:
- Who will be deploying?
- What deployment tools are you going to use?
- When are deployments scheduled?
- Do you need to upload any data?
- How are you going to communicate the update?
- What’s the roll-back plan?
Don’t develop in production
Some people develop right in the production environment, which means they don’t need to deploy. It saves time and money but this approach can work only for those companies that run minor customizations that don’t require IT help and additional development and staging environments.
However, in most cases, development in production entails certain limitations (it’s not possible to write Apex code in production) and destructive consequences and unexpected cascading effects (a modified workflow rule can create an infinite processing loop, or an edited field type can change data in a way that’s impossible to undo). For this reason, it’s highly recommended to develop any change, even a minor one, in a sandbox or a scratch organization, test it, and then proceed to deployment.
Consider the following tips to develop safely:
- Limit customization access to minimize the number of people allowed to deploy changes
- Restrict modification types for change sets
- Appoint an environment management team to review changes prior to deployment
- Provide every developer with their own sandbox
Sandboxes are a great tool for auditing and keeping track of developers’ work. There are a few types of sandboxes in Salesforce:
Developer sandbox
An isolated organization that copies metadata into a different environment for coding and testing. Multiple developer sandboxes get linked to a source control system.
Partial copy sandbox
The tool copies metadata and a portion of production data for integration testing and quality assurance and minimizes code overwriting risks.
Full sandbox
The tool copies the entire production organization and data for coding and testing changes in relation to the entire live organization, thus minimizing possible errors.
Don’t skip testing
Testing is a key procedure for securing successful Salesforce deployment and positive user experience. It’s recommended to run tests both during the production and after the deployment.
You can make use of the Apex testing framework to write and execute unit tests to ensure high quality of Apex code and reach all the requirements to deploy it, checking that:
- Apex classes and triggers work as expected
- Code coverage is at least 75%
- Apps going to production are of high quality
At the Partial copy sandbox stage, run integration tests to ensure that updates don’t affect the functionality. When in a full sandbox, run user acceptance tests to make sure the changes meet user requirements, and performance tests to check response time and unintended effects on any of the organization’s aspects.
Salesforce also allows creating regression tests that can be triggered every time there are updates and ensure that these changes don’t break the existing functionality.
Additionally, consider implementing test automation to cut on manual testing and speed up releases. Automated scripts can run tests and immediately inform the developers whether their code is safe for deployment.
Do implement code version tracking
Code version control allows tracking and documenting all changes at every development cycle stage, which provides:
- A single source of truth for all team members, so that they can access a detailed change history
- Parallel development streams with the possibility to deploy different code versions across development stages
- Notifications about code conflicts
- Continuous integration and delivery
Salesforce sandbox development offers limited version tracking, so many Salesforce development teams go for a Git-based version control system which has become a number-one system for version control.
Do create a release management strategy
When developers work simultaneously in multiple environments (development, staging, or production), they need to plan and control their deployments. To establish good governance and run smooth deployments, developer teams need to have a proper release management strategy. Consider the following tips:
- Create a complete release management process where each team member understands their role.
- Categorize releases into bug fixes, minor changes with no need for user training, and major changes with significant impact on functionality, dependencies, and adoption.
- Develop and test in separate environments, and migrate all the changes from every project to the same environment for integration.
- Make developers aware of other releases and their schedules, and provide them with version control tools.
- Identify areas of code conflict early in the planning and provide developers with communication tools.
- Avoid deployment during busy hours or major events.
- Release on a regular schedule so that users could plan their week by knowing, for example, that major updates usually come on Friday nights and minor ones on Tuesday mornings.
Do follow CI/CD practices
СI/CD practices speed up releases and provide space for flexibility and improvisation. Continuous integration and merging lets developers minimize bugs and dependency issues, and if there are still any, they will usually be smaller and can be easily fixed. As a result, you can deliver new features once they are developed and tested, without waiting for releasing them in one batch.
In Salesforce Developer Experience (DX), it’s possible to pursue the continuous integration approach by making use of scratch organizations—source-driven and disposable deployments of Salesforce code and metadata. When developers regularly integrate code changes into a source code repository, it’s necessary to ensure that the new code doesn’t contain bugs. Scratch organizations allow developers to use integrated third-party CI tools, like CircleCI, Jenkins, Travis CI, etc. for running automated tests for new changes, checking code coverage, and pushing deployment to a target environment.
No comments:
Post a Comment