Developing new features and committing them to Stash

This guide is part three of ‘How to set up Continuous Integration for‘, and will take you through setting up a DEV environment, deploying your code base into it, building a feature, and then committing the new feature into your Stash repository.

In the previous article we committed the LIVE codebase to Stash. In this post, we are going to go through all the steps that a developer will need to go through in this methodology. A new developer to your project will need:

1 – Get their own developer sandbox cloned from LIVE;

2 – Have a Stash user with read / write access to the repository;

3 – Have Eclipse IDE with, and SourceTree, installed on their local machine.

We will add a new feature directly to the ‘master’ branch in Stash. This is not branching best practice, but is just for the purposes of this tutorial.



This tutorial assumes that you  have the pre-requisites available from the parent article – ‘Setting up Continuous Integration for‘, and have carried out the first and second steps of this walkthrough:

  1. Setting up Eclipse, and making your first commit to Stash;
  2. Commit your codebase to Stash.


1. Set up your Developer instance

1.1 – As a developer, navigate to the Stash repository, and clone the repository (use ‘Clone in SourceTree’) to your local machine.

Screen Shot 2015-04-07 at 11.20.41

1.2 – SourceTree will open automatically and default in your Stash credentials. Select a new folder to save the repository code into and click ‘Clone’. When complete, you will have the latest version of code on your machine.

Screen Shot 2015-04-07 at 11.24.59

1.3 – Now we need to import this project into Eclipse so that we can edit this code. Open Eclipse IDE, and go ‘File -> Import’, and select ‘Exiting Projects into Workspace’.

Screen Shot 2015-04-07 at 09.48.00


1.4 – In ‘Select root directory’ choose the folder that SourceTree saved the code to. Eclipse should detect a project in there already.

Screen Shot 2015-04-07 at 09.48.36


1.5 – You should now have successfully created a new Eclipse project from the imported folder. Your Eclipse will look something like this.

Screen Shot 2015-04-07 at 09.49.30


1.6 – Next, update your project to use your Salesforce DEV org. Right-click on the project and navigate to ‘ -> Project Properties’ – then enter your DEV credentials, then hit OK.

Screen Shot 2015-04-07 at 09.52.01

1.7 – Once you have updated your credentials you will see the following pop-up – make sure you hit ‘No’ – otherwise your DEV codebase will be pulled down and will overwrite the code you pulled down from Stash.

Screen Shot 2015-04-07 at 09.52.31

If you hit yes, then you will have to pull the latest code down from Stash again, which can produce merge errors and be a pain to work around!

1.8 – The final set up step is to deploy the code from your local machine onto your Salesforce DEV org. This will update your DEV environment with the latest stable code base. To do this, right click on your project and navigate to ‘ ->Deploy to Server’. You will be prompted to re-enter your DEV credentials.

Screen Shot 2015-04-07 at 09.57.23

1.9 – Eclipse will prepare the deployment package for you by identifying the differences between your files and your DEV org’s. It can also output a log file if you want (I skipped this step). Select the items you want to deploy and hit ‘Next’ when ready.

Screen Shot 2015-04-07 at 10.12.06

1.10 – It is common to find deployment errors at this point.

To mitigate this check that your DEV environment has been recently refreshed from PROD (so that the same settings are activate, fields / objects / layouts etc match). Salesforce often release new features in Sandboxes before LIVE, so it is possible that something you are trying to deploy clashes with a new feature. You can also try deploying classes / objects one-by-one.

Screen Shot 2015-04-07 at 12.00.56


If you have errors that aren’t solved by the mitigations above, then see the ‘Additional Points’ section at the bottom of this page.

1.11 – Assuming that you have been able to solve any major deployment errors, you are now able to start developing your changes.

2. Develop a new feature in Salesforce

You can now start developing / making changes in your Salesforce DEV environment. I will be creating an example feature that touches on multiple areas of Salesforce config and committing it to demonstrate the process.

I am making a feature to track financial invoices against a customer. This contains:

  • 1x custom object called ‘Invoices’ with a master-detail relationship with Accounts.
  • 2x custom fields – a ‘Status’ picklist and a ‘Total Amount’ field.
  • 4x roll-up summary fields on Account –
  • 1x custom tab called ‘Invoices’ which will be added to the ‘Sales’ application.

All profiles have complete access to these objects, for the sake of ease. This feature can be seen below in my DEV environment.

