Previous Next  

  Overview: Team Development

Team development allows for multiple people to perform development work on a Discovery Hub project simultaneously. This allows multiple users to work with complete transparency and understanding of who is working on what.

Work Items

Development tasks are communicated to other users by assigning Discovery Hub tables as "Work Items". You can make comments on your work items if desired which will be visible to other users. Assigning a Work Item to yourself, should communicate to other users that you are "reserving" this item for development work and changes by other users should be avoided until it is released. Work Items for all users in the same project are listed in the Work Items window. Work Items may also be associated to a save or version of your project, assisting in development notation risks.

While Team Development is supported, and recommended to provide increase productivity, it also comes with some potential risks that you should be aware of. It is important to understand that Work Items do not prevent other users from making changes to the object. If two users make changes to the same object and both users attempt to save those changes to the project repository this could have undesired results.

  1. The subsequent save could overwrite the previous, potentially losing work.
  2. The conflicting saves could corrupt the project repository making your project unusable.

Best Practices

To mitigate these risks, it is best to always follow a number of best practices with working with multiple users:

  1. Never work on the same object (e.g. Table, Dimension, Cube, Script Action) as anyone else. To avoid this:
    1. ALWAYS create work items before making any changes to an object.
      1. Right click the object, create work item.
    2. Create work items on associated objects that may be impacted by your changes. This should be any other object(s) that will be marked "dirty" (turn red) when your change is made.
      • Example: When creating a conditional lookup. This updates the indexes on the source table and it will be marked as dirty. So both the source & target tables should be marked as work items.
      • Example: Deleting a field that is mapped to a Data Warehouse will cause the data warehouse table to be marked as dirty. Create work items on both the source & target tables.
      • Example: Updating a project variable will mark all objects where the variable is used as dirty. Create work items on all objects where the variable is used.
      • Example: Modifying a script action and updating items where the script action is used. All objects that are updated should be marked as work items.
    3. If anyone else has the item marked for their use, wait for them to release the work item before you make modifications to or CREATE LOOKUPS into that table.
      1. If two developers are creating/modifying lookups into the same source table, this can corrupt the repository by making conflicting changes to the table’s index.
    4. Once you are done working on an object, release the work item.
    5. Keep the work items window open when working. This enables you to see what items other users are currently working on.
  2. Avoid renaming objects when working with multiple users. Exceptions to this are:
    1. You just created the table and have not saved yet.
    2. Nobody else has the project open (you can see who has an open project in the work items dialog)
    3. All active users immediately Save and Reload the project immediately after the name change.
  3. Always Save + Reload (CTRL + F5) before you start a new development task. This makes sure that you get the latest version of all objects before you start taking over somebody else’s work.
  4. Configure a daily (or more frequent) backup of the project repository. This can be used in the event a conflict and subsequent corruption occurs.

Discussion
6 comments