The Build Lackey Labs Provisionator

Overview

The Provisionator automates the installation and setup of the third party
frameworks and utilities needed to build, test, and deploy
today's industrial strength Java applications.

While a JVM and a reasonable text editor were sufficient to
create toy applets in the late 90's, modern Web 2.0 application development
requires a much broader range of tool support: dynamic languages (e.g., Groovy,
Ruby), frameworks such Grails or Rails, build tools such as Ant or Maven,
and test frameworks such as Canoo or Fitness, to name a few.

In addition to the must-haves, all development organizations can benefit
from proactively providing their engineers with third party tools and utilties
that help them code, test, and debug more effectively. Remember the
productivity lift you experienced when you discovered tools
such as WinMerge (or similar diff/merge utilities), the Sysinternals Process Explorer, and XML editors such as Oxygen? How much more effective would
your developers be if they didn't have to discover, then install these
tools on their own ? The Provisionator enables your senior developers
to determine the tool set that should be available to each and every member
of the team, and ensures that these tools will be correctly and
automatically installed as part of a unified provisioning process.

Pain Points Addressed

Setting up a new developer box or contintual integration (CI) server for
a large scale Java app can easily take hours. It can take days if
you are a recently onboarded developer, if the set-up instructions get
stale, or if you miss a step. The obscurity of the resultant
build-time and run-time failures can Drive You Nuts.

Complex manual set up processes can also lead to inconsistencies between
individual developer environments, CI machines, and production
environments. Such inconsistencies can be an irksome source
of hard-to-track bugs.

Summary of Provisionator Benefits

By dramatically reducing the number of manual steps required for setting
up environments you can:

* reduce the ramp-up required for new developers to get productive;

* ensure consistency across developer environments

* make development more pleasant by reducing "monkey work".

* achieve a higher degree of consistency between development and
production configurations with the result that bugs discovered
in production have a better chance of being reproducible in
the development environment. This, in turn, means that developers don't
need to be granted access to production to resolve critical bugs,
and can rely on their standard tools in the course of the resolution
process.

Features

* Operates in either Command-line mode or via a Web Browser Based GUI
(signed java applet)

* Multiple repository and protocol support for storing 3rd party artifacts.

This means that artifacts can be stored on a shared file system,
an HTTP server, or even within a Maven repository.

* "While You Wait" Presentation of Content:

   * As 3rd party artifacts are being downloaded we will be displaying Blog and RSS feed content related to the artifact being fetched.  As an example, if your 3rd party application component set includes Eclipse, then Eclipse related content will be shown.

    * Advertisements will be interleaved with the above content.

       * See the http://buildlackey.com site for a mock-up of a composite widget that cycles between ad and blog/rss content. Widgets such as these will be displaying relevant content as dependencies are being downloaded.

* Multi code branch and multi JVM development support

* As a software product matures the need to support
multiple back versions will likely arise. Different versions
of a given product will likely have different third party
dependencies (at either build time or run-time, or both).

* The Provisionator enables your development staff to
install any number of versioned "configuration sets" of
3rd party components. It provides an easy way to
set your current environment to use the tools and frameworks
that comprise a configuration set at any version level.

As an example of where this would be useful, let's say
your team is responsible for an Eclipse plugin that
allows you to visually construct and debug Ant tasks.

Version 1.0 of your product might have been developed with Java 1.4
and therefore might make use of variable names like 'assert'
or 'enum' that are no longer valid as of Java 1.5. You therefore
need to compile using version 1.4, but you need to test
under all JVM's (and versions of Eclipse) for which your
product is officially supported. Patches of the 1.0 product
need to occasionally be created, tested and released for the
paying customers who choose to be at that version level.

This means that developers working against this branch need
some way (hopefully an easy way) of configuring an environment
with an older 3rd party component set up.

The complexity grows as you consider that the build process for
the latest version of your product may require a newer version of
Ant, while your QA team needs to test against every Ant version
at or above the minimum version officially supported..
This example should illustrate the complexity of setting
up and managing an environment that includes all versions of
the 3rd party components needed to build and test all major releases
of your product line.

Please see this section for technical details as to how versions
are stored and managed by the Provisionator.

TODO -- need link...