Screen Shot 2015-04-07 at 12.43.18


The new feature has been built and is working, now it is time for it be committed into Stash. From here, it can be deployed to further environments for business acceptance etc.


3. Pull your changes onto your local machine.

3.1 – To pull your changes into Eclipse (and thus SourceTree), right click on your project and select ‘ -> Refresh from Server’. This will pull all metadata components down from Salesforce DEV into your Eclipse.

Screen Shot 2015-04-07 at 12.48.15

3.2 – Once the refresh is complete, you should find that your Eclipse files have been updated and now contain the changes that you made. For example, I found my new ‘Invoices__c’ object in the ‘objects’ folder.

Screen Shot 2015-04-07 at 12.50.20


I can also see that my new fields have been added to the Account.object file:

Screen Shot 2015-04-07 at 12.51.55


The same principle works for APEX, VisualForce, workflows, objects, profiles, page layouts and more!

3.3 – Do a quick sanity check in Eclipse to see that everything you expected is in there. This is harder for config consultants than it is for developers, as you can easily miss some aspect of metadata if you make a config change (e.g. page layouts, profile / permission changes etc).

4. Commit your feature

4.1 – Return to SourceTree – you should see a lot of uncommitted changes in the ‘working tree’ area.

Screen Shot 2015-04-07 at 13.00.52

4.2 – Rather than deploy all changes, you need to pick the the changes you require for your feature to work, and deploy those only. If you attempt to deploy all changes it is likely that you will deploy something you don’t mean and could thus cause issues further in the process.

Screen Shot 2015-04-07 at 13.07.11

If necessary, you can use the ‘Stage Hunk’ feature, to only commit specific changes in a file (thus not deploying any unwanted changes).

Screen Shot 2015-04-07 at 13.03.54

4.3 -When you are ready – hit the ‘Commit’ button in the top-left corner of SourceTree. Enter your description, tick ‘Push commits immediately to: origin’, and then hit commit.

Screen Shot 2015-04-07 at 13.12.02


All done! You have now set up your DEV connection, built a new feature and committed it to Stash. The next step is to add Deployment Automation to this process, using Bamboo.

<– Previous: Commit your code base to Stash

Next: How to set up Salesforce deployment pre-requisites on a Linux Server (for Bamboo) –>

Additional Points

  • An alternative, faster method is available – If you followed from the previous article, then you could simply configure your existing Eclipse project to use your developer Sandbox, instead of a new project from scratch. You can do this by going into ‘ -> Project Properties’, and swapping your LIVE details to your DEV details, and deploying your code into your DEV environment.
  • If you have trouble importing your project to Eclipse – if the import feature does not work (in point 1.4), try creating a blank new Project, and setting it’s root as the SourceTree repository folder.
  • If you can’t find all your new feature changes in Eclipse – you may not be pulling everything from Salesforce that you need – for example, if you add a Workflow, you need to make sure that you are polling for the ‘workflow’ folder from your DEV org. To fix this, right-click on your project and navigate to ‘ -> ‘Add / Remove Metadata Components’ – and add any extra folders you need to get the whole feature.

You may also like...

5 Responses

  1. Chandra says:

    Thanks for the blog. However I do have one question in terms of team deployment. Assume two developers are working on different changes in two different GIT Branches/Sandboxes However both developers made changes to same custom object and profile. How do manage them? Do you merge them using Git? Did you have this scenario and does Git Merging works fine for profiles and other metadata?

    • dsmorris85 says:

      Hi Chandra,

      Thanks for stopping by!

      In the instance you describe I have always found to date that gif can be used to merge changes manually. As a default I prefer to pull as many metadata components as possible into git including profiles, objects etc. As these are XML it’s normally not too hard to figure out why something has changed and thus can be easily rectified using git merges.

      If you wanted to get even more advanced then I’d recommend using a branching strategy similar to GitFlow (see

      This model creates all feature branches from a develop branch. The develop branch can then be used by developers to pull changes made by other devs onto their feature branch periodically.

      What do you think? Hopefully that helps?

  2. Albert says:

    Thank you so much for all the great information in your blog. The logical way you’ve structured you’ve structured your tutorial, the examples you used, and the graphics you provided made this easy to understand. I found this tutorial extremely helpful and valuable. I also enjoyed reading the information you put into your personal profile.

Leave a Reply

Your email address will not be published. Required fields are marked *


Seo wordpress plugin by