It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×4,712

question asked: Jun 07 '17, 2:33 p.m.
question was seen: 1,283 times
last updated: Jun 30 '17, 11:55 a.m.

Related questions

What is the best practice for frequently updating process templates?

0
Michael Dexter (92●2●11●14) | asked Jun 07 '17, 2:33 p.m.
Currently I have a Master project with 23 Children that get updated through process sharing so that piece is already in place but I come to the forum to seek others opinions.

I own the process template updates and have weighed pros and cons to different methods but still find myself without a perfect solution.  
 
Scenario A:         Make changes to a project, extract project to a template, create new project from template, test, repeat.
-          This is painful and leads to a ton of process templates that can never be archived due to having a project be created from it.
 
Scenario B:          Put my DEV project in DEV, my UAT project in UAT and PROD project (Master parent) in PROD with Children in PROD
-          This is painful because e.g. validator scripts will get appended a DB UUID that will be different from DEV to UAT to PROD
-          What is best way to find out the ID of the "going-to" environment and then updating all unique keys?


Here is an example of the unique DB UUID key I am speaking of:
Attribute Customization Validator Script -->, I do mean _r3CWEEtpEeeGtepOyoaYJA as in
<validatorid="com.ibm.team.workitem.valueproviders.VALIDATOR._r3CWEEtpEeeGtepOyoaYJA"name="Vali"providerId="com.ibm.team.workitem.shared.common.internal.valueProviders.ScriptAttributeValueProvider">                        <scriptclass="com.example.Validator"path="/workitem/scripts/common/vali.js"/>
</validator>
 
Scenario C:          Create all my projects on PROD but name them such like ( {name-d}, {name-u}, {name-p}, d for dev, u for uat and p for prod )
-          This is awesome because I can copy and paste the full XML from project to project, fetch the JS from attribute customizations and I am done
-          Downside, anything I create in “d” appears in JRS as if it were in PROD today.  We can communicate changes each release but you know the curious ones will “discover” the (new, but unexplained) and want to play.
 
Is there no ideal solution that is fast, easy and able to conceal half-baked changes till fully baked.  

The floor is open... :)

Accepted answer

0
permanent link
Matthew More (40●3●13) | answered Jun 09 '17, 2:25 a.m.

 Michael i have such similar topic in my company and use resolution as you mention Scenario C its working without bad feeling 

Michael Dexter selected this answer as the correct answer
Comments
Michael Dexter commented Jun 30 '17, 11:55 a.m.

 Thanks Matt.


I guess this is good enough.  I did not see much comments here so today we stay with Scenario C.  This is new for us, I just implemented that 2 months ago.  So far I have not heard a lot of noise.  Hopefully IBM will hear our cries for how to make something not visible to JRS until fully baked.

Have a great day.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.