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 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/21/2010 01:13 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Community Digest, Vol 13, Issue 24 | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| Send Community mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: [email protected] Subject: Re: [OSLC] Possible new Working Group - Automation Message-ID: <of0fc49dbf.c282130c-on852576b2.00636138-852576b2.00673...@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 | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f) |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |David N Brauneis/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | 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: [email protected] | phone: 919-254-9935 | mobile: 919-656-0874 From: Michael H?ttermann <[email protected]> To: [email protected] Date: 01/16/2010 12:53 PM Subject: [OSLC] Possible new Working Group - Automation Sent by: [email protected] 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 -- [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/community_open-services.net. _______________________________________________ Community mailing list [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/community_open-services.net End of Community Digest, Vol 13, Issue 24 *****************************************
