Configuring Stash/Git for Salesforce With the Force IDE For Eclipse

In my Continuous Integration With Salesforce article, I provided an overview of the challenges and options as a member of a Salesforce project. This article will focus on configuring an Atlassian Stash/Git repository for use with Salesforce, along with configuration suggestions on using the Force IDE plug-in for Eclipse.

Quick Recap

Instead of relying on Change Sets to deploy our Salesforce application code and configuration, we decided to use the Force Migration Tool - which is an Apache Ant-based tool to communicate for the Salesforce Metadata API. Our goal was to maintain a code repository outside of the Salesforce cloud, so we planning to leverage our existing investment with Altassian Stash.

Eclipse and the Force IDE Plug-in

Salesforce provides a plug-in for the Eclipse IDE. The plug-in actually allows developers to write code inside of Eclipse and later push the code back into a Salesforce instance - often referred to as an "Org." My team found that using the tools built-in to Salesforce (Developer Console and Setup pages) were easier to use, so we merely use the Eclipse client to pull data from the developer's Salesforce Org so that we can then check the code into Stash. 

The steps to get the Force IDE plug-in working with Eclipse and connect Eclipse with a Salesforce Org are listed below:

Configure Eclipse and Force IDE Plug-in

1. Configure Java on your machine and validate everything is working properly using the "java -version" console command.

2. Download Eclipse ... please note Eclipse Juno (4.2) or Eclipse Kepler (4.3) — the 'Eclipse IDE for Java Developers' distribution is strongly recommended.

3. Launch Eclipse and validate functionality/select a workspace location.

4. Navigate to the Force.com IDE Installation and follow the instructions provided,

Connect to Salesforce via Eclipse

1. If your Security Token is not known for your Production Salesforce Org, reset your Security Token following the steps provided below:

   1. Login to login.salesforce.com.

   2. Select username | My Settings from the menu in the top left-hand corner of the Salesforce screen.

   3. Select My Settings | Personal from the left-hand menu.

   4. Select Reset My Security Token option.

   5. Single-click the Reset Security Token button after reading the information on the screen.

   6. Retrieve new Security Token from the email account attached to your Salesforce account.

2. Within Eclipse, select File | New Force.com Project:

3. Populate the following items in the New Force.com Project dialog box:

   1. Project Name (I called mine sfdc)

   2. User Name (which is your Salesforce user name for the Production Org)

   3. Password (which is your Salesforce password for the Production Org)

   4. Security Token (which may have been reset in the steps above)

   5. Environment should be set to Production/Developer Edition

4. Single-click the Next Button (which should validate you can connect to the Production Org).

5. On the Project Contents screen, add all available items to the Project.

6. Single-click the Finish button.

7. If asked if you wish to retrieve all contents now, go ahead and select the Yes option.

8. After the dialog box closes, right-click the project (which I called sfdc) and select Force.Com | Refresh from Server. This will pull down all the metadata from your Production Org an additional time.

9. Exit Eclipse.

At this point, there should be a project in your Eclipse workspace folder for your Salesforce Production source code (which I called sfdc). You may have noticed that we included elements which can not be migrated using the Force Migration Tool. This is because, my team's goal was to have a copy of all Salesforce data outside the Salesforce cloud. Our hope, is that some day Salesforce supports deployment of all metadata elements.

Configuring Stash

Atlassian Stash is a Git-based repository, which provides strong Pull Request (code review) functionality. Additionally, as I will demonstrate in a future article, Stash works well with Atlassian's Bamboo product - to automate Continuous Integration.

Continuing from where we left off with Eclipse, the next step is to create a new repository in Stash. I decided to use the name CRM for my Stash project and I created a sfdc repository for the Salesforce code. In our case, we had source code for another CRM system, which is why the project name of CRM was chosen. As you will notice in the steps below, the work we did with getting data into Eclipse will soon be removed, since these steps were designed to initially load Stash with Production design and configuration data.

Once the sfdc project has been created in the CRM project within Stash, the following steps were executed:

1. Copy the files from the Eclipse sfdc project into a new folder which will be used by Git (in my case it was user/myusername/sfdc).

2. Open up a console/terminal session.

3. Navigate to the user/myusername/sfdc folder.

4. Execute the following commands:

   1. git init

   2. vi .gitignore (to include the following items)

      1. .DS_Store

      2. .project

      3. .settings

   3. git status

   4. git add .

   5. git commit with a message of "Initial Check-In"

   6. git remote add origin ssh://git@stash.yourhostgoeshere.com/crm/sfdc.git

   7. git push origin master

   8. git checkout -b develop

   9. git push origin develop

Within the CRM project, the develop branch was set to the default branch

At this point, a copy of the Salesforce Production Org has been uploaded into two branches (develop and master) within Stash. From this point, developers will create a new branch from develop.

When developers complete their changes, a Pull Request will be created within Stash, which will merge the code into the develop branch. When a Production release occurs, the develop branch code will be merged into the master branch.

Clean Up Tasks and Developer Configuration

Since the Eclipse project above was created for the initial load of data, it needs to be removed. It is recommended to launch Eclipse, right-click on the project created above (mine was called sfdc) and select the Delete option.

Developers should always plan to work against a Sandbox Org. These sandboxes will be refreshed often using Bamboo, which I will document in my next article. Developers will follow a similar set of steps noted above, with the following exceptions:

• Developers will have created a branch on their local workstation.

• Instead of using File | New Force.com Project they will use File | Import with the following steps:

  • Locate the Projects from Git option, single-click Next.

  • Select the "Existing local repository" option, single-click Next.

  • Browse/Select the user/userName/sfdc folder (which sets the value to user/userName/sfdc/.git), single-click Finish

  • At the Import Projects from Git dialog box, select "Import as general project"option, single-click Next

  • Name the project using a predefined pattern (we often use the sandbox name)

  • Single-click the Finish button

• Right-click on the project imported (above), select Force.com | Add Force.com Nature.

• Right-click on the project imported (above), select the Properties option.

• Single-click the Force.com section and populate as follows:

  • Username = your Salesforce username for the Org you are connecting to

  • Password = your Salesforce password

  • Security Token = your Security Token

  • Environment = Sandbox

  • Single-click the Apply button.

• At the Refresh Project Contents dialog box, select the No option.

• Single-click the OK button to close the Properties dialog box.

• Right-click on the project created (above) and make sure Force.com | Work Offline option exists. If the Work Online option appears, single-click the option to toggle the value.

• Right-click the Force.com | Refresh from Server option to pull down the latest contents from the sandbox

It is important for the Salesforce Org to be on the same version of Stash code where the branch was created. In our case, we refresh all of our environments following a Production release. From a Salesforce perspective, all environments are on the same code base. From a Stash perspective, both develop and master have the same contents.

What's Next?

My next article will focus on configuring Bamboo to automatically deploy Salesforce updates stored in Stash into Salesforce Orgs.  Once completed, the process to deploy code from one Salesforce Org to another can be as simple as a push of a button.

Have a really great day!