Projects

In ControlTier, all build and deployment activity occurs within the context of a project. A project consists of various artifacts and data.

• Release Artifacts: deployable package archives
• Model Artifacts: types and objects
• Activity Data: model revisions and command execution history

Multiple projects can be maintained on the same hosts. This can be handy for creating separate projects for each business line's application.

A project can be likened to be like both a repository of artifacts and an information database. As a repository, a project houses all the packages that have been loaded during the build process and distributed during the deployment process. When a package is loaded into the repository, a physical file is added but also key data is recorded describing its type, version, install directory, etc. This data describing the packages is also part of the project and it is in this light that one can see a project as an information database. Packages are not the only kind of data in a project. The base library establishes the fundamental data model of the project. You of course, can add your own types by extending the ones in the base library.

Object-oriented Model

The base library of the ControlTier framework uses an object-oriented paradigm to both describe the structure of an application (i.e, topology of components), as well as define process (i.e., command structure). The model is defined in terms of types and objects:

• A type defines the characteristics of an object via attributes and constraints (c.f., member data and roles) while a type's commands define the things it can do (c.f., methods). A type can be relatively self contained, and include internal resources such as file templates, library dependencies, utilties, etc. This collection of type definitions and resources are packaged into an artifact called a module.
• An object is a particular instance of class. An object inherits the characteristics defined by its type but can override them with values unique to itself. Objects collaborate by calling commands on each other. Objects only collaborate with those that the constraints of the type definition allow.

Given that all activity occurs within the context of a project, how big or small should a project be? Should there be just one project to manage all applications in all environments? Should there be one project on a per application per environment basis? These questions go to that of project scoping.

While there is no one size fits all strategy here, one strategy that works most of the time is to use one project to manage one application for all its environments. But before we keep throwing around terms like "application" and "environment" a simple example will help make these ideas more concrete.

The figure below describes a trivial three tier application comprised of a web tier that handles user requests, dispatching them to an application tier. The role of the application tier is to execute business logic and provide an abstraction layer over the database tier. The database contains standing data and application state.

The diagram shows a standard arrangement of components that when configured correctly comprise an application. Of course, these components do not run in isolation but are deployed to one or more physical hosts. During the course of the application life cycle, these components are deployed to different sets of machines, each set representing an environment.

The diagram below shows three environments, dev, qa and production, and indicates differences on how the application components are distributed to the number of machines each environment supports. In dev, all components are installed on one node while in production, each component is located on its own host.

From the point of view of the application components, these hosts may look like resources that are exclusively theirs, but in actuality, hosts might be shared between environments. The next diagram shows dev and qa share a pool of hardware while production has its own pool.

A project's types capture the standard structure of the application (i.e., it is always an arrangement of Webs, Apps and RDBs) while a project's objects capture the environment specific arrangements (e.g., in dev Web, App and RDB are on one host versus qa where Web and App are on one host and RDB is on its own).

With an idea on how to organize applications into projects, the next step is to actually implement the framework, and populate a project with artifacts.

ProjectBuilder is a module that comes from the base library. ProjectBuilder is a "Builder" used to develop and build types, type libraries and define and load objects. In other words, its role is to help you populate a project with model artifacts.

ProjectBuilder supports a typical edit, build, test methodology familiar to most developers wherein, a set of source files maintained in a source code repository are developed using familiar text editing tools, and ProjectBuilder builds and deploys them, so that the results can be tested.

The diagram below shows ProjectBuilder in the context of an SCM repository and the ControlTier server. By issuing the Build command to the ProjectBuilder object, a developer drives the project build life cycle: sources for model artifacts are checked out of the SCM, they are compiled, packaged and uploaded to the server, and finally are deployed to a working context where the artifacts can be used.

ProjectBuilder is designed to support iterative development, where there are cycles of revision to the types and object model of the project.

Since type development dominates the project development process, you will become most familiar with ProjectBuilder's build-type command. This command reads an XML file that contains the type definition and processes it into a set of files usable by the ControlTier framework.

• ProjectBuilder reference