After committing many deployments I have realized that having a stable/structured naming convention would help me better asses the historical commits.

Also when there is more then 1 developer on the same org, it would be very convenient if everybody would have a standard naming convention that which describe the functionality of the deployment just from the title.

I would be interested to know, how is everybody else tackling this situation. For example the way I am doing it at the moment is:

[NameofSandbox] followed by [ApexClass] Or [ApexTrigger] Or [SObject_Fields] followed by the name of the objects that are influenced by the update, followed by [Number] which indicates the related number of times a particular change set was tried to be deployed.

You get my point. Any information with regards to this would be much appreciated. Thank you in advance!

2 Answers 2


The naming convention depends on your organization's development style. The most important part about using naming conventions is to have a naming convention. It doesn't really matter what it is, so long as there's an easy way for people to go back and look them up.

For example, at one place I worked, we had a deployment exactly every two months, coordinated across multiple integrated platforms. These deployments were managed by way of ant scripts, and each deployment was tagged in our code repository by way of branches (they should have been tags, but, it was their established convention by the time I showed up). This bundling was also necessary because deployments could easily take many hours (a single run of unit tests was 50+ minutes at one point).

Where I'm working at now, our deployments take about three to five minutes, so we deploy on an as-needed schedule outside business hours, and usually deploy each story independently. In that case, our deployments are simply labelled the same as the feature or bug they're named for in our agile environment (e.g. US-12345 is a user story, and so would have a matching change set).

The point is to be consistent. If you're deploying once every month or so, you might consider using the term "version", even if it's really just a release date (so version 2016.03.10 is the version deployed on March 10th of 2016). If you're releasing a feature at a time, you can use the story number(s) from your other system. Alternatively, if you're a feature-based development team, consider releasing each feature as a version (e.g. "Deduplication Manager v2015.02.20" is a specific feature released on a specific date).

One recommendation that I'd have is to delete failed deployments. This only serves to clutter up the history and make it harder to find deployments you're interested in. You might keep track of them elsewhere, but usually failed deployments have no modification effect on production, and so are just failed attempts.

  • That's a good point to delete the failed deployments and always use the standard naming convention + a version timestamp . Similar to @Vigneshwaran G's answer your approach seems to be applicable only when the developers size is relatively medium,high but in my case is only 1 at the moment. So I need to decide carefully how should I start naming them as I want to set a clear overview of the past deployments to future developers in my org. Commented May 11, 2016 at 16:12
  • @MarcZaharescu Before I left my last position, our team was indeed around 10 or so developers. But my current team is only two full-time (myself and one other) and two contractors. Looking back on my history, if I had to do everything over again back from my solo days, I'd still recommend using agile software (e.g. Rally, Jira, something), and naming deployments after the stories they represent. Naming deployments after the class/trigger/etc isn't productive, as it doesn't tell you why it changed.
    – sfdcfox
    Commented May 11, 2016 at 16:18
  • thanks again, I will try to use your advice on this matter and will start using agile software in this case Commented May 11, 2016 at 16:24
  • @sfdcfox Did you try Agile Accelerator? We also had some discussions on what to implement, and how the development process should be, but as it's only 2 of us here, and we do support also, decided to do not use Agile Accelerator or any other platform, and just trying to do a high level plan for larger projects.
    – o-lexi
    Commented May 11, 2016 at 17:10
  • @Oleksiy No, my experience so far is limited to Rally and Jira, and we're kind of tied in to Jira where I'm working at right now, because it's spread across the entire organization, even those that don't use salesforce. But that link looks interesting, so I might try it out for my own personal projects first and see if I like it.
    – sfdcfox
    Commented May 11, 2016 at 17:21

The naming convention depends more on the kind of project/work (administration/development) you do to do the migrations.


For administration works, we usually get change requests and a single change request may require us to work on more than one type of component(workflow, process, apex class, trigger, visualforce, custom labels, etc.,). So in that case we name the Changeset with the change request name(format of CRxxxxxxxx) followed by Date followed by Vx where x is the version.


For developments, there are two process we followed. One for migrating from Developer Sandbox to Full copy Sandbox for UAT/SIT and another from Full copy Sandbox to Production.

Developer to Full copy Sandbox

This usually follows a sprint model and we used changeset name with sprint number followed by Date followed by Vx where x is the version.

Full copy Sandbox to Production

This also follows sprint model but the frequency changes a lot as some of the urgent fixes need to be moved to production. So for fixes the changeset name will be bugfix bgxxxxxxxx followed by Date followed by VX where x is the version. For normal sprint migrations, sprint number followed by Date followed by Vx.

This is purely what we followed and following in different kind of projects. Others may chime in and provide different views and thoughts I hope.

  • thank you very much for your answer, it was very helpful in explaining what sort of process you follow. Commented May 11, 2016 at 15:53
  • Although your approach probably works the best for you because there are multiple developers on your organisation,I'm not sure if it makes sense to apply it as I am currently the only 1. Commented May 11, 2016 at 16:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .