Mike, This scenario makes sense to me. In fact, I could insert some side comments (marked by "pm>") to demonstrate some important touch points with another scenario involving a test product.
pm> Test automation plan is associated (i.e. denoting "interest") with a build automation plan for Product A > - Build plan for Product A is executed via an Automation Request > > - Build result contains contributions for a) logfile locaions, b) > location of binary build artifacts such has jar files, plugins, war > files, etc c) location of binary install image produced by the build pm> Test automation plan is executed via an automation request using the build result described above. > - The test team wants to ensure that this build is kept for as long > they are using it for integration testing with Product B > > - The test team registers "interest" in this build (mechanism still > TBD) and the Product B build pm> Test automation result is linked/related to the build result. > - Optionally, the Product A build result is linked/related to the > Product B build result being used (mechanism still TBD) > > - When testing is complete, interest in Product A and B is > deregistered and the builds are eligible for teardown (deletion) if > no other parties are interested. pm> perhaps the verdict of the test automation result (pass/fail/etc) could also factor into the teardown Best wishes, Paul McMahan "Oslc-Automation" <[email protected]> wrote on 05/01/2013 09:56:45 AM: > From: Michael F Fiedler/Durham/IBM@IBMUS > To: [email protected] > Date: 05/01/2013 09:57 AM > Subject: [Oslc-Automation] Alternate teardown scenario > Sent by: "Oslc-Automation" <[email protected]> > > In last week's workgroup meeting I mentioned it might be helpful (to > me, anyway) to have an alternate to the primary teardown scenario. > We have been discussing teardown in terms of deployed configurations > or environments, but it would be useful to see if the concepts still > stand for a non-deployment scenario. While it might not be as > compelling, I've tried to apply some of the concepts to the build > domain and summarize it in the following bullets: > > - Build plan for Product A is executed via an Automation Request > > - Build result contains contributions for a) logfile locaions, b) > location of binary build artifacts such has jar files, plugins, war > files, etc c) location of binary install image produced by the build > > - The test team wants to ensure that this build is kept for as long > they are using it for integration testing with Product B > > - The test team registers "interest" in this build (mechanism still > TBD) and the Product B build > > - Optionally, the Product A build result is linked/related to the > Product B build result being used (mechanism still TBD) > > - When testing is complete, interest in Product A and B is > deregistered and the builds are eligible for teardown (deletion) if > no other parties are interested. > > Comments? Holds water or too contrived? > > Regards, > Mike > > Michael Fiedler > IBM Rational Software > [email protected] > 919-254-4170_______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
