Hi,
In a previous discussion, Pramod has proposed to a oslc_auto:automationType attribute, but there is some objection to it, see the thread here - http://open-services.net/pipermail/oslc-automation_open-services.net/2012-June/000182.html Automation plan: We don't have oslc_auto:automationType attribute. Without this we can't distinguish whether Automation is for build, test, deployment, cloud etc.. I think this needs to be typed. <dnb>I actually do not agree with an approach that types the automation, there are some automation plans that might perform one or more of those different types as a part of the workflow (think a continuous integration or continuous delivery product - i.e., DevOps)... How would you characterize those? Also, some automation providers will exist that can support more than one type of automation and do not need them to be separated. What do we gain by forcing this? </dnb> <pchandor>I think when a AutomationPlan represents a group of Automations (like TestSuite in RQM, workflow in DevOps), it might make sense to call them "complex" type. Consider a scenario like user is defining a workflow in RTC, that when a build automation is completed, wants to run a Test Automation. When user will query automation from the automation provider (RQM), It would definitely like automation plan of 'test' type be listed to choose from. Do we think this should be defined in service providers name space?. I think having a type in spec will provide client hint about what type of Automation plan it is.</pchandor> <dnb>I really think this is unnecessary, it is by choosing the automation plans from the provider where this "hint" of what the automation plan might do. I think that the type would like end up being close to unique per automation provider which kind of defeats the purpose. What about automation providers that can do some generic automation work, would it then be up to the Automation Provider to change and require the end user to define the type of automation it is from a list of categories. I do not see what the gain for the consumer is here... If I ask RQM and it returns test, if I ask RTC and it returns build, and if I ask RAF and it returns deployment (always in each of these cases) what is the purpose?</dnb> I'm bringing this discussion up again, because from end user story point of view, we have an issue not knowing the type of automation. Consider this user scenario: As a RTC user, I want to set the test(automation) result inside my build result so that I can view the test result directly from RTC. When user configures the cross server communication in RTC, the steps are usually the following Step1 - Set up server friend relationship Step2 - Set up the project areas associations If the friend server is an automation provider that provides several types of automation (build, test, provision, deployment...etc.), it could be confusing for the user which one is for which. Here is an example, RQM is an automation service provider for both test and provisioning, this could be in its rootservice.xml <jd:oslcCatalogs> <oslc:ServiceProviderCatalog rdf:about="https://myserver1.ibm.com:9443/qm/auto/test/catalog";> <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> </oslc:ServiceProviderCatalog> <oslc:ServiceProviderCatalog rdf:about="https://myserver1.ibm.com:9443/qm/auto/provision/catalog";> <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> </oslc:ServiceProviderCatalog> </jd:oslcCatalogs> As you can see, <oslc:domain> for these 2 service providers are the same, however, they just have different rdf:about URL, one is for test automation, the other is for provision automation. But to the end user, when they have to choose the project area association, all they see are 2 "Uses - Automation" choices, they don't know which one is for which. The association would show 2 "Uses - Automation" options, with no additional information to show which one is for test, which one is for provisioning Step3 - Using a picker to choose an Automation result When programming this picker, it will need to be in the context of some integration points, but if we don't know what type is the automation association, how can we make sure we display the right content? e.g. we need to bring up the UI picker to choose an automation (test) result, but it could show a list of the automation result for provisioning rather than for test. Jing J. Qian Development, Rational Quality Manager Rational Software IBM Software Group 4205 S. Miami Blvd. Durham, NC 27703 Tel: 919-254-9455 T/L: 444-9455
