Enabling “Team Development” on a TimeXtender SaaS instance or a TimeXtender Version 20.10 project allows multiple developers to work simultaneously on different parts of the data estate and coordinate their changes through the addition and release of “Work Items” on the objects under development. Understanding how to use work items is essential for developers who need to implement their changes without overwriting or conflicting with the work of others, which could ultimately lead to corruption errors that must to be addressed before further development can continue.
Work Items are like Post-it notes on data estate objects that let other people know that someone else is currently working on this item and it may be subject to change. Coordinating changes to a TimeXtender data estate can be challenging, as some objects may be dependent upon or have a relationship with other objects, and changes made to one object may result in other objects being changed as well. Therefore, it may be necessary to create multiple Work Items for all of the objects that may be impacted by a particular development task.
Best Practices for using work items
Before proceeding with any development work, check to see if there is a newer version of the project or instance available. If so, close and reopen the project or instance to ensure your work is performed on the most recent version. Note that with Team Development enabled, it is possible that another developer may have saved out a new version of the project or instance and you may not be aware of it. The specifics on how to check for newer versions depends on the version of TimeXtender you are using and is desribed in more detail in the “Coordinating Versions and Associated Work Items” section below.
Always create work items before peforming any work, and note whether an object already has a work item before creating your own. If so, wait for the other work item to be released before creating your own work item on the same object.
Create work items on all of the objects that may be impacted by your changes. Objects that change to a red font and are marked with an asterisk as a result of a change should all have their own work items as to notify other developers that these objects may be changed as part of a future deployment.
The following examples illustrate how work items may be needed for multiple objects involved depending on the type of development work being undertaken.
- The addition of a conditional lookup will affect both the source and target tables, so work items should be created for both of these tables.
- Deleting a field that is involved in a mapping will cause the data area table involved in that mapping to be marked in red. Work items should therefore be created on both the original table and the destination table that included the mapping for the deleted field.
- Updating an instance variable will mark all objects where the variable is used in red. Create work items on all of the related objects where the instance variable is used.
- Modifying a script action will affect all of the objects where the script action is used. Create work items on all of the objects that use the script action.
Implementing Work Items
Enabling Team Development
The “Team Development” attribute must first be enabled before work items can be employed. For the TimeXtender SaaS Version, this is done in the TimeXtender Portal on the Data Warehouse or Semantic instance level.
For TimeXtender Version 20.10, Team Development is enabled on the project level in the Tools->Repository Administration dialog.
Adding Work Items to Objects
Right-click on an object and select “Add Work Item”.
Enter text in the description area that describes the work that will be done and then click “Create work item”.
If other users attempt to create a work item on this same object, they will see that a work item from a different user already exists for that object and the “Add Work Item” link is in red, which indicates that an additional work item would conflict with an existing work item.
In order to understand all of the work items that are currently active, go to Tools->Work Items to open the following dialog that displays all of your own work items on top and all of the other work items for other users below.
Completing or Releasing Work Items
Work items are generally completed or released during the deployment of their associated object. During the deployment of a data area, the work items created by that user are listed below.
By checking the box next to a Work Item during a deployment, this work item will be associated to the new version of the instance or project that gets created as part of the deployment, which means that this new version contains the changes that were coded as part of that work item.
For TimeXtender SaaS versions, the work items associated to specific versions are available in one of the two following methods:
- Open Version dialog. Close the instance if it is already open, then right-click on the instance and select “Open Version”.
- Advanced->Version Notes. Right-click on the Instance, select Advanced, and then click on “Version Notes”.
In the following example, there is a deployment that had 2 work items associated with it.
Click on the “Version note” column field for that particular version to view the Version Deployment screen that lists out the deployment details, including the two work items and their descriptions, which may contain additional information on the development work that was performed.
For the TimeXtender 20.10 Versions, the Version Notes are available in the Project->Select Versions dialog as shown below.
Coordinating Versions and Associated Work Items.
Work items that are checked as part of a deployment are incorporated into that new version. After the deployment is complete, the user that performed the deployment will have open the new version of the product or instance that was just created by the deployment. However, other users that had the project or instance open during the deployment may still be on the previous version, and are therefore now a version behind. If one of these users goes to Tools->Work Items, they may see the other Work Items that were deployed by the other user as now released and displayed in a green font.
The screenshot above shows two released work items from a different user listed below while this user is on Version 173 of the Sandbox project. The fact that there are two released work items items listed below is an indication that a newer version of the project is available. In the TimeXtender Desktop Version 20.10, it is possible to go to the Tools->Repository Administion dialog to see what the most recent version is for all the available projects.
As shown above, the user currently is on Version 173 of the SandBox project, however, the Repository Administration dialog indicates that Version 174 is the most recent version of the project that has been saved.
Before beginning any new development work then, it is a best practice to open the most recent version of the product or instance. If you do not have any changes to save, then the most straightfoward way to open the most recent project version is to simply close it and then reopen it.
The TimeXtender Version 20.10 Repository Administration dialog includes the “View Version Notes” button that opens the Version Notes dialog that is similar to the TimeXtender SaaS Version Notes described above. Clicking on the “Version Note” column will also display the Deployment dialog that includes the associated work items deployed along with that version.
In the TimeXtender SaaS Desktop, opening the Version Notes is an easy way to check whether a newer version of the instance is available.
In the TimeXtender SaaS Version Notes shown above for the Chemicals Data Warehouse Instance, we can see that Version 58 is currently open but there is a newer version 59 that is also available. Similar to TimeXtender Version 20.10, if we do not have any changes to save, then the most straightforward way to open the most recent version of the instance is to close it and then reopen it.
Keep Associated Work Items
Work Items can be deployed without being released by clicking the “Keep Associated Work Items” check box during the the deployment
After the deployment is complete, the work item will still be associated with the data object so that additional development work can be completed until such time as it is appropriate to release it in a subsequent deployment, or perhaps simply delete the work item if it is no longer needed.
Repository Corruption Issue with Team Development
When one or more developers are working on the same instance or project, there is the possiblity that one or both will save changes that will conflict or adversely impact the work of another, and a corruption in the project or instance is the result. The most common corruption error is the “Object reference not set to an instance of an object” null reference error.
To resolve this error, you can request our Product Team review your repository via a support ticket. For TimeXtender SaaS versions, our product team may be able to indentify and remove the corruption in the repository database that is stored on our Cloud server. For TimeXtender 20.10 users, they will need to send us backup of their repository database via an FTP link that we can provide. Helpful information to supply with the support ticket includes the following:
- Screenshot and details of the error encountered.
- Name of the corrupted project or instance.
- SQL Server Version (For TimeXtender 20.10 users.)
Otherwise, users can consider the following potential workarounds that can be attempted on their own, which may or may not be able to resolve the error.
- Revert to an earlier version of the project or instance that was in good working order.
- For TimeXtender 20.10, you may consider restoring your repository database to a period of time priror to the corruption. However, note that any changes made subsequent to the backup date will be lost.
- Open the previous version that works, export it to XML file, create a NEW project repository, Import the XML and continue working. Note that this approach has the downside of eliminating all of the previous versions, so you would need to go back to the original repository in order to access any previous versions.
