The Automation meetings alternate times each meeting to accomodate the global team.

Agenda

* Reoccurring agenda items:

• Recap of previous meeting AutomationMeetings20111201

• Previous Action Items:
  • Automation Contribution and Automation Result drill down discussion
    • CharlesRankin, MaxVohlken, PaulMcMahan, PramodChandoria, VaibhavSrivastava and MichaelFiedler met on 5 December to discuss
    • Discussion covered
      • Modelling of the relationship. Do consumers need to be able to find contributions as independent artifacts? Sentiment was this was not likely. Always need them in context of a result.
      • Need to allow for contributions from non-local automation providers.
      • Need to allow for contributions in-line with an Automation Result and contributions which are referenced (via URL) from within the result
      • Follow on action item to propose exactly what the artifacts will look like and see if they hold up to our scenarios.
• Main topic: Discuss the DevOps and Deployment scenarios
• Plans for moving from scenario development to spec development
• Next meetings:
  • 15 December

Minutes

Attending: Michael Fiedler, Bill Higgins, Dan Berg, Max Vohlken, Rich Rakich , John Arwe, Srimanth Gunturi, Pramod Chandoria, Eric Bordeau, Vaibhav Srivastava, Paul Mcmahan. I know I missed a few others, please add your names.

* Recap of Automation Contribution discussion * DevOps? and deployment scenarios

• General observations
  • Automation "template" plans can be cloned and customized with more specific environment/input data prior to requesting execution. How "read only" are automation plans?
  • DevOps? automation scenarios are chained together. Build->Deploy in sandbox->Test->Deploy in production. The logical concept of passing results from one build to another is important.
  • There is a need to determine the "subtype" of an Automation provider. In an environment like DevOps? , times when only interested in build providers - other times just interested in test providers, etc. Need to filter at provider level.
• Scenario 1 - deployment execution
  • Full scenario represents multiple discrete automation plan executions chained together by the provider. Availability of previous stages results to current stage is crtical.
  • Deployment operations are triggered by events - started automatically from automation plans with environment information pre-configured for the most part.
  • Need the ability to store arbitrary environment data in an automation plan and automation request
    • Discussion on whether name/value was still an acceptable approach. General consensus was that it likely still held up, but need to see actual proposed artifacts to validate
  • "Posting activity events" == contributions to an automation result
  • Comments that it would help to re-align the language in this scenario with the OSLC artifacts discussed to date
• Scenario 2 - deployment configuration
  • When configuring an automation, need to be able to filter on certain automation provider types (build, test, deployment)
  • "Configure the stage" == configuring the environment for the execution
  • Policy aspects to this scenario are out of scope for OSLC spec
    • however decision points require automation results be available to support policy decisions

• Keeping the env configuration as simple as possible
• Need further discussion on "input" configuration vs "output" configuration in the results. Topic for next meeting

• 15 December - final meeting for 2011
• Continue environment configuration discussion
• Possible conversation on troubleshooting sub-scenario (task drill-down)
• Will try to have some artifact proposals for initial review