Team development and the Force.com IDE

So far, you have learned about tools an individual, disciplined developer might use for smaller development projects. When you are working on larger projects with longer application lifecycles, or with groups of developers in team environments, they will need the ability to manage change and track versions of their code.

While some applications can be developed by one person, many will be developed by teams. Sometimes this is because there is simply too much to do for one person, other times because different participants have different skills.

Whatever the reason for the team, team development brings challenges of change isolation and controlled synchronization. You won’t be pleased with your teammates when they make changes that break your code and stop you from finishing your tasks. A developer’s work should be isolated with a separate environment until it is complete enough to share, but, at that point, the separate changes should not break the other functions of the application.

Beyond team development, revision control is also very useful as the application lives through an extended lifecycle. After you deliver your application to users, they will no doubt find bugs and suggest minor enhancements that can be done quickly; however, you may also be working on larger extensions of the functionality that will take some time. You’ll want to work on these two sets of changes concurrently, keeping them isolated from one another so you can deliver the quick fixes before the new application is ready, and also merge those changes together so you don’t need to fix the bugs all over again in the extended application.

Tip

With the Force Platform, you can create and modify applications very rapidly, rolling changes out in near real time. But just because you can make application changes instantly available to end users does not mean that you should. Organizational issues, such as end-user training, frequently call for a more measured approach to iterative development.

In traditional software development practice, some of these needs are served by revision control systems. Revision control systems (also known as version control or source code control) are used to track sets of related changes, the completion status of those changes, and to coordinate bringing changes together into a complete version of the application for test or deployment.

The Force.com IDE is built on the Eclipse tool framework, and can take advantage of the large number of revision control systems that are either pre-integrated with Eclipse, or that are supported in Eclipse via plug-ins.

Note

For a list of revision control plug-ins for Eclipse, see http://eclipse-plugins.info/eclipse/plugins.jsp?category=SCM.

Version control integration works in Eclipse through three views within the IDE:

• A repository view for connecting to, managing, and browsing projects and contents in a revision control repository, which varies by revision control system

• Team-related context menu items and status icons on files in the Project Explorer

• A Text Compare editor that allows identification and resolution of concurrent changes

Resolving Change Conflicts

Team development naturally includes the possibility of more than one person working on the same metadata. In fact, since the Force.com IDE uses a local copy of metadata, you can end up with a conflict that stems from changes that have been made by one person through the Setup menu while you are working on the same objects in the IDE.

The Force.com IDE includes capabilities to address this type of issue. You start your exploration of team development by exploring the conflict detection and resolution capabilities of the IDE.

1.	Start the IDE if it isn’t already running, and return to the project you created earlier in this chapter.
2.	Click src objects.
3.	Double-click the Candidate__c object to bring the XML file into view.
4.	Right-click to bring up the context menu and select Force.com and Show in Salesforce Web. A browser window will open with the attribute page for the Job Application custom object.
5.	In the browser, scroll down and edit the Description of the Address field and save the changes.
6.	Return to the Force.com IDE and the XML for the Candidate__c object.
7.	Change the description to a different value than you did through the Setup menu.
8.	Use Ctrl-S to save. This saves the change to disk and also pushes the change into your organization. This Save will not be successful, due to a conflict. An error marker will appear in next to the component with the problem in the Package Explorer, and an error message will appear in the Problems panel, as shown below. Figure 146. Error with a Force.com IDE Save [View full size image]
9.	Right-click to bring up the context menu on Candidate__c.object, and select Force.com and Synchronize with Server. This action brings up a dialog box that prompts you as to whether you want to open the Synchronize view. Click Yes to continue.
10.	In the Synchronize view on the right, double-click the project to open up the hierarchy, and then double-click the Candidate__c object to open up a text comparison on the right, as shown below. Figure 147. The Synchronize view in the Force.com IDE [View full size image]
11.	In this case, the lines with differences between the two versions are indicated by the red line between the two versions.. The tool bar in the Text Compare editor has two buttons, which will allow you to copy the value from the right window to the left window or vice versa. Copy the changes either way that you wish.
12.	Right-click the project in the Synchronize window and select Apply project to Server. Click OK to save the two files. The Synchronize navigator should display a message indicating no changes in synchronizing.
13.	Return to the Force.com perspective, and then close the extra tab by clicking X on the tab.

This example showed you how the Force.com IDE detects conflicts between a local version of a metadata component and the version on the Force.com servers, protecting the integrity of this metadata, and how you can resolve this type of conflict. This procedure will take care of basic conflict issues that may arise in a team development scenario, but you may need to go to the next level of tracking and resolving in a larger team environment.