Traditional deployment

There are two ways to deploy code to test in a sandbox or production environment:

• Change sets: A change set is used to move changes from a development sandbox to a production environment. Change sets do not contain data. Change sets are best for deploying the same components to multiple organizations. Change sets are good for small deployments, but not preferred for large deployments. The Force.com Migration Tool can be used for large deployments as deployment components can be easily managed.
• Force.com Migration Tool: Using the Force.com Migration Tool requires some setup. It is scriptable, so it is used for a multistage release process, where we can easily have scripted retrieval and deployment of components. Repetitive deployments using the parameters can be done. We can retrieve all metadata in the organization, make changes using the editor, and deploy the same subset of components.

Issues with traditional deployment

No versioning is provided in a sandbox environment, so it becomes difficult when multiple developers are working on a project and are not in sync. Keeping track of all changes in project can look like finding a needle in a haystack. Deployment with a change set is not recommended for large projects and creating a change set is not scriptable. So it becomes a repetitive task.

The Force.com Migration Tool is good for large projects, but we do not have versioning, so we cannot revert code to its previous version. Also, we are not able to track changes done by developers. 

We have different environments, such as development, test, stage, and production, in almost all technical stacks. In Salesforce, we use a sandbox for development and test environments. Sandboxes come in different types as per our requirement, and we can choose which sandbox to use. Let's look at the different types of sandboxes.