4

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?

2
  • FWIW, I do my tracking in the Changeset itself rather than keeping a separate set of notes - not perfect for every use case.
    – cropredy
    Mar 3, 2015 at 4:37
  • @crop1645 Thats not a bad idea, I've been thinking about that. Maybe I will give that a try, thanks.
    – user17526
    Mar 4, 2015 at 17:42

4 Answers 4

2

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.

3
  • Thank you for the answer Daniel, but I was referring to a method to create a active deployment manifest, not track changes in the system. I probably should have used different verbiage in the heading.
    – user17526
    Mar 4, 2015 at 17:46
  • So you want a way for all those entries in the setup audit trail to automatically become a change set? Mar 4, 2015 at 19:34
  • Automation..! Exactly what I was looking for. As you alluded to, the audit trail would probably have changes that we do not want in the change set. But your idea is on the right track of what I'm looking for. I gave it a thumbs up on Ideas :)
    – user17526
    Mar 4, 2015 at 22:08
2

There are a few different ways to do deployments between Salesforce orgs:

  1. 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.

  2. 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.

0
1

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.

0

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.

0

You must log in to answer this question.