Team Development

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.
  1. Save Project to Local
  2. Commit to the Project Server
  3. Detect Competitors of the Project / Script
  4. Reflect the Server Project Condition to the Local Project
  5. Manage the Local Script History
  6. Set the Comments on the Project and Tags

Save Project to Local

Saves the project to local.
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.

In DataSpider Studio, projects are saved by user unit on the OS running the Studio. In DataSpiderStudio for Web, projects are saved by user unit on the OS running DataSpiderServer.
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".
  1. Recognize a project conflict
    → If a conflict is detected, a project conflict occurs
    → If not, proceed to 2

  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

  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

Describes the state where the changes in the project are competed among several team members.
The project conflict occurs when the project structure of the server is changed by other team members when committing a project.
Changing the project structure includes operations such as changing the layer structure (path) formed with folders/scripts, the order of displaying folders, names, and delete.
To avoid generating project conflicts, it is recommended to determine the project structure at an earlier level of development, or limit team members who can modify the structure.

If a project conflict occurs, the "Conflicts of projects" screen which allows you to check the condition of the local project as well as the server project appears.
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.  
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.

To solve conflicts in the project, below solutions can be applied. 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.

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. 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.
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 Competitors of the Project / Script".
  1. Recognize a project conflict
    → If a conflict is detected, a project conflict occurs
    → If not, proceed to 2

  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
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

Notes