[Oslc-Automation] Alternate teardown scenario

[Paul McMahan]

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" <oslc-automation-bounces at open-services.net> wrote on
05/01/2013 09:56:45 AM:

> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 05/01/2013 09:57 AM
> Subject: [Oslc-Automation] Alternate teardown scenario
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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
> fiedler at us.ibm.com
> 919-254-4170_______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net