InRelease components - How does it work?
|
InRelease is developed using the latest Microsoft technologies with a service oriented architecture. The product is also integrated with Visual Studio Team foundation Server 2010, Microsoft’s latest application lifecycle management solution.
|
Architecture Overview
The basic goal of InRelease’s architecture is to provide a mechanism where application components can be deployed automatically to various target servers in different environments. The components may require different configurations on the various servers but we still want to deploy the same package to all of them. Another key goal is to keep all the configuration information centralized and manage the deployments as part of a business driven release workflow that involves multiple roles in the organization.
|
In order to accomplish these goals, InRelease is based on four main components.
|
InRelease Server. The server component is the heart of the solution and consists of the database, the workflow controller, and a dispatcher that synchronizes activities with the target servers.
InRelease Client. The client comes in two flavors, a Windows Presentation Foundation (WPF) based client that exposes all the functionalities of the application and an upcoming web-client designed for testers, user acceptance approvers and managers.
InRelease Deployer. The deployer is a service that is installed on the target servers where the application components need to be deployed.
Deployer Tools. The InRelease solution provides various installation tools that assist different deployment scenarios such as:
- Installing a version of a component to a specific environment
- Uninstalling previous version of a component before a re-deployment
- Deploying reports to Microsoft SQL Reporting Services
- Moving files to specific locations.
|
|
Note that custom tools can be added as Deployer Tools. InRelease uses
an open and extendable model that enables you to integrate any type of
tool that can be executed as a process.
|
Basic interactions
The basic mechanism used in InRelease is to have the users interact with the server through the appropriate client where new release requests or stage approvals will trigger deployment requests to the next stage in the release path. The paths are composed on the various servers grouped in environments on which the testing for the stage is performed. Once an application needs to be deployed to a new environment, the server will queue deployment requests to all the required target servers for each component of the application. This allows an atomic deployment of all the components.
The InRelease Deployer running on each target server monitors the InRelease server continually (at a configurable interval) and will pick the installation requests for the one or many components it needs to install locally. The deployer will then find the release package, provided by the InRelease Server that calculates the location using the TFS API - if built by TFS - or using a predefined UNC path - if not. The Deployer then downloads the package locally and performs the installation using the appropriate command defined for each component. The Deployer also downloads any additional executable (batch file, PowerShell script, .exe) to be ran prior to or after the installation as configured by the user. These are additional deployment activities beyond the installation itself; creating test data or triggering automated tests are common scenarios here.
It is important to note that the Deployer requires access to the InRelease Server but the Release Server does NOT require access to the target servers, all operations are based on a pull mechanism from the Deployer to the Server, mitigating many security requirements and concerns.
|
Variables Mechanism
Another key mechanism is how to apply the right configuration when deploying to a given server. As stated in our goals, InRelease always uses the same package on all environments and the configuration information is kept centrally in the database where it can be managed through the interface instead of being burried in brittle scripts. When preparing an application for InRelease, developers replace the configuration values in the configuration files of their application with a variable name. The variable along with the value to use on each target server is configured centrally in InRelease. At release time, InRelease will inspect the configuration files and command lines and look for variables and replaces them with the appropriate value specified for that server.
|
InRelease Team Build Action
Releases in InRelase can be triggered automatically as part of a Team Build operation by including an InRelease build action - provided with InRelease - in the build definition of the application.
|
| More about TFS integration> |