The general approach of team development is to provide a central share repository to all developers working on a common application project. Each developer then creates a project within the local Eclipse workspace based on the contents of the share repository. Developers then modify their local versions of the project and periodically commit their changes to the share, and also update their local projects from the share repository.
In support of this workflow, several new operations have been added to the Agentry Editor specifically for working with the share repository. Additionally the import operation has been augmented to support working with a share repository. Also, the concept of definition tagging has been added to the Agentry application project and Agentry Editor. The Agentry application project itself can be connected to a share, which then allows for the tracking of changes and revision history, and the share repository operations to update and commit from and to the repository.
The following sections provide overview information on the different functional areas and concepts related to the team configuration behaviors. Each of these is covered in more detail in subsequent sections, including instructions and requirements where applicable.
At the center of the team development architecture is the share repository, or simply “share.” This share is placed in a location common to and accessible by all developers on a team. Changes can be committed to this share from each developer’s local application project and from this share other developers can then update their local projects to retrieve committed changes.
The location of the share repository must be one that is accessible to all developers on a team, and should also be one that is backed up in some manner, usually via a version control or source control system. This location is typically a file server common to all members of the development team and to which each member has read-write privileges.
Stored within this repository is the common project share by the development team. Each developer has a local Agentry application project within the Eclipse workspace created from this share. Developers can work with the local project, defining behaviors just as with any project. When a stable point is reached in the development work, the developer commits the changes made back to the share. From here, other developers update their local projects from the share. The share itself maintains multiple revisions of the project, one for each commit. From this share a developer can update to the latest, or “tip” revision, as well as to earlier revisions when necessary.
The compression of the share repository is a behavior added in version 6.0 of the Agentry Mobile Platform. This is the standard behavior of both creating a new share repository, and when committing new revisions to an existing repository. For share repositories created with a version of Agentry prior to 6.0, the existing revisions in the repository will remain uncompressed and subsequent revisions to it will be compressed. Once such a revision is committed, the entire repository can only be used by versions of the Agentry Editor (6.0 and later) that support compressed share repository revisions.
Operations related to the share repository are begun by right-clicking the root project node in the Project explorer view. This must always be the open Agentry application project. In the context menu displayed there is a sub-menu Team. Within this menu there are several operations related to the share repository. If the open project is not currently connected to a repository, the only option available is to create a new share. This operation should only be performed when creating a new share for other developers to connect with, typically at the beginning of the project.
If no project is currently connected to a share, then a new project can be created from a share using the Import operation, which is separate from those in the Team menu. This is the same Import operation as others previously available. The selected import source is a share repository available to the Agentry Editor.
Once a project is connected, the Team sub-menu for the open project includes several options. Note that the first menu item is Apply Patch... This item is not a part of the team development functionality for an Agentry project and does not apply to these discussions.
When working with a share repository the possibility exists that changes committed to that share and changes made by individual developers conflict with one another. These conflicts become prevalent when a developer attempts to update the local project from the tip revision in the share.
The processing logic within the update operation includes checks for such conflicts. These items are then either resolved automatically by the update operation or are noted by the operation and the developer is informed. In the latter case, the developer is presented with options to resolve the issue. The specific options depend on the nature of the conflict.
Whether the conflict is handled automatically or via manual intervention by the developer, the goal of the operation is to update the local project to match the tip revision, or to modify it in such a ways that the next commit performed by the developer updates the share so that no further conflicts exist.
The import operations have been augmented in the 5.2 release of Agentry with the addition of a new import source that is the share repository. This source is selected in an import operation to create a new local Agentry project based on the tip revision of a selected share. When completed a local project is added to the Eclipse workspace that matches the tip revision in the share repository.
Within the import wizard the share repository is selected. Note that this operation always creates a new project. Imports cannot be performed from a share to an existing project. Rather, this operation requires the developer to perform an update operation for a project already connected to a share.
Any definition within the application project can have one or more tags added to it. Tags are created by developers within the project and include a name and description. Tags do not affect the mobile application at run time.
Certain operations, such as exporting, allow for definitions to be selected by the associated tags. As an example, if implementing a new behavior in an existing project, the definitions added or modified to support that behavior can all be given the same tag. During an export, the developer can easily select all these definitions to be exported by simply selecting that tag, which is displayed in the export wizard. In support of such behavior it is possible to enable auto-tagging. This feature allows the developer to select one or more tags to be automatically applied to definitions are modified or added.
The impetus for implementing tags in the 5.2 release of Agentry is in support of the team development functionality. However, they are not tied solely to this functional set and can be used in any manner found useful by the developer.