Contents Now Platform Custom Business Applications Previous Topic Next Topic Set up an instance hierarchy Subscribe Log in to subscribe to topics and get notified when content changes. ... SAVE AS PDF Selected Topic Topic & Subtopics All Topics in Contents Share Set up an instance hierarchy Set up an instance hierarchy that best supports your development life cycle. About this task This example demonstrates how to set up an instance hierarchy where several peer sub-development instances have the same parent development instance, but a more complex configuration may be required to handle multiple project teams or other customer requirements. Do not use Team Development with production or test instances. Do not use a test or production instance as the parent instance in Team Development. Do not make any instance the parent of a production instance. Production instances should never have a parent. When you back out a change on a Team Development instance, it backs out the change all the way back down the chain, including undoing the work on the source instance. This behavior can cause major problems on test and production instances. Procedure Provision a parent development instance on the same software version, such as Dublin, as the target instance, such as production. [Recommended] Clone the production instance to the parent development instance. Provision sub-development instances on the same software version as the parent development instance. (Optional) Log in to the parent development instance and clone it to the sub-development instances. On each sub-development instance: Define remote instance connections to other instances in the hierarchy that this instance needs to push and pull with. Select the parent instance. Pull all changes from the parent instance. Grant access rights to appropriate developers. Related TasksCreate an exclusion policyDefine a remote instanceEnable a code reviewSelect the parent instanceRelated ReferenceAccess rights for developers On this page Send Feedback Previous Topic Next Topic
Set up an instance hierarchy Set up an instance hierarchy that best supports your development life cycle. About this task This example demonstrates how to set up an instance hierarchy where several peer sub-development instances have the same parent development instance, but a more complex configuration may be required to handle multiple project teams or other customer requirements. Do not use Team Development with production or test instances. Do not use a test or production instance as the parent instance in Team Development. Do not make any instance the parent of a production instance. Production instances should never have a parent. When you back out a change on a Team Development instance, it backs out the change all the way back down the chain, including undoing the work on the source instance. This behavior can cause major problems on test and production instances. Procedure Provision a parent development instance on the same software version, such as Dublin, as the target instance, such as production. [Recommended] Clone the production instance to the parent development instance. Provision sub-development instances on the same software version as the parent development instance. (Optional) Log in to the parent development instance and clone it to the sub-development instances. On each sub-development instance: Define remote instance connections to other instances in the hierarchy that this instance needs to push and pull with. Select the parent instance. Pull all changes from the parent instance. Grant access rights to appropriate developers. Related TasksCreate an exclusion policyDefine a remote instanceEnable a code reviewSelect the parent instanceRelated ReferenceAccess rights for developers
Set up an instance hierarchy Set up an instance hierarchy that best supports your development life cycle. About this task This example demonstrates how to set up an instance hierarchy where several peer sub-development instances have the same parent development instance, but a more complex configuration may be required to handle multiple project teams or other customer requirements. Do not use Team Development with production or test instances. Do not use a test or production instance as the parent instance in Team Development. Do not make any instance the parent of a production instance. Production instances should never have a parent. When you back out a change on a Team Development instance, it backs out the change all the way back down the chain, including undoing the work on the source instance. This behavior can cause major problems on test and production instances. Procedure Provision a parent development instance on the same software version, such as Dublin, as the target instance, such as production. [Recommended] Clone the production instance to the parent development instance. Provision sub-development instances on the same software version as the parent development instance. (Optional) Log in to the parent development instance and clone it to the sub-development instances. On each sub-development instance: Define remote instance connections to other instances in the hierarchy that this instance needs to push and pull with. Select the parent instance. Pull all changes from the parent instance. Grant access rights to appropriate developers. Related TasksCreate an exclusion policyDefine a remote instanceEnable a code reviewSelect the parent instanceRelated ReferenceAccess rights for developers
