[OSLC] Community Digest, Vol 13, Issue 24

Andrew J Berner ajberner at us.ibm.com
Thu Jan 21 21:24:25 EST 2010


While within the IBM Rational brand we use Delivery Automation because our
tools have a broad range of features, it will be either misunderstood or
not recognized by the wider community that's the audience for open
services.  David is certainly correct that "Build" is too narrow.  The
suggestion I've seen in this thread, "Build and Deployment", would be
meaningful to the entire community of providers and consumers.  The
"automation" aspect is of course an inherent part of all OSLC interfaces,
so not useful in the name: the reason for defining an open interface around
build and deployment is for tools which provide and consume the interface
to collaborate around automating the functions.  David mentions some
specific functions that you would expect a provider of a "build and
deployment" interface to offer, for example the ability to automate
installation, configuration, and deployment.

But a more general name such as "delivery automation", since it's being
used outside the context of the specific tools and messaging from Rational,
would likely be met with a puzzled look or confused with other automation
around the development/delivery lifecycle; terms like "delivery" are not
standard enough and easily confused, and "automation" is inherent in all of
OSLC.  Note already in this thread, the name was already confused with
"Development Automation".

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |community-request at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |community at open-services.net                                                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |01/21/2010 01:13 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Community Digest, Vol 13, Issue 24                                                                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |community-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Send Community mailing list submissions to
             community at open-services.net

To subscribe or unsubscribe via the World Wide Web, visit

http://open-services.net/mailman/listinfo/community_open-services.net
or, via email, send a message with subject or body 'help' to
             community-request at open-services.net

You can reach the person managing the list at
             community-owner at open-services.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Community digest..."


Today's Topics:

   1. Re: Possible new Working Group - Automation (Scott Bosworth)


----------------------------------------------------------------------

Message: 1
Date: Thu, 21 Jan 2010 13:47:07 -0500
From: Scott Bosworth <bosworth at us.ibm.com>
To: community at open-services.net
Subject: Re: [OSLC] Possible new Working Group - Automation
Message-ID:

<OF0FC49DBF.C282130C-ON852576B2.00636138-852576B2.006730EB at us.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"


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)


|------------>
| 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://open-services.net/pipermail/community_open-services.net/attachments/20100121/46cebf47/attachment.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <
http://open-services.net/pipermail/community_open-services.net/attachments/20100121/46cebf47/attachment.gif
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <
http://open-services.net/pipermail/community_open-services.net/attachments/20100121/46cebf47/attachment-0001.gif
>

------------------------------

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net


End of Community Digest, Vol 13, Issue 24
*****************************************







More information about the Community mailing list