Modeling Methodology

From ControlTier

This page describes a methodology on how to integrate your build and deploy processes into the ControlTier framework.

You have a multi-component application that could benefit from ControlTier's automation platform but you are unsure how to get started. After all, your application is unique and so are some of its procedures to build and deploy it.

This document provides a general description of a methodology successfully used to implement various customer projects, both large and small. The scope of this methodology covers all the activities needed to automate an end-to-end build and deployment process using the ControlTier base automation library. This document is not a tutorial but a general plan.

The activities of this methodology will address questions like:

1. What is covered by the base automation framework ?
2. How to tie in a packaging process ?
3. How to tie in a build process ?
4. How to tie in a deployment process ?
5. How the two above steps are coordinated for an end-to-end process ?
6. How to operationalize these processes for admin staff ?

In the end, treat this methodology as a collection of rules of thumb for a successful use of ControlTier but feel free to bend it to best fit your organization and application needs.

General approach: divide and conquer

While it's a somewhat simple job to automate a build process or deploy process for a single application component, creating a coordinated automation process that manages these steps for multiple and diverse application components is quite another! Of course, the result should be a set of automation processes that are simple (so a less technical person can run them) yet flexible (so they can be re-factored safely over time). The very thought of these considerations is no doubt quite overwhelming. In order to tackle the problem, we use a "divide and conquer" strategy.

The divide and conquer strategy breaks the process into several rough parts, each part responsible for a particular phase or role in the overall process. Dividing the work into several parts will confine each sub process to few and simpler tasks and avoid overly complex logic and information.

The figure below organizes these divided sub-processes into two layers: high and low levels.

Low-level processes like "build", "package" and "deployment" boil down to simple steps like invoking a build script, creating and extracting a package, or restarting a system service. While high-level processes are only concerned about how to coordinate low-level processes.

We consider low-level processes to be "physical" since they correspond to concrete actions that occur on a machine against something like a system process or a package file. These are things you can see. The high-level processes are considered to be "logical" since they are really about some thing that coordinates activity and just corresponds to the process itself.

The methodology discussed here uses the process structure illustrated in the diagram above.

Package-centric paradigm

It's important for any methodology to be grounded by something tangible, a basic concept which will help direct its users to reach a certain end. This methodology is grounded by the package concept, and it is the goal of this methodology to understand how to produce and deploy packages. A package plays the role of pivot point in the end-to-end build and deployment process. By understanding the needs to create and install a package, you are half way to understanding how to integrate the build and deployment process.

While packages come in all sizes and formats, can contain data, content, code or configuration, they are concrete things and are the common currency in the build and deployment world. Packages are interchanged between teams across the organization as well as the phases of the end to end process.

Modeling the process with ControlTier objects

Part of the usefulness of the ControlTier framework lies in its base automation library. This library contains a set of object-oriented modules that reflect the "divide and conquer" strategy discussed above and embodies each step in the process as a command contained in a base type. These objects are designed to work together, enabling the end-to-end coordinated build and deployment process.

The diagram above shows five ControlTier objects — Builder, Package, Service, Site, Updater — each object corresponding to a particular part of the overall process. The solid blue arrows in the diagram show how objects interact with each other via standard command interfaces while the red text and arrows show what part of the process the object's type implements.

One puts the base library to work through tying your "physical" processes to Builder, Package and Service resources. While one uses Updater and Site objects to coordinate the end-to-end process. How one ties their existing process to the base framework depends on their particular requirements and availability of concrete types. For example, to tie an control-dispatching build process, one can use the Builder subtype, AntBuilder (or MavenBuilder for a Maven build process). Alternatively, one can use the Service subtype, JakartaTomcat, to manage WAR package deployments for Tomcat instances.

If one needs to expose a particular build and deploy process not covered by an available type, one creates their own sub-types. Subtyping is simple and subtypes still leverage quite a bit of the functionality from base type framework.

Framework driven control

The ControlTier base library controls the flow of execution using an inversion of control model. Each base object executes a process step through a standard command. These commands can be called in a sequence via a workflow command, thereby defining a higher level process. The base types establish the overall process structure using a hierarchy of well known workflow commands. The diagram below shows a partial view into this workflow command hierarchy:

The blue boxes are standard workflow commands that either call commands internal to that object, or another standard workflow command offered by an object of another type.

Design pattern for workflow commands

