In this tutorial we will talk about sandbox and how deployments are handled in Salesforce. Let’s start with Sandbox.
What is Sandbox?
Sandbox is a copy of a production environment.The main purpose of Sandbox is testing and development of new changes.
How Sandbox works?
Whenever you create or refresh a sandbox, copy of the production environment at that point in time is made. Most of the configuration remain same as production org. Few changes are done to the sandbox during the copy process like sandbox name is appended to the username of all the users of the sandbox. Some of the sandbox will also allow you to copy data from production into the sandbox as well. If no data is copied (like in developer edition sandbox) then the metadata will be migrated but no records will be copied to sandbox.
What’s the purpose of a Sandbox?
If you are working on a new Force.com application then I will recommend you to test and build the application in a sandbox. Once you are satisfied with the application, then you can migrate the metadata as well as data (if possible) to the production environment. By testing the application in a sandbox, you will be able to experiment without the risk of creating unused configuration or fields, interfering with existing application and other concerns.
Most companies use a multi-staged deployment method- the most common example is development and unit testing in one sandbox and then testing in a QA box ( full sandbox) and once everything looks good then move it to production.
Different types of Sandbox:
You are lucky if you have access to all the sandbox types. Here is one way to use them. If you don’t have all types available, you will be required to combine some tasks.
1) Full Sandbox – Fully testing changes against real data before deploying them to production. This may include user acceptance testing. All changes must pass through this sandbox. If multiple admins/developers are working on overlying areas, this is the place where changes get merged. Force.com IDE can be used to compare changes by different developers of the same apex code.
2) Partial Data Sandbox – This is a new sandbox type and I am not quite sure what was the intentions for this sandbox. It is just a cheaper alternative to a full sandbox. If you have a full sandbox, then partial data sandbox can be a good place for user training for new features, new employees, etc. Having real data can really help with training of new employees and also testing the new features. Partial Sandbox can also be used as a place to work on integration changes since it can hold large amount of real data.
3) Developer – A place to work through solutions to new requirements. The main idea is to keep experimentation out of the full sandbox. It there are multiple admins/developers, each one should get their own Developer sandbox so that they don’t disturb each other work until they are ready to deploy the changes in Full Sandbox.
4) Developer Pro – The main difference between Developer Pro and Developer is the amount of data that can be stored. It also contains some amount of product data from production. If you are looking for these two things then you can pick Developer Pro over developer Sandbox. Otherwise, both are very similar.
How to Login to a Sandbox?
You can login to a Sandbox using Sandbox URL. Similarly, to log into production you need production URL. This is same as login via the website or API.
Production URL: https://login.salesforce.com
Sandbox URL: https://test.salesforce.com
Migrating Metadata Between Different Environments:
There are different types of tools available which can help an adminstrator or developer to migrate metadata (configuration info) from one environment to another. The most common tools are here:
1) Change Sets
2) Force.com IDE ( developer toolkit)
Below are some important points to remember regarding sandboxes:

• Your sandbox will get out of sync with production org almost immediately. If you are making regular configuration changes to your production org this can be problematic.
• Test your deployment: Change sets and IDE are great tool for migrating metadata. Always use Preview deployment feature available in change sets. Always test your deployment in more than one sandbox specially if you are new to migration process.
• Promotion of profiles can be problematic, change sets are comparatively easier.
• The amount of time to create a full sandbox( with data) depends on the amount of data present in your production org.
• Whenever you create a full sandbox, the record IDs (contacts, accounts etc) will match the production environment (org ID will vary). The new records which you will create in either environments, new record IDs will not match.