Team Development

Team development function is a group of enhanced functions to support developing services by multiple users.
As this function is organized based on IDE (Integrated Development Environment) and the upgrade management system, it is intended for developers who have experienced these products.

Enabling Team Development

Team development function is disabled by default.
To enable, you need to login again to the client. From the Control Panel, select [DataSpiderServer Settings] then the [Team Development] tab, and check [Enable team development].

Main Features of Team Development

By enabling Team development function, below features are available.

Save Project to Local
Commit to the Project Server
Detect Competitors of the Project / Script
Reflect the Server Project Condition to the Local Project
Manage the Local Script History
Set the Comments on the Project and Tags

Save Project to Local

Saves the project to local.

Save the project on the OS on which DataSpider Studio is running in DataSpider user units.

Save the project in DataSpider user units for each user of OS on which DataSpider Studio for Web is running.

By saving the project to local, you can avoid overwriting the changes other team members made when you share and edit the same project as a team.
Also, as a secondary effect, it can prevent project bloat, as every time you save the project, only the project stored in local is updated.

The projects/scripts, which are not committed to the server but saved to local, are distinguished by the ">" sign, meaning the projects are saved in local only.

To open a project, first open the local project.

When Team Development Function is disabled, open the project in the server. In a case where a local project exists with Team Development Function enabled, the local project will be destroyed by disabling Team Development Function and open the same project.

Commit to the Project Server

Commits the local project to the server.
By committing to the server, the contents of the local project and the server project become consistent and the changed contents can be visible to other team members.

Commit is completed by the following steps.

If a conflict is detected in the process, you need to solve the conflict otherwise you will not be able to commit to the server.
For information about conflict, refer to "Detect Competitor of the Project/Script".

Recognize a project conflict
→ If a conflict is detected, a project conflict occurs
→ If not, proceed to 2

Execute below i. and ii. for all scripts
1. Check whether a script conflict exists or not
2. Update scripts without conflict (reflect the server script condition to the local script)
→ If a conflict is detected, a script conflict occurs
→ If not, proceed to 3

Commit to the server

As projects are always updated by folder/script unit before making a commit, you will not have to overwrite the script which is not edited.

When you commit the project to the server, "Commit project" dialog will appear.

Description of items

Item name	Description	Remarks
Comment	Enter a comment.
Tag	Enter a tag.
List of scripts to be committed / Script	Names of the scripts to commit are displayed.
List of scripts to be committed / Operation	The type of operations (Add, Update and Delete) of the script to commit is displayed.

When commit is completed, the local preservation sign ">" will be vanished.

Detect Competitors of the Project / Script

Conflict is a state where the operations such as changing the project structure and the script contents are conducted simultaneously by multiple team members.
If a conflict is detected in the process, you need to solve the conflict otherwise you will not be able to commit to the server.
This is to avoid overwriting the project/script contents of the server with the local contents accidentally.

There are two patterns of the state of the conflict:

The Project Conflict
The Script Conflict

The Project Conflict

Describes the state where the changes in the project are competed among several team members.
Project conflict may occur in the case that other team members change the project structure in server when committing the project.
Corresponding changes of project structure are as follows.

Change a script of which name is different in the same folder into the same name
Move a script of which name is the same in a different folder into the same folder
Delete a script of which content has been changed
Edit a local custom logic

To prevent project conflict from occurring, defining the following rules is recommended.

Determine a project structure in an early stage of development
Limit team members who are allowed to edit project structure or local custom logics
When editing a local custom logic, other team members do not modify the project until the edition will be committed

When project conflict occurs, "Project conflict" screen appears and you can confirm the condition of local project and server project.

Basic information

Item name	Description	Remarks
Local project	Displays the condition of the project saved to local.
Server project	Displays the condition of the project committed to the server.

Custom logic

Name	Description	Remarks
Local project	Shows the state of local custom logic saved in local.
Server project	Shows the state of local custom logic committed to server.

Commit information

Item name	Description	Remarks
Last modified on server	Shows the date of the latest version of the server project was saved.
Last modified user on server	Shows the user committed the latest version of the server project.
Comment	Shows the comment to the latest version of the server project.
Last modified on local	Shows the date of the latest version of the local project saved.

The conflict sign, "

" is displayed for the conflicted projects on Project Explorer.

[Custom logic] tab is displayed only when the contents of local custom logics differ between local and server.

To solve conflicts in the project, below solutions can be applied.

Overwrite the local project to the server project
Move the local project by copying it then overwrite the server project
Change the local project into the same structure as the server project

When you overwrite a server project, compare the contents between the project you moved and the project you overwrote. Extract the parts you modified if necessary and reflect them to the local project, and commit again.

Although local custom logics are included in project conflicts, you can resolve that separately as follows.

The project conflicts other than the local custom logic conflicts will not be resolved even if you resolve the local custom logic conflicts. Resolve them from the project conflict menu separately.

The Script Conflict

Describes a state where the changes in the script contents are competed against other team members.

When the script conflict occurs, the "Conflicts of scripts" dialog appears to check the name of the script.
The condition of the conflict can be seen from [Script properties].

The conflict sign, "

" is displayed for the conflicting script the Project Explorer.

To solve a script conflict, below solutions can be applied.

Overwrite a local script to the server script
Move the local script by copying it then overwrite the local script in the server script

When you overwrite a server script, compare the contents between the script you moved and the script you overwrote. Extract the parts you modified if necessary and reflect them to the local script, and commit again.

To avoid generating script conflicts, you can use the Lock Script function so that other users cannot edit the script.

Reflect the Server Project Condition to the Local Project

If the structure of the local project is different from the server project and the contents do not conflict against each other, you can reflect the server project structure to the local project by Update.

Update is completed by the following steps.

Recognize a project conflict
→ If a conflict is detected, a project conflict occurs
→ If not, proceed to 2

Execute below i. and ii. for all scripts
1. Check whether a script conflict exists or not
2. Update scripts without conflict (reflect the server script condition to the local script)
3. Update folder (reflect the state of server folder to local.)

The project is automatically updated when committing to the server. You can also update manually.
For example, by updating the project before editing the existing script, keep the script at the latest version of the server to lower the possibility of script conflict.
(It is more effective if you use the script lock function as well)

Manage the Local Script History

Manages local script history. It is also possible to restore the condition you specified.
The number of local histories in the system retained is up to 50, or for 7 days. More than 50 of local histories or histories passed 7 days are automatically deleted.

Local histories are managed by the internal ID of the script. Therefore, local histories are retained even when you moved scripts or changed the name.
In a case you delete the script and create a new script with the same name, the local history may not be inherited.

Set the Comments on the Project and Tags

When you commit a project to the server, you can set comments and tags to the project.
By setting a comment as a commit log and use a tag as the end of development, you can manage upgrading processes more easily.

At the time of committing the project, you can set a comment as well as a tag. Tags can also be configured from [Tag] in My Project.

Specification Limits

If the Team Development Function is enabled, you need to save the project in local when executing the script in Designer.

Notes

The applications those can be referred by local projects are Studio or Studio for Web. If projects are available for reference with other applications/tools, they should be server projects.
When changing or moving a script name which is the same between local and server, change in local is preferred unless the contents of the script are not modified in server.
When name of a script which is deleted in local is changed or the script is moved in server, deletion in local is preferred unless the contents of the script are not modified in server.