Glossary of Terms

Approval

A Pre-Approval enables a verification moment before delivering a Level Request to a Test or Production Level. It adds an extra condition to the execution of the Level Request: not only the Requested Date/Time must be expired, but the Pre-Approval must also be granted by an IKAN ALM User. As long as both conditions are not fulfilled, the Level Request will not be handled. When a Pre-Approval is rejected, the Level Request will never be handled.

A Post-Approval enables a verification moment after the execution of the Level Request on a Test or Production Level. It adds an extra condition to the determination of the end status of a Level Request: not only must all Build(s) or Deploy(s) have been ended successfully, but the Post-Approval must also be granted by an IKAN ALM User. As long as the Post-Approval is not handled, the Level Request status will not be set to warning or success. When a Post-Approval is rejected, the Level Request can never be delivered to the next Level in the Lifecycle.

Auditing a Project

After having created a new Project, that Project is locked. Auditing the Project will perform a certain number of checks and if all checks succeed the Project will be unlocked and ready to be used.

Branch Project Stream

A Branch Project Stream is a development Stream in the Project different from the Head (also referred to as main or trunk) Project Stream. It maps to the sources controlled in a Branch of the VCR. A Branch Project Stream is typically used for Releases, parallel development, patches or other ALM practices to support development next to the main development line. Just as a Head Project Stream, the Branch Project Stream must be linked to a Lifecycle in order to be active (Builds and Deploys).

Build

A Build is an action on a Build Environment which involves several sub processes, called Build Phases. It is always part of a Level Request, which may also contain other Builds or Deploys. [A Build is handled by the IKAN ALM Builder]. It starts from sources that were retrieved from the VCR to the Build Environment. A Build script is executed on those sources by a Scripting Tool and gives a Build Result that is transferred to the Build Archive.

Build Archive

The physical location (path) on the IKAN ALM Server where the Build Results are stored in a compressed and archived format (*.zip or *.tar.gz). The Build Results are organized by Project and by Project Stream.

Build Environment

A physical environment on a Machine where sources retrieved from the VCR may be transformed by a Build script executed by a Scripting Tool. A Build Environment is always part of a Level.

Build History

The Build History provides a historical overview of the Build Level Requests for a specific Lifecycle of a Project Stream. It allows you to verify the flow of a certain Build in the Lifecycle: was it ever delivered to a Level higher in the Lifecycle then the first Build Level? If yes, did it reach the highest Level (e.g., Production)?

Build Number

Each Build on the Build Level in a Project Stream has a unique Build Number. This is a sequential number that is incremented by IKAN ALM when a Build Level Request is created. The highest Build Number is stored on the Project Stream.

Build OID

The Build OID is the unique identifier of a Build used to store the build information in the database.

Build Parameter

Build Parameters are parameters that can be used during the execution of the Build Script. They are defined on a Build Environment, and can have a predefined value or be modified during the creation of a Level Request.

Build Phase

A Build Phase is a sub process that must be performed to complete a Build action. Different Build Phases form the workflow of a Build and are inserted into a Build Environment. They are executed by the IKAN ALM Builder Thread of the IKAN ALM Agent. A Build Phase may be a Core Phase (e.g., Verify Build Script), or a Custom Build Phase created or imported by the User in the Phase Catalog.

Build Prefix/Suffix

A series of numbers or a character set to uniquely differentiate a Project Stream in the Project, also referred to as a “Release Number”. Samples: 4.2, or Head, or 1-0. A Head Project Stream is only be identified by a Build Prefix. A Branch Project Stream will combine the Build Prefix and Suffix to obtain its release number.

Build Tool

Scripting Tool installed on a Build Environment

Continuous Build Level

A Build Level for which a Schedule has been defined verifying the latest sources in the VCR after a specified number of minutes (e.g., every 5 or 10 minutes). If the code has changed in the VCR, the Scheduler will notify the changes after the defined interval and a Level Request will be generated automatically.

Core Phase

Core Phases form the IKAN ALM “Core” functionality. They can only be viewed, and can be neither altered nor deleted. Consider them an integral part of IKAN ALM. When a new Level, Build or Deploy Environment is created, its default workflow will be created and will completely consist of a sequence of Core Phases. This default workflow may be changed by removing Core Phases, by changing the sequence order, or by adding Custom Phases.

Custom Phase

A Phase added by the User is also called a “Custom” Phase. It may be created from scratch in Global Administration based on one or more working scripts and resources, or it may be imported, using the “Import Phase” functionality. Once defined in Global Administration, a Custom Phase may be inserted into (and consequently change) the default work flow of a Level, Build or Deploy Environment. All Custom Phases are stored in the Phase Catalog on the IKAN ALM Server, and are transported automatically to the IKAN ALM Server (Level Phase) or IKAN ALM Agent (Build or Deploy Phase) when they are to be executed.

