User story

• Software can support many platforms. Building this software can require maintaining lots of build machines, for each platform and for parallel builds.
• Maintaining these machines can take a lot of effort.
• Such a cloud will usually be replacing one or more static build machines, so there will be an existing process for build requests to be submitted. (OSLC should hopefully allow a seamless transition to using the cloud for the end users).

Perspectives:

1. • As a software engineer
   • I want to build my software continuously, on a wide range of platforms
   • In order to get quick feedback across the wide range of supported platforms
2. • As operations (maintaining the build infrastructure)
   • I want to avoid setting up and maintaining many static machines
   • To provide a more consistent and reliable service, and to reduce costs

Usual problems/costs:

• Lead time to get a new machine
• Manual setup for new machines
• Maintenance overhead
• Under-utilized hardware
• Fixed machine specification

Solution: cloud-enabled build (and test) capability, with dynamic provisioning of build engines.

Benefits:

• Reduced maintenance costs
• Higher utilisation of hardware
• Cheaper to grow capacity

Use case

Actors: Submitter (may be human or automated process); Elastic Build Cloud Manager (EBC Manager); Cloud provider; Deployment provider (may be same as Cloud provider, or as EBC Manager itself); Build engine. There may also be a component between the submitter and the EBC Manager that stores and tracks build requests.

1. Build request submitted (may be a manual request, may be on a trigger e.g. code check-in), containing details of platform(s) and build required.
2. Elastic Build Cloud (EBC) Manager submits request to cloud provider to provision a cloud instance for the build engine.
3. EBC Manager submits requires to deployment systems to deploy build engine (plus any dependencies defined by the build and platform definitions) onto that cloud instance.
4. Build engine picks up the original submitter's build request (either from EBC Manager or from the original build request submission), and performs the build.
5. Submitter is notified when the build completes.
6. Cloud instance is torn down.

Variation:

• The EBC manager could find an existing cloud instance that matches the required platform and build definition, and re-use that. If it does this, then step 6 (tear down) may not be performed, so the cloud instance may remain around for later re-use.

Diagram

Implementation in Automation 2.1

There are a number of integration points:

1. Submitter to EBC Manager
2. EBC Manager to Cloud provider
3. EBC Manager to Deployment provider
4. ? to Build engine (could be with EBC Manager, or with the build request system, if separate from the EBC manager).

Most, if not all, of these would be possible to implement with Automation v2.

The main questions that this use case raises are:

1. How does the Deployment provider know where to deploy the build engine to? (Chaining output from cloud instance provisioning to deployment provider plan.)
2. The build engine does not exist most of the time. How does this affect the configuration of the integrations?