The model-driven approach is one where the ControlTier model as defined by its types drives the execution of the management process. This is in contrast to the script-driven approach. Underlying this approach is Model-driven command dispatching.
To manage the life cycle of a business service component via ControlTier, there are several general kinds of tasks you perform to configure and customize your ControlTier deployment:
- Service definition: declaring a resource model describing the business service components as Services, importing necessary packaged artifacts for the deployment cycle, making Node assignments to declare where the Services will run and how you group them for simplified control. Each of these are defined in types. See Core Type Guide.
- Integration: attaching scripts and actions that manage the physical long running process to the Service life cycle workflows, creating configuration templates and supporting Settings
- Extending ControlTier: developing new service and artifact types, commands and workflows and other modules used by ControlTier
This page provides a high-level overview of the steps you take to perform these tasks. For a more in depth explanation and a structured method to automate your release and service management processes see the Methodology and Methodology Activities pages.
If you like to learn by getting your hands dirty then see the Examples.
Acquaint yourself with CTL and command dispatching. CTL is the heart of the ControlTier system providing the command dispatching capabilities that let you execute command and control actions in a distributed environment. Everything else in the ControlTier system builds on or enhances CTL.
Configure a Builder
If you are deploying packages that are produced from local builds then learn about ControlTier Builders that interface with your build process and then set up a Builder to import those packages to the repository for later deployment to a Service.
Manage Deployment Cycle
A Service represents a software deployment that is also a long running process and has runtime state. You can wrap the management of that application deployment by first registering it as a Service (so it is visible in the resource model). Once it's registered you can manage it via defined commands.
After you have uploaded your Packages and registered your Service you can manage package deployments to it. See the Deploying Packages to a Service page to learn how to define Package dependencies for your Service and then use the "Deploy" workflow command to manage the deployment cycle.
Integrate startup cycle scripts
Services are long running process that have runtime state managed via startup and shutdown procedures. You already have scripts and commands to manage those procedures. You can plug those scripts into the Service's hook commands. See: Screencast: Configuring a Service with your start and stop scripts
Beyond managing the package installation life cycle, the Service can also coordinate application configuration. Service's "Configure" workflow command governs the configuration step inside the "Deploy" workflow. You can generate customized configuration files based on environment specific information and a set of template files. See Generating Configuration Files.
Set up a Site
A "Site" lets you group a set of Services and then lets you control the group as a single object as a simple command. Sites can be nested, too, and become very useful as a representation of your business service as an integrated software system. See the Working with Sites section in the User Manual for more.
Jobcenter provides a centralized graphical console to running service management commands. You can define two kinds of jobs:
- jobs that can be run any time
- jobs that run a scheduled periodic basis
See the Using Jobcenter section in the User Guide.
Setup project build
While you can use the Workbench graphical interface to register Nodes, upload Packages and define Services, it is often much more preferable to maintain the Project Content using a set of text files maintained in an SCM repository and a build tool to process them and update the ControlTier server. See the "Use ProjectBuilder" page for information on how to setup ProjectBuilder to support building your project artifacts.
Define new Types
ControlTier's solution library contains dozens of types that provide the generic life cycle workflow commands to support managing your business service, as well as, specialized types for specific targets. ControlTier was first and foremost designed to be extensible via sub-typing.
You can introduce the management of a new Service using information here: Create your own Service type You might also want to package your control scripts inside a custom subtype to benefit from ControlTier's module distribution mechanism (See: Use custom control scripts with a Service sub-type).
Add and override commands
While ControlTier's generic types establish workflow command structures to manage the service management life cycles sometimes you need to customize these either by defining new steps or overriding existing ones.
Define Attributes and Constraints
ControlTier uses a sophisticated object-oriented model to describe your business service and its environment. ControlTier uses a class based Type system to allow you to create a data model to represent the various components of your Business Service. Read the Type modeling page to learn more.
You might also want to introduce new Attributes to capture configuration settings and use them for driving your commands and/or generate configuration files.
An important aspect of the ControlTier model schema are constraints. Constraints let you define rules that govern how instances are created and edited. You can also use constraints to govern how Objects are composed together into your model. See the Constraints page for more.