Whenever I make a code or config change in sandbox, I keep track of all the changes in a text document. I later use that text document as a reference to create a change set for deployment to production.
I feel this process in inefficient and error prone. Does anyone have a better process for tracking changes in Salesforce for deployment?
Have a look at the setup audit trail history. See Monitoring Setup Changes.
There are some restrictions here that may limits its usefulness. For example, it will only immediately show you the 20 most recent changes unless you download the setup history (for the last 180 days).
To your point that you would like an automated process to create the change set. I've created the idea Automated Change Set creation from Setup Audit Trail log.
If you could select a range of audited setup changes are automatically create the base change set you would be off to a good start. It would still need to be reviewed before upload.
There are a few different ways to do deployments between Salesforce orgs:
Changesets: Built into the Salesforce UI and quite nice, but some limitations including you need to have a relationship between the two orgs you are deploying.
Force.com Migration Tool: An ANT based tool, from Salesforce, that is command line based and allows you to migrate all changes from one Salesforce org to another by copying the files to your machine first.
There are also some third-party options. I work for Gearset and we are aiming to solve this problem. We provide a tool that allows you to view the differences between orgs, select only the changes that you want to deploy and then perform the deployment of those changes into the target org.
The Chrome Plugin Salesforce Change Set Helper can be very useful to do that. It shows you metadata components sorted by modification date and the user who changed them, so it is easy for you to find which components you have changed.
Here's an imperfect solution
Track all your changes in the Change Set itself.
In my orgs where changesets are used; I open up a change set and give it a label like
Sprint xx.0 - Oppo Discounts
Then, each time I touch a class/trigger/VF page/VF component or metadata item, I've trained myself to add that item to the changeset immediately. Rather than take notes, I use the changeset itself as the list keeper.
Obviously, I sometimes forget to add something in the heat of the moment and this doesn't get discovered until I deploy the changeset to my staging sandbox where there might be deployment validation errors. In that circumstance, I go back to the changeset, clone it and change the label to Sprint xx.1 - Oppo Discounts and add a comment into the description field as to what was added (i.e. forgotten) in the prior version of the changeset. Then, rinse and repeat.
You can also use Eclipse IDE Deployment tool to tell you what you've changed versus the target org and use that to double check your change set manifest.
Using a consistent naming convention for the changesets helps keep track of what is going on over time, especially if you deploy to multiple sandboxes/PROD
Of course, other orgs use GIT + Jenkins so the above won't always apply to everyone.
