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
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
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.
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.
Behind the scenes of an IDE SaveOnce you understand exactly what happens when you save a project from the Force.com IDE, you can understand some of the intricacies of the interaction between the development environment and the server metadata. When you create a project in the IDE, the Metadata API returns an XML file that is constructed from the metadata on your Force.com server instance. When you save a project back to the server, the Metadata API first checks to see if any of the metadata in the saved project has changed since it was initially retrieved. If there is a conflict, the Save is not successful and you must take corrective action, as demonstrated in this section. If the save is successful, the Metadata API returns an updated version of the XML file to the Force.com IDE, replacing the old version. This action may create results that can be confusing at first. For instance, if you add a new custom field to an object, the new XML file will include the field in alphabetical order—which means the field may be returned in a different spot than when it was initially saved. Remember that you can specify selected components for inclusion in a particular project. This flexibility has other implications on some of the actions you can accomplish with the IDE. In Force.com metadata, custom fields exist independent of the custom object that contains them, although the only way to access that metadata in the Force.com IDE is through the object. If you delete the XML definition of a field from a custom object in the Force.com IDE, the deletion will have no effect. The Metadata API will not delete the field definition in the metadata, so when the new XML file is built to return to the IDE, the custom object metadata will be refreshed to include the custom field. As a consequence, good practice calls for you to use the Setup menu to Force.com metadata as the ultimate authority. If you feel that something is not working in the way you expect through the API, be sure to check the results and consequences through the Setup menu. |
18.117.77.54