Developing new features and committing them to Stash
This guide is part three of ‘How to set up Continuous Integration for Salesforce.com‘, 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 Salesforce.com 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 Salesforce.com repository;
3 – Have Eclipse IDE with Force.com, 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 Salesforce.com‘, and have carried out the first and second steps of this walkthrough:
- Setting up Eclipse, and making your first commit to Stash;
- Commit your Salesforce.com codebase to Stash.
1. Set up your Developer instance
1.1 – As a developer, navigate to the Salesforce.com Stash repository, and clone the repository (use ‘Clone in SourceTree’) to your local machine.
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.
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’.
1.4 – In ‘Select root directory’ choose the folder that SourceTree saved the code to. Eclipse should detect a project in there already.
1.5 – You should now have successfully created a new Eclipse project from the imported folder. Your Eclipse will look something like this.
1.6 – Next, update your project to use your Salesforce DEV org. Right-click on the project and navigate to ‘Force.com -> Project Properties’ – then enter your DEV credentials, then hit OK.
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.
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 ‘Force.com ->Deploy to Server’. You will be prompted to re-enter your DEV credentials.
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.
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.
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.
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 ‘Force.com -> Refresh from Server’. This will pull all metadata components down from Salesforce DEV into your Eclipse.
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.
I can also see that my new fields have been added to the Account.object file:
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.
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.
If necessary, you can use the ‘Stage Hunk’ feature, to only commit specific changes in a file (thus not deploying any unwanted changes).
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.
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.
- 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 ‘Force.com -> 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 ‘Force.com -> ‘Add / Remove Metadata Components’ – and add any extra folders you need to get the whole feature.