Projects overview
From ControlTier
In the ControlTier software, a Project is a named container for all of the service management components you define or build. All management actions occur within the context of a single project.
Each project has the following content:
- A Resource model: the types and resources maintained the Resource Model.
- Space in the File share: Deployable artifacts such as packages and other files stored in the WebDAV
- A history of activity: model revisions and command execution history stored in Ctlcenter
In addition, each ControlTier client that registers as a Node within a Project creates a filesystem workspace, local to that client.
- Clients store Resource data and artifacts retrieved from the server
Multiple projects can be maintained on the same ControlTier server. Projects are independent of one another, so you can use them to organize unrelated systems within a single ControlTier installation. This can be useful for managing each business line's application.
Project boundaries
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 towards the topic 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.
Applications
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.
Environments
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.
| ||||||||||||||