Deliver [Level Request]

A manually (via the Command Line or web interface) created Level Request to deliver sources or a Build Result to the next higher Test or Production Level in the Lifecycle of a Project Stream. The Level Request may contain Build(s) and/or Deploy(s).

Dependency

Dependencies are defined on Project Streams. This functionality makes it possible to reuse common libraries or sources from Child Projects Streams The project that reuses the common library is called a Parent Project Stream. Projects can be reused in two ways: as sources retrieved from the Versioning System or as a Build result retrieved from the Build Archive.

Deploy

A Deploy is an action on a Deploy Environment which involves several sub processes, called Deploy Phases. It is always part of a Level Request, which may also contain (an)other Build(s) or Deploy(s). [A Deploy is handled by the IKAN ALM Deployer]. It starts from a Build Result which is retrieved from the Build Archive. A Deploy script is executed on this Build Result by a Scripting Tool.

Deploy Parameter

Deploy Parameters are parameters that can be used during the execution of the Deploy Script They are defined on a Deploy Environment, and can have a fixed value or be modified during the creation of a Level Request.

Deploy Phase

A Deploy Phase is a sub process that must be performed to complete a Deploy action. Different Deploy Phases form the workflow of a Deploy and are inserted into a Deploy Environment. They are executed by the IKAN ALM Deployer Thread of the IKAN ALM Agent. A Deploy Phase may be a Core Phase (e.g., Transport Build Result) or a Custom Deploy Phase created or imported by the User in the Phase Catalog.

Deploy Tool

A scripting Tool installed on a Deploy Environment

Deploy Environment

A physical environment on a Machine where a Build result retrieved from the Build Archive on the IKAN ALM Server may be deployed by a Deploy script executed by a Scripting Tool. A Deploy Environment is always part of a Level.

Desktop

The Desktop lists current information about selected Project Streams and Levels. Users can personalize their Desktop adding the items they are interested in. Furthermore the personal Desktop provides shortcuts for creating Level Requests.

Environment Parameter

Environment Parameters are parameters that can be used during the Execute Script Phase which runs a Build/Deploy Script. They may also be used during the execution of a Custom Phase.

Environment Phase Parameter

Phases may have their own Phase Parameters. Once a Phase is linked to an Environment, specific values can be specified for these Phase Parameters, which are then referred to as Environment Phase Parameters.

Forced Build [Level Request]

If a Continuous Build Process has been defined for the Build Level by means of a Schedule and this Schedule is bypassed by generating a Build [Level Request] manually via the web interface or Command Line, this action is called a “Forced Build [Level Request]”. The Level Request must at least contain one Build and may contain one or several Deploys.

Head Project Stream

A Stream in the Project mapped to the main development line (referred to as main, head or trunk) of the VCR. A Head Project Stream is typically used for the ongoing development of the next Release. Just as a Branch Stream, the Head Stream must be linked to a Lifecycle in order to be active (Builds and Deploys).

IKAN ALM Agent

A process (daemon) running on a Machine with sub processes to handle Build or Deploys. An Agent running on the same Machine as the IKAN ALM Server is also referred to as “local”, whereas running on a different Machine it is indicated as “remote”. During a Build or Deploy the IKAN ALM Agent interacts remotely with the IKAN ALM Monitor, and locally with a Transporter and with a Scripting Tool that must be correctly configured on the Machine.

IKAN ALM Server

The Machine hosting the IKAN ALM web application and the IKAN ALM Monitor and Scheduler processes.

IKAN ALM Monitor

A process (daemon) running on the IKAN ALM Server to handle Level Requests. During the proceeding of a Level Requests it interacts with a VCR client installed on the IKAN ALM Server and with a local or remote IKAN ALM Agent.

IKAN ALM Scheduler

A process (daemon) running on the IKAN ALM Server. In case a Schedule (= a predefined interval, e.g., each 5 or 10 minutes, each night or each week, .) is linked to a Build Level, the IKAN ALM Scheduler will verify, in the Version Control Repository, whether changes have been made to the sources in the VCR each time the Schedule interval expires. This enables Continuous Integration or Nightly Builds.

IKAN ALM Builder

A sub process (daemon) of the IKAN ALM Agent that will handle the Builds of a Level Request in the Build Environment on an Agent Machine.

IKAN ALM Deployer

A sub process (daemon) of the IKAN ALM Agent that will handle the Deploys of a Level Request in the Deploy Environment on an Agent Machine.

