Here is a user story, and a use case and scenario for it, that I would like to contribute for discussion. There are multiple ways this could be implemented. Some will be supported by OSLC Automation 2, some won't. I hope discussion of this user story will bring out some problems that can occur when implementing this use case, whether OSLC really is a good fit for all the points of integration, what guidance or best practices can be offered to help people if they are considering this use case, and if there are any additions that can be made to the spec to better support it.

(This first half of the page should be 100% achievable in Automation 2.1. The additional stuff - such as avoiding hard-coded environments to allow 'elastic' deploy & parallelization - is in the section marked "old contents of this page", but is less fleshed-out. I want to ficus on the simple scenario first.)


Stories, use cases & scenarios

Story 1: Basic build, deploy & Q2 test:

For a quick read, see the scenario walkthrough slides:

As Eva,
I want to add deployment and automated functional test steps to my existing build script (pipeline),
In order to perform continual functional testing in a pipeline composed of steps pulled together in a consistent way without having to learn any vendor-specific APIs (or do any scripting at all).

Before & after (benefits):

(Bullet points from "after" relate to benefits over the equivalent points from "before")

Use case:

Scenario - Jenkins:

(This image wasn't created with reference to the scenario below, but it's close enough.) diagram.png

Evaluation of story/scenario:

Old contents of the page (ignore in most cases)

User story:

Use case:

Actors: Release engineer (human), Build process (automated system), deployment provider (automated system), test system (automated system)

These steps are very generic, and there are multiple ways this could be implemented. Some will be supported by OSLC Automation 2, some won't. There are many scenarios that could be built on top of this very generic use case, and which one will be used depends usually on what tools are available and what parts of the system are already working (i.e. what tools are already in use).

Scenario 1: Ant build script, uploading artifacts directly to a deployment provider

Extension: The release engineer could add a step to the build script to "promote" the build if it passes the tests. This could either be by modifying a property on the deployment provider, or by pushing it to a separate repository.

Other scenario ideas:

I'm not sure I've got the best separation between use case and scenario, but I could express this in any number of layers, so I've just gone for whatever was easiest to write. I'm in a bit of a rush this week, so I haven't proof-read it, so apologies for any typos or inconsistencies.

I ought to write up the two concrete scenarios that I have actually come across, in addition to this generalisation, to help focus discussion and try to solve problems that I've actually seen, but I'll submit this now so people can start reading it and thinking about it.


Scenario 2: RTC and UrbanCode Deploy

In this scenario: after an RTC/Jazz Build Engine build completes, it creates a new version of a component in UrbanCode Deploy and requests for it to be deployed.

This scenario is detailed in this blog entry:

(Note that the blog post has not been submitted under the OASIS IPR policy.)

UseCasesAndRequirements/DeployingBuildArtifactsContinuousIntegration (last edited 2014-10-14 09:11:34 by martinpain)