Scenario: deploying build artifacts as part of Continuous Integration

[Martin P Pain <martinpain@uk.ibm.com>]

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.


User story:

As a software developer
I want the result of every Continuous
Integration build of my software to be deployed into a cloud
In order for automated testing to be
performed on it

Use case:

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

At configuration-time:
C1. The release engineer configures
the three automated systems to work together.
At run-time:
R1. An automated build is triggered
(may be by a developer, may be by an action such as checking in code, or
it may be on a timer, or any other trigger)
R2. The build process runs and, if successful,
generates one or more build artifacts.
R3. The deployment provider deploys
these built artifacts
R4. The test system runs automated tests
against that deployment
R5. The deployment provider tears the
deployment down

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

At configuration time:
C1. The release engineer writes the
build script to generate the artifacts
C2. The release engineer adds a step
to the build script to upload the artifacts to the deployment provider
(currently this would have to use provider-specific knowledge) - hard-coding
the component that these artifacts comprose, and providing some way to
generate or retrieve a version number (e.g. by setting it to use the timestamp
at which the build started). (Variant A: the provider could provide the
version/ID, and return it to the build script)
C3. The release engineer adds a step
to the build script to deploy the artifacts "into the cloud",
specifying the environment template to use. This could be by selecting
an Automation Plan from the provider, hard-coding its URI into the build
script, and using a value returned from the step created in C2 pass in
the identifier of the build artifacts that were uploaded.  (Variant
B: it could identify a particular standing environment, rather than a template,
but this doesn't support parallel builds.)
C4. The release engineer adds a step
to the build script to trigger an automated test system to run automated
tests against the deployed artifacts. Using a value returned in step C3
to let the automated test system know where the deployment is against which
it is to run its tests.
C5. The release engineer adds a step
to the build script to tear down the deployment when the tests have finished.
At run-time:
R1. The build is triggered. The ant
script runs, and generates build artifacts.
R2. The ant script uploads the build
artifacts to the deployment provider, specifying which component these
artifacts comprise, and a version (probably a snapshot timestamp). When
the upload is complete, the ant script stores an identifier for this upload
(may be the version/timestamp it provided, may be a unique ID or URI returned
by the provider).
R3. The ant script requests that the
deployment provider deploy the component "into the cloud", specifying
the environment template to use. Ths could be by creating an Automation
Request for the Automation Plan whose URI was hard-coded in to the build
script, and providing as one of the properties the identifier stored at
the end of step R2. When the deployment is complete, the ant script stores
one or more values that point to where the deployment can be located (e.g.
may be output properties from the Automation Result).
R4. The ant script triggers an automated
test system to run automated tests. This could be by creating an Automation
Request for a second Automation Plan whose URI was hard-coded into the
script. The ant script passes in the values stored at the end of step R3,
so the tests know where the system under test is deployed. The ant script
waits for the tests to finish executing.
R5. The ant script uses some value stored
in the end of step R3 to request that the deployment is torn down.

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:
* The build script can send it to a
separate repository system, then give the deployment system a link to that
one.

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.

Questions:
* Is there a standardised way to get
the build artifacts to the deployment provider? (Does it need to be loosely-coupled?)
* There will be some aspects in which
the different components will always be tied to each other (e.g. the deployment
provider needs to know how to deploy that kind of build artifact, and the
test system needs to be able to access the deployment - it may be able
to do all testing over the network, but alternatively it might need an
agent on the deployed system from which to execute tests "locally"
to that system). How valuable is loose-coupling ofthe build script with
the deployment provider, and with the test provider given these ties? Is
it enough to say that the person setting it up (here, the "release
engineer") needs to make sure they configure systems that can work
together, but using loose coupling still helps swap those systems in &
out as needed?
* Even if we chain the output parameters
of the deployment step into input parameters of the test step, how do we
know that the two systems will use the same property names? Would we need
to map them? Would that introduce provider-specifics that defeat the purpose
of the loose coupling? Or is that an acceptable minimum of configuration
change that would be needed if changing what provider implementation takes
the place of one of those systems?

I intend to move this to a wiki once
we have one, so that we can improve on it.
Please ask any questions, or provide
any feedback, even if it's "I've no idea what you're talking about"
or "why would anyone ever want to do it like that".



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU