Copy/promote/apply process template customizations
Working on a complex environment requires in many cases to have an RTC test env and an RTC prod env. Upgrades, tests, customizations are first made in the test env and then, if everything works, applied in the prod env.
As for process customizations, it seams that the only way to copy/promote/apply changes from test to prod is to manually perform a complex list of operations as described in this post: https://jazz.net/wiki/bin/view/Main/ProcessUpdateForExistingProjectAreas
This procedure requires a big effort, creation of useless projects (to be archived) and is not 100% safe.
Is there a better way to perform all this, with something like export/import, or is there any plan to support a promotion procedure for dev->test->prod RTC working env ?
thanks
As for process customizations, it seams that the only way to copy/promote/apply changes from test to prod is to manually perform a complex list of operations as described in this post: https://jazz.net/wiki/bin/view/Main/ProcessUpdateForExistingProjectAreas
This procedure requires a big effort, creation of useless projects (to be archived) and is not 100% safe.
Is there a better way to perform all this, with something like export/import, or is there any plan to support a promotion procedure for dev->test->prod RTC working env ?
thanks
3 answers
On Tue, 25 Aug 2009 08:38:06 +0000, pcravino wrote:
Currently, copy/paste is the best you can do. We would like to do better
and this kind of "process refactoring" is one of the options on the table
as we're planning for our next major release.
--
Jared Burns
Jazz Process Team
Working on a complex environment requires in many cases to have an RTC
test env and an RTC prod env. Upgrades, tests, customizations are first
made in the test env and then, if everything works, applied in the prod
env.
As for process customizations, it seams that the only way to
copy/promote/apply changes from test to prod is to manually perform a
complex list of operations as described in this post:
https://jazz.net/wiki/bin/view/Main/ProcessUpdateForExistingProjectAreas
This procedure requires a big effort, creation of useless projects (to
be archived) and is not 100% safe.
Is there a better way to perform all this, with something like
export/import, or is there any plan to support a promotion procedure for
dev->test->prod RTC working env ?
Currently, copy/paste is the best you can do. We would like to do better
and this kind of "process refactoring" is one of the options on the table
as we're planning for our next major release.
--
Jared Burns
Jazz Process Team
This is the approach we are taking:
1. Limit permissions so that users can only be added as project members by an admin.
2. Limit permissions so that only project members in a specific role (teamlead for using the defaults) can update the process configuration.
This allows us to know that no process changes have occurred at the project level and avoids the XML merge. The limitations to this are:
1. Admins must add all project members to the project (remember that project member really = project admin)
2. This takes away to configure the default team process for all teams in the project. This is probably good if you have lots of teams and if you don't doesn't really matter much since they can override the process at the specific team level.
All of this still leaves project members with the privileges to define timelines/iterations, create teams, and configure categories.
1. Limit permissions so that users can only be added as project members by an admin.
2. Limit permissions so that only project members in a specific role (teamlead for using the defaults) can update the process configuration.
This allows us to know that no process changes have occurred at the project level and avoids the XML merge. The limitations to this are:
1. Admins must add all project members to the project (remember that project member really = project admin)
2. This takes away to configure the default team process for all teams in the project. This is probably good if you have lots of teams and if you don't doesn't really matter much since they can override the process at the specific team level.
All of this still leaves project members with the privileges to define timelines/iterations, create teams, and configure categories.