[OSLC] Automation (Build/Deploy) Workgroup Kickoff & Call for Participation
David N Brauneis
brauneis at us.ibm.com
Mon Feb 1 14:09:16 EST 2010
OSLC Automation (Build/Deploy) Kickoff Meeting
Friday February 5, 2010 11:00 AM - 12:00 PM EST (GMT -5:00)
**Please contact me directly for teleconference information
Tentative Agenda
Introductions
2010 Goals
Basic Integrations
Automation Providers
Automation Consumers
Automation Services/Definitions
Proposed Timeline
Scenarios
Draft Specification
Final Specification
Meeting Logistics
Frequency (Bi-weekly)
Web Conference
Teleconference
Next Steps
Regards,
David
_________________________________________________________________
david brauneis | ibm rational automation framework for websphere chief
architect
email: brauneis at us.ibm.com | phone: 919-254-9935 | mobile: 919-656-0874
From:
Scott Bosworth/Raleigh/IBM at IBMUS
To:
community at open-services.net
Date:
01/21/2010 01:48 PM
Subject:
Re: [OSLC] Possible new Working Group - Automation
Sent by:
community-bounces at open-services.net
Points well taken (1) the use of automation in software delivery is
broader than build and we might help ourselves by keeping that in mind,
(2) there's been specific interest expressed here in addressing build
integration scenarios as one topic of priority, and there may be other
areas as well (3) we need to stay focused and pragmatic. There has been
sufficient interest on this mailing list, in other workgroup discussions,
and off-line feedback from community members and workgroup leads to
suggest that we should take next steps to flesh out the proposal and form
a working group. I suspect that as the workgroup forms and debates its
scope, the right topic areas will be obvious and will fall out.
I understand David's point with the CM/Defect analogy, but perhaps a
better analogy is what we saw with another OSLC workgroup looking at
topics in Software Project Management. That group started by describing
the context of Software Project Management, including portfolio
management, project management, performance management and discussed a
variety of related integration topics before prioritizing their immediate
efforts around integrations for managing and estimating risk. They expect
to tackle other integration topics in Software Project Management in the
future.
So, perhaps a similar approach would be useful here? Setting the context
with a wiki topic for Software Development Automation, where a broad brush
of the areas for automation (build, configuration, deployment, analytics,
etc.) can be described, and which can serve as the basis for the workgroup
to consider which specific topics and scenarios it wants to tackle and in
what order. The workgroup can then figure out how it wants to operate and
how it will relate to other workgroups. I guess my real suggestion is
let's get going and let the workgroup debate and propose the details.
David, if your agreeable to this, and since you proposed the idea for the
workgroup ;-), would you be willing to take a first pass at a context page
on the wiki and setting a date and time for a workgroup kickoff call
within the next 30 days or so? In the meantime, I'd encourage everyone to
solicit others to join in the workgroup.
Thanks...Scott
Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com |
919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
David N Brauneis---01/20/2010 10:34:33 AM---If the years of experience
working on Rational Build Forge have taught me anything, it is to very
careful in what name you choo
From:
David N Brauneis/Raleigh/IBM at IBMUS
To:
community at open-services.net
Date:
01/20/2010 10:34 AM
Subject:
Re: [OSLC] Possible new Working Group - Automation
If the years of experience working on Rational Build Forge have taught me
anything, it is to very careful in what name you choose for a topic like
this specification. I have spent a lot of time over the last 3 years
trying to explain how a product like Rational Build Forge is bigger than
"build" (which most people think of as compilation/packaging) - expanding
beyond a limiting name is extremely difficult. The product team has
literally spent years trying to explain the difference between build and
Build - one being the typical task a developer thinks of as compiling
(build), the other being a greater automation flow that might contain
static analysis, junit testing, and deployment of the results (Build).
If you take a look at the products that encompass the Rational Software
Delivery Automation segment, we are a lot more than just Build and
Deployment - we cover automated code analysis/security analysis, generic
automation (including but not limited to build), and
WebSphere-specific/Middleware-specific automation (installation,
configuration, and deployment). I think that if we really try to narrow
the scope in the naming of this work group, we will be sorry because it
may not even fit our needs in the SDA business segment.
While I agree that we do not want to try to boil the ocean, I think we
need to keep that naming broad enough to cover the scenarios that we will
desire be a part of the 2.0 and future versions of the specification. I
think that pigeon-holing this workgroup into the Build area by naming
would be like pigeon-holing the CM folks by naming their workgroup
"defects."
I think as we flush out the design in this area there will be a couple
areas that need to be covered in the automation specification:
1. Automation "Step" providers - tools that provide a service that could
be automated
2. The ability to query automation projects, run automation projects,
schedule automation projects, and get the results of an automation project
run
I think we want to be careful since this "Automation" area will bridge and
be useful to the Rational Software Delivery Automation products as well as
some of the Quality Management products/features (like Test Lab Manager)
as they integrate with Change Management, Source Control Management, Asset
Management, and other areas.
Since the development of a specification is scenario based and I do not
feel that the 1.0 version of the specification could possibly cover all of
the different scenarios, I suggest that we choose a couple of scenarios to
focus on for the initial revision and then continue to add to it over
time. I think having different workgroups for Build, Deploy, Analyze, etc.
for the different scenarios over time will lead to less consistency in the
overall integration areas.
Regards,
David
_________________________________________________________________
david brauneis | ibm rational automation framework for websphere chief
architect
email: brauneis at us.ibm.com | phone: 919-254-9935 | mobile: 919-656-0874
From:
Michael Hüttermann <michael at huettermann.net>
To:
community at open-services.net
Date:
01/16/2010 12:53 PM
Subject:
[OSLC] Possible new Working Group - Automation
Sent by:
community-bounces at open-services.net
Hello,
I would like to join this group and help working on that.
I also like "Build and Deployment" more, because you can automate pretty
everything, not only build and deployment. In practice, often also
"configuration" is interfacing build/deploy. Maybe it could be also
included into this group, it can be handled as a totally separate
discipline too though.
Thank you.
Best regards
Michael
--
michael at huettermann.net
http://huettermann.net
I agree with Samit's concern, and I agree that "Build and Deployment"
would be an excellent name.
Cheers,
Geoff
From:
Samit Mehta/San Francisco/IBM at IBMUS
To:
community at open-services.net
Date:
01/13/2010 11:01 AM
Subject:
Re: [OSLC] Possible new Working Group - Automation
Sent by:
community-bounces at open-services.net
My two cents...
Automation sounds very generic and up till now the groups have been very
specific around particular software delivery discipline. I would suggest
calling it a "Build and Deployment" workgroup.
I completely support the need for such a group - it would definitely fill
a crucial gap in the ongoing OSLC working groups.
---------------------------------------------------------
Samit Mehta
IBM Rational Software - Business Development
Ready for IBM Rational software program:
http://www.ibm.com/isv/rational/readyfor.html
Ready for IBM Rational software Plug-in Central:
http://www.ibm.com/developerworks/rational/downloads/ready.html
Scott Bosworth/Raleigh/IBM at IBMUS
Sent by: community-bounces at open-services.net
01/13/2010 08:37 AM
To
community at open-services.net
cc
Subject
Re: [OSLC] Possible new Working Group - Automation
Hi David, you've taken the right first step in proposing the new working
group here ( see
http://open-services.net/bin/view/Main/OslcWorkgroupPrinciplesandBestPractices
- How are workgroups formed?). I'd like to open it up for comment over the
next week or so to the community on this maillist. Based on that feedback
and assuming there is general encouragement to proceed, the next step
would be to author an AutomationHome wiki page that fleshes out additional
proposed details of the workgroup as outlined in the Best Practices topic,
and then consultation with other Workgroup leads to ensure we wouldn't be
introducing duplicative or overlapping efforts.
As far as the proposal itself, my two cents are that this seems to be a
good topic and in fact one that would fill a gap that has come up in other
workgroups. The SCM and Asset Management workgroups both have integration
scenarios with Automation (Build) systems, and if I recall correctly, some
of the SCM scenarios were deferred because they required the definition of
Build services which had no catcher at the time. Also, there was some
early interest in Quality Management around test automation, though that
was tabled in favor of other scenarios.
Other feedback for David?
Thanks...Scott
Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com |
919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
David N Brauneis---01/12/2010 08:25:16 PM---Since I am new to
participating in the Open Services for Lifecycle Collaboration (OSLC)
community, I was unsure how new Working
From:
David N Brauneis/Raleigh/IBM at IBMUS
To:
community at open-services.net
Date:
01/12/2010 08:25 PM
Subject:
[OSLC] Possible new Working Group - Automation
Since I am new to participating in the Open Services for Lifecycle
Collaboration (OSLC) community, I was unsure how new Working Groups
(topics) are proposed or initiated but would like to propose a new Working
Group (topic) focused on Automation. Automation is a best practice and an
important aspect of the software development and delivery lifecycle which
spans the different stages - including multiple technologies (compilers,
languages, scripts, platforms, etc...) and activities(compilation,
analysis, packaging, deployment, etc..). Automation provides the
capability to eliminate manual handoffs between the different disciplines
in the software development and delivery lifecycle as well as
traceability.
Initially, I think that the Working Group (topic) could focus on the a
couple of scenarios:
1. Build - automated compilation and packaging of code
2. Deployment - automated delivery/installation of build output
Regards,
David
________
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100201/1f2098ab/attachment-0008.gif>
More information about the Community
mailing list