What is the best practice for frequently updating process templates?
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?
<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.
Accepted answer
Michael i have such similar topic in my company and use resolution as you mention Scenario C its working without bad feeling
Comments
Thanks Matt.