All the standard workflow commands employ a software design pattern called Template method wherein the template method defines a program skeleton that establishes the steps of a process, allowing sub types to override individual steps in order to establish specialized behavior. Therefore, the commands you override in subtypes are called by the standard workflows defined in base types.

All the essential build and deployment processes are embodied in standard workflow commands and follow the template method design pattern. The diagram below shows the general pattern and an example showing Builder's Build workflow command. In this example, Build is the standard workflow that calls subordinate commands (scmCheckout, runBuildscript, repoImport) that can be overridden by subtypes. The AntBuilder subtype overrides just the runBuildscript command so when Build is run on a AntBuilder object, the standard Build workflow inherited by the base type is used but the overridden command is used instead of the generic one.

Design Pattern	Example

General rules of thumb

It is important to keep perspective on how to go about the work which will result in a working and successful ControlTier solution. There are several rules of thumb that will help keep one on the right track:

Divide and conquer

Any time you face a long and/or complicated process it's easy to get overwhelmed and confused. The name of the game is dividing the work into logical parts and work on each one. Luckily, the ControlTier base types guide how to break a build and deployment process down so often times one just asks to which base type does a sub-process correspond. There are more primitive base types than the ones described here so consult the Core Type Guide.

Start with low-level procedures, then work up to the high-level ones

The end-to-end build and deploy process covers a lot of ground. What is the best order of work to get the job done? We have found time and again it is always best to start with the build, then deploy, then the coordinated deploy and finally the coordinated build and deploy. In fact, the activities of this methodology are organized around this order of work.

Try to avoid custom sub-typing

ControlTier's Workbench and ProjectBuilder make it easy to create your own types and there are times when this is preferable or necessary. On the other hand, you can get the final automated process working quicker by leveraging existing core types and type libraries found on ModuleForge. You may also have a fellow ControlTier user in your organization that has pertinent functionality already in a custom type. Code re-use means code avoidance, and less maintenance burden overall!

Establish namespace and naming convention

ControlTier gives you a lot of freedom on how you name your types and objects. That said, it pays dividends to give some thought to a standard way of naming your types and objects. We have found it is best to use a common prefix for all locally developed subtypes (e.g., PfxTypename). This creates a type namespace and makes it easy to visually distinguish your types from those from other sources. Objects also benefit from a regular naming scheme. Sites and Service resources can be visually associated with each other by using an environment name and optionally hostname. (e.g., environment or environment-hostname). Package resources typically follow a pattern where names are a concatenation of three bits of package metadata (e.g., base-version.extension).

Module development using Workbench or ProjectBuilder? GUI vs. CLI

There are two ControlTier module development tools: Workbench and ProjectBuilder. Either can be used to define types and objects, and maintain a project. Given this choice, which one should you use? If you hate graphical interfaces and are comfortable within a shell environment, then the default choice is ProjectBuilder. That said, there is a lot of merit in choosing Workbench, if you are a brand new user. Workbench includes a class browser and nice features for moving around and editing your object model. Once you have sketched out an initial process with Workbench you can always switch to ProjectBuilder to maintain the type and resource definitions. With care, you can even switch back and forth between tools. If there is more than one user doing the module development and you do choose to use both tools, you will need to create a change process to ensure changes are not lost when switching between the tools.

Methodology Activities

So what are the general steps to finishing a complete ControlTier implementation and how do you know you have covered all the essentials? To address these concerns, this methodology is made up of four activities which culminate in an operational application service build and deployment process:

As the diagram indicates, you are done when you have exposed your process as a job in Job Center.

Below are links to the individual activities if you want to skip directly to one:

1. integrate package process Activity #1
2. integrate build process Activity #2
3. integrate deployment process Activity #3
4. configure coordinated processes Activity #4
5. define and run jobs Activity #5

The goal of each activity is a working executable process that can be performed by a release administrator. This keeps the methodology grounded in achieving practical results.

v • d • e Modeler Guide Introduction Modeler Guide · Concepts · Modeler Getting started · Model-driven approach · CTL architecture · Model-driven command dispatching · File share Resource modeling Resource Model · Graphical resource editor · Graphical type editor · ProjectBuilder · Core Type Guide  · Type modeling · Attributes · Constraints Module development Module Development Guide · Modules · First type module · Workflow command · Command options Examples Creating packages · Mock Unix Service Example  · Mock Site Example  · Service Package Deployment Example  · Windows service  · Windows site  · Windows deployment · Builder Simple Example  · Continuous Deployment Example with Tomcat · Dukes Bank J2EE examples