Issue Tracking

A system external to IKAN ALM, where Issues (defects, enhancements, tasks, .) may be defined for a Project. Samples are Atlassian JIRA, MicroFocus ALM, GitHub, Microsoft Team Foundation Server, Collabnet TeamForge, Bugzilla or Trac. IKAN ALM can plug in to such a System and keep up with the Issues that were handled for a Level Request.

The integration with JIRA, Microfocus ALM, GitHub and Microsoft TFS is more advanced: Issues are automatically synchronized through the Lifecycle, and it is possible to keep a link with the Level Requests in the JIRA Issue, MF ALM Defect, GitHub Issue or TFS Issue.

Level

A Level is a stage in the Lifecycle, a conceptual step in the process of promoting sources and build results from development to production. A Level is linked in a specific order to a Lifecycle. A Level must contain at least one (physical) Build and/or Deploy Environment in order to be active. It may have more than one Build and/or Deploy Environments to support parallel Builds or Deploys on multiple Machines.

Level Phase

A Level Phase is a sub process that must be performed to complete a Level Request. The execution of a Level Request is split up in Level Phases which will be executed sequentially. Different Level Phases form the workflow of a Level Request and are inserted into a Level. They are executed by the IKAN ALM Monitor Thread of the IKAN ALM Server. A Level Phase may be a Core Phase (e.g., Retrieve Code) or a Custom Level Phase created or imported by the User in the Phase Catalog.

Level Request

A Level Request is an action on a Level which involves several sub processes, called Level Phases. In most cases, a Level Request will contain at least one Build or Deploy action, which will be executed on local or remote Machines. A Level Request may be created manually by the user via the Web interface or the Command Line interface, or automatically by the Scheduler Thread of the IKAN ALM Server. A Level Request is handled by the Monitor Thread of the IKAN ALM Server.

Lifecycle

Machine

A representation of a concrete Server. Builds and Deploys may be done on a Machine, when it is linked to a Build respectively Deploy Environment. Other conditions are that the IKAN ALM Agent is installed and running on the Machine, and that a Scripting Tool is installed on the Machine. The IKAN ALM Server is a special Machine, containing the web application and the running IKAN ALM Monitor and Scheduler Threads.

Machine Parameter

Machine Parameters are defined for a Machine instead of for a specific Environment. Parameters defined for a specific Machine, will automatically be available for all Environments using that Machine. This avoids having to (re)define Build and/or Deploy Parameters for each Environment linked to that Machine.

If an Environment Parameter and a Machine Parameter have the same name, the Environment Parameter takes precedence.

Notification

A message to a User defined in IKAN ALM via mail. Notifications may be sent when a Level Request fails or succeeds, when an Approval must be granted for a Level Request, when an Approval for a Level is rejected, when a Level Request is delivered to or from a certain Level, when the IKAN ALM Administrator wants to notify certain Users.

OID (Level Request OID / Build OID / Deploy OID /Level Approval OID)

Object Identifier. Unique number to identify a Level Request/ Build / Deploy / Level Approval from other Level Requests/ Builds / Deploys / Level Approvals

Package

A Package allows moving one or more individual files selected manually from a VCR Stream (Head or Branch) through the IKAN ALM Lifecycle. One or multiple Packages may be created in each Project Stream of a Package-based Project. This is different from the original way of working in the Project Streams of Release-based projects, where a configurable automated process defines which file revisions are retrieved from the head (trunk) or branch of the versioning system and moved in the Lifecycle.

Phase Catalog

The physical location (path) on the IKAN ALM Server where the Custom Phases (created from scratch or imported) are stored in an archived format (Phase.name-Phase.version.jar, e.g., com.ikanalm.echoproperties-1.0.0.jar). When an IKAN ALM Server or Agent needs to install a missing Custom Phase, it will be retrieved from that location. That will be done using the Transporter linked to the Server or Agent Machine.

An IKAN ALM Project maps to a project or subproject in a versioning system (VCR) which bundles related sources. An IKAN ALM Project is a shell for one or more Project Streams in which the real actions (Level Requests, Builds, Deploys) are done. It is possible to set up dependencies between different Projects, also through the Project Streams.

There are 2 types of Projects:

* Release-based Projects: IKAN ALM will work with the existing structure in the VCR system, so that the objects to be extracted will be retrieved automatically when starting the build process. * Package-based Projects: this concept enables to work with isolated files from the VCR system. Objects must be selected manually in a Package structure created in IKAN ALM before starting the Build process.

Project Stream

