+ Start a Discussion
Sébastien Van Cutsem 8Sébastien Van Cutsem 8 

SalesForce release management - best practice ?

Today we do not have a release magament process for SFDC releases. I read a lot of articles on the subject but I don't find the best way. There is a lot of tools to do that : Flosum, AutoRABIT, Copado, CloudMax, sfOpticon, Force.com Migration Tool... 
We think to use the Migration tool with SVN and the dataloader to automate all the process and make Continuous Integration with Jenkins. The idea is that we would like to have :
- a sandbox for each developper 
- a sandbox (QA-Integration) to validate the code (SF best practices convention, naming convention,...) 
- a sandbox (UAT) for users tests
- a sandbox (staging) to validate migration to production 
- poduction
What we want to avoid is to take too much time for the prod deployment, found errors in the last step (UAT-staging), found dirty code in another environement than development and we would like to easily roll-back, compare environment, rebase an environment... We think that with the migration tool and svn we can achieve it without encountering too many difficulties but I want to be sure before I implement all the process. So has someone already implemented a similar process in his organization ? Has someone scripts exemple ? If not what do you suggest as a proper process for managing SFDC releases according to our needs ?

Thanks in advance for your answers en your help.
Hi Sébastien,
Release management depends upon many project related variables as following:
1) Size of team
2) Skills of team with tools
3) Number of sandboxes
4) Release cycles

I have used below process in past:
1) Individual developer merge their code to SVN
2) Get latest code and use comparison tools e.g. beyond compare to merge and only deploy changes which are applicable.
3) On commit Jenkins job kick off which try to deploy using checkonly with test command of ANT
4) Any failure gets sent to DEV and DEV is required to act upon it to make build green
5) Use of beyond compare make sure DEVs are not overwriting each other’s code.
6) As there is no complete continuous integration in salesforce, manual changes are tracked in separate google docs spreadsheets
7) Have a look inti unsupported metadata types in salesforce https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm
8) On day of the deployment with just one click, build gets deployed to production and all manual pre and post deployment steps are performed as per sheet.
9) You can also kick of scripted data loader from your Jenkins job to migrate custom settings data as well.

​Fahad Akhtar
Aleemuddin KhanAleemuddin Khan
Hi Sebastien,

This is Aleem from AutoRABIT. I'd recommend you to go through the following link for SVN setup and connectivity:

AutoRABIT has strong integration support for Version Control Systems (SVN, GIT, TFS & Perforce) and can fast-track your Continuous Integration by empowering you with following capabilities:

a) Fetch uncommitted changes from Salesforce and commit directly to SVN using AutoRABIT.
b) CI jobs creation from SVN
c) Easy commit, and Easy Deploy to boost productivity
d) Compare, sync Salesforce org and SVN
e) Fetch changes from your repository based on date, revision or tagged check-in’s and deploy them to your Salesforce environment.

Incase you need further assistance, please feel free to write to us at support@autorabit.com, our Support Engineers will get in touch with you.

Vinay YelavarthiVinay Yelavarthi
Hi Aleemuddin,

I was new to Salesforce and I have to schedule a job in Jenkins by Git.

Scenario: When a developer commits the code to GitHub Jenkins should immediately pick the code and move it to a sandbox and this should be running for every 15 mins. Can you please help me in providing any useful links or any valuable information to write the code and schedule it in Jenkins.

We are using bitbucket for the repository.

Sajeed SayedSajeed Sayed
Hi Vinay,
You will have to configure a webhook on the github for the repository. The endpoint of the webhook should be your jenkins.  

Hope this helps

Tam TTam T
Fahad made very a very important point  - approaching source control and release management for Salesforce must start with evaluating your team size and skill set. The first decision you want to make is if you should use an org-to-org based deployment approach versus Git being the source of truth. The former is simpler, requires less technical skill but is not scalable. The latter introduces overhead because it adds another competing source of truth [dev org] -> [git] -> [prod org]. It is, however, very scalable and flexible but it will need your team to skill up within the dev-ops space, as well as figure out a process that allows your admins to work with Xml & Git, which could be a very steep learning curve.

If you have decided to go with the latter option (adopt version control), follow the best practices in the blog post below and you should be way ahead of the game in setting up the right process for your team.

Salesforce release mangement best practices (https://medium.com/@clickdeploy_team/salesforce-release-management-best-practices-4255ad7c7f63)