The Project Stream concept enables to control different active Lifecycles within an IKAN ALM Project. In general, all Projects have a main Project Stream called “Head”, in which development for the next upcoming release happens. In addition to this there will probably be one or more Branch Project Streams. A Branch Project Stream can be used for maintaining Project releases which are currently in Production, so that fixes can be rolled out automatically or urgent fixes can be promoted along a shorter (and faster) Lifecycle to production. A Branch Project Stream may also be used to allow parallel development, or to test upcoming Test and Production environments with different settings (new operating system, new compiler or database version, …​).

Project Stream Dependency

Project Streams can have dependencies on one another.

A Child Project Stream is a Project Stream whose sources or Build Result are used to create Builds in one (or more) Parent Project Streams. The Parent Project Stream has then a dependency link to the sources, or the Build Result of the Child Project Stream.

The Parent Project Stream is a Project Stream to which a Dependency (a Child Project Stream) is added. Builds in the Parent Project Stream may use the sources or Build Result (e.g., a common library) from the Child Project Stream.

Example: a child project stream may contain a common library that is used in several Parent Project Streams.

Requested Build [Level Request$

A manually (via the Command Line or the web interface) created Level Request on a Build Level that has no Schedule linked to it. The Level Request must contain at least one Build and may contain (a) Deploy(s).

Rollback [Level Request]

A manually (via the Command line or web interface) created Level Requests to reset previously Delivered sources or Build results on a Test or Production Level in the Lifecycle of a Project Stream. The Level Request may contain Build(s) and/or Deploy(s)

Scripting Tool

A system external to IKAN ALM which can execute user-created scripts and which is installed on a Machine. IKAN ALM integrates with Ant, Gradle, NAnt and Maven2. When the Scripting Tool is linked to a Build respectively Deploy Environment it is also referred to as a Build respectively Deploy Tool. The script for executing a Build or Deploy must be stored in the VCR (together with the sources) or in the Script Location on the IKAN ALM Server.

Tag-based Build

A tag-based Build will be executed on sources with a pre-applied tag (manually by a user) in the VCR, whereas a non-Tag-Based Build will be executed on the latest sources, also called the “tip”, of a branch or head (trunk/main) stream from the VCR.

Transporter

A Transporter is used for transporting files and directories between the IKAN ALM server and a local or remote Agent handling the Build or Deploy processes. Therefore, a Transporter must be defined for a specific Machine that is linked to the Build or Deploy Environment. IKAN ALM supports the local FileCopy, remote FileCopy, SecureCopy and FTP Transporters. A Transporter may transport checked-out sources from the Versioning System, a Build result from the Build Archive, but also Custom Phases from the Phase Catalog.

User

A person that may log on to IKAN ALM. The membership to User Groups determines his or her "`Access Rights, i.e., what actions (Global or Project administration, creation of Level Request, verification of Projects, …​) a User can do in IKAN ALM. Users are not created manually in IKAN ALM, but in an external security system (like LDAP or Active Directory). If the User belongs to the correct User Group in this security system, he or she may log on to IKAN ALM and will be created automatically.

User Group

An entity grouping Users with the same “Access Rights”. Actions in IKAN ALM (Global or Project administration, creation of Level Request, verification of Projects, …​) are protected by a User Group. User Groups must be created in IKAN ALM. There are two types of User Groups: external and internal. The membership of Users to an external User Group is set in the external Security System. Each time a User logs on to IKAN ALM, his or her memberships to the different User Groups will be synchronized with the external security system. Internal User Groups, however, are not synchronized with an external security system: they are intended for notification and approval purposes and are managed manually through the IKAN ALM interface.

VCR Branch ID

A unique identifier for a Branch in the external VCR system.

VCR Tag

After a successful Level Request on a Build Level the IKAN ALM Monitor applies a tag in the Version Control Repository (VCR) system. This VCR Tag matches a Build [Level Request] with its source code in the VCR The format of the VCR Tag normally matches the Tag Template defined for the Project Stream.

Version Control Repository (VCR)

An external versioning system holding different versions of sources. Related sources are bundled in a Project or subproject (sometimes also called a Module). A VCR Project may contain different development streams, called head (=main or trunk) or branch streams. IKAN ALM integrates with the following VCRs: Subversion, Git, CVS, and TFVC. In order to connect to the VCR, a VCR Client must be installed on the IKAN ALM Server and correctly configured. The IKAN ALM Monitor interacts with the VCR by retrieving or tagging sources. The web interface interacts with the VCR to show revision numbers, modified sources, …​ related to a Level Request.

Work Copy

A physical location (path) on the IKAN ALM Server to which the Monitor retrieves the source code from the VCR or Build Results from the Build Archive.