Phases - General Information
This appendix provides more detailed information on the IKAN ALM concept of “Phases”.
When IKAN ALM is running Level Requests, Builds and Deploys, all actions are performed by executing a sequence of Phases.
Phases represent specific tasks or actions that must be performed by the system.
Phases are defined in the IKAN ALM database and can be consulted and manipulated in the Phases section of the Global Administration interface. Once they have been defined in Global Administration, Phases may be linked to Levels, Build or Deploy Environments in the Project Administration context.
Phases are categorized into different types depending on who created them (“Core” and “Custom” Phases) and where they are used (Level, Build and Deploy Phases).
The IKAN ALM core functionality is performed by so-called "Core" Phases. Those Core Phases can only be viewed, and cannot be altered nor deleted. Consider them an integral part of IKAN ALM. When you create a new Level, Build or Deploy Environment, its default workflow will be created and will completely consist of a sequence of Core Phases. Next, you may change this default workflow by removing Core Phases, by changing the sequence order or by adding your own Phases.
Those own Phases are also called “Custom” Phases. You may create them from scratch in Global Administration, based on one or more working scripts and resources, or you can import an existing Custom Phase, using the “Import Phase” functionality.
We also distinguish 3 types of Phases in IKAN ALM, depending on where they are being used:
-
Level Phases: phases inserted into the Level workflow. They will be executed on the IKAN ALM Server.
-
Build Phases: phases inserted into the Build Environment workflow. They will be executed on an IKAN ALM Agent.
-
Deploy Phases: phases inserted into the Deploy Environment workflow. They will be executed on an IKAN ALM Agent.
A Level Request represents the execution of a Level. A Level is split up into Level Phases. Those Phases will be executed sequentially, and when all Phases have completed, the Level Request has ended. One of the Phases of a Level Request is the Build Phase, which will execute the Builds related to this Level Request. A Build represents the execution of a Build Environment. These Builds, for their part, are split up into Build Phases. When all the defined Build phases in the Build have executed successfully, the Build was successful. The Deploys of a Level Request are handled similarly.
|
From IKAN ALM 5.5 onwards, there is no strict boundary anymore between those three types of Phases. The Core "`Execute Script"` Phase, is as well a Level as a Build or Deploy Phase, since you may use it on a Level, Build or Deploy Environment. Also, when you create a Custom Phase, you define where the Phase may be used: on a Level, on a Build Environment or on a Deploy Environment (or on all three Environments). In this context, we consider the Level to be also an "Environment". |
All types of Phases inserted into the workflow of a Level/Build/Deploy Environment have the following general fields:
| Field | Description |
|---|---|
Phase Name |
This field corresponds to the Display Name of the Phase definition and, at the same time, defines its function. |
Phase Version |
This field, together with the Phase name, forms the unique identifier of the Phase. The version of the Core Phases matches the IKAN ALM version (e.g., 5.5.0). The version of Custom Phases conforms to the format as explained in the section Creating a Phase Definition. |
Next Phase On Success (Phase Position) |
This field defines which Phase should be executed next if the current Phase completes successfully. It can’t be edited directly; its value is inferred by the order in the Phase sequence of the Level/Build Environment/Deploy Environment. |
Next Phase On Error |
This field defines which Phase should be executed next if the current Phase has gone in Error. Usually this Phase is a Cleanup Phase. |
Fail On Error |
This field defines whether the status of the enclosing Level Request, Build or Deploy should be set to Fail or to Warning when this Phase goes in Error. Possible values:
|
For more information on defining and configuring Phases, refer to the following sections:
When executing a Phase, it can have the following status:
| Status | Description |
|---|---|
Success |
The Phase finished successfully |
Warning |
The Phase finished with warnings |
Fail |
The Phase failed |
Running |
The Phase is currently being executed |
Not executed |
The Phase has not been executed |
Aborted |
The Phase was aborted |
The execution of a Phase can be viewed on the Phase Logs tab page on the Level Request Detail screen.
Level Phases
Level Phases are the actions that must be performed to complete a Level Request.
A vanilla IKAN ALM installation only contains Level Phases of the “Core” type. You can search for them in the Phases Overview by restricting the search to Core Phases that can be used on a Level. Next to those Core Phases, you may enrich the functionality of IKAN ALM by creating your own Custom Phases which can be used on a Level.
Level Phases may be inserted into the workflow of a Level (Project Administration - Level Phases) and are logged on the Phase Logs panel of the Level Request Detail screen (Level Request Detail - Phase Logs - Level Phases).
They are executed by the Monitor Thread of the IKAN ALM Server, so they run on the IKAN ALM Server Machine!
Their exact behavior may depend on the Level Type, and on the status of previously executed Level Phases.
The following section describes each of the Core Level Phases in detail:
Next to the Core Level Phases, you can create your own Custom Level Phases:
Retrieve Code Phase
The Retrieve Code Phase is usually the first Phase executed in a Level Request. It retrieves (checks out) the source code from the VCR and copies it to the Transport Location (sub folder of the Work Copy Location) where it is accessible for the Agents running the Builds of the Level Request.
When the Level Request is for a Build Level, the latest source code is checked out; when it is for a Test Level, the tagged source code is retrieved.
When the Level Request is for a Build Level attached to a Tag-based Project Stream, the source code is retrieved that was tagged with the tag specified in the VCR Tag field when the Level Request was created. See the description of the VCR Tag field in the section Creating a Build Level Request.
The Retrieve Code Phase also retrieves the source code and/or the build results of all Child Builds this Level Request is depending on. See Build Dependencies.
In the case of a Partial Build, (Creating a Branch Project Stream), only the modified source code will be retrieved and made available to the Agents running the Builds of the Level Request.
The alm.phase.retrieve.source.partialBuild.partialCheckout (Environment) Phase Parameter defines how this is done: if it is set to true (default value), this is done by a partial checkout of the modified sources. Otherwise, all sources will be checked out, but only the modified sources will be transported to the source location of the Build Environment.
When the Level Request has no Builds associated with it, the Retrieve Code Phase does nothing and exits with status Success. In that case, you could remove the Retrieve Code Phase from the Level’s workflow.
Build Phase
The Build Phase activates and monitors the execution of the Builds of the Level Request.
When it starts, it activates the Builders running on the Agent Machines to start all the waiting Builds of the Level Request. Then, it waits for all the Builds to finish.
Meanwhile, when a Level Request is aborted while in the Build Phase, the Build Phase notifies and stops the executing Builders.
When all Builds have finished, the status of the Build Phase is set, depending on the statuses of the Builds:
-
When a Build has failed, the status of the Build Phase is set to Error,
-
When no Builds have failed, but one Build ended with status Warning, the status of the Build Phase is set to Warning
-
When all Builds executed successfully, the status of the Build Phase is set to Success.
When no Builds have been defined for the Level Request, the Build Phase does nothing and exits with status Success. In that case, you could remove the Build Phase from the Level’s workflow.
Tag Code Phase
The Tag Code Phase tags the code that was checked out with the VCR Tag associated with the Level Request. When the tag already exists in the VCR, the tag is moved.
The Tag Code Phase only tags when the checked-out code was the latest code of the VCR branch. So, it won’t tag for a Build Level in a Tag Based Project Stream, and it won’t (re-)tag for a Deliver Level Request. In both of those cases, tagged code was checked out, so no tagging was needed, and you could remove the Tag Code Phase from the Level’s workflow.
Deploy Phase
The Deploy Phase activates and monitors the execution of the Deploys of the Level Request.
When it starts, it activates the Deployers running on the Agent Machines to start all the waiting Deploys of the Level Request with Sequence Number 0.
Next, it waits for all those Deploys to finish.
Next, when those Deploys all ended with status Success or Warning, it activates the Deploys that have Sequence Number 1, and so on until there are no more Deploys or a Deploy has failed.
Meanwhile, when a Level Request is aborted while in the Deploy Phase, the Deploy Phase notifies and stops the executing Deployers.
When all Deploys have finished, the status of the Deploy Phase is set, depending on the statuses of the Deploys:
-
When a Deploy has failed, the status of the Deploy Phase is set to Error,
-
When no Deploys have failed, but one Deploy ended with status Warning, the status of the Deploy Phase is set to Warning
-
When all Deploys executed successfully, the status of the Deploy Phase is set to Success.
When no Deploys have been defined for the Level Request, the Deploy Phase does nothing and exits with status Success. In that case, you could remove the Deploy Phase from the Level’s workflow.
Issue Tracking Phase
The Issue Tracking Phase links Issues, managed in an external Issue Tracking System, with a Level Request, by searching for references to the Issues in the commit comments of the VCR.
In the case of a Build Level Request, the Issue Tracking Phase parses the commit comments that have been entered since the last successful Level Request for that Level and tries to match the Issue Pattern of the attached Issue Tracking System (Creating an Issue Tracking System). All found Issues will be attached to the Level Request.
For an Atlassian JIRA, MF ALM, GitHub or TFS Issue Tracking System, the Issue Tracking Phase will also connect to and try to identify the issues in JIRA, MF ALM, GitHub or TFS. For each identified Issue, it will try to get additional information from JIRA, MF ALM, GitHub or TFS (like description, status, owner and priority) and store it in IKAN ALM.
When the Level Request is a Deliver Level Request, the Issue Tracking Phase enumerates all the Issues that have been attached to the previous successful Build Level Requests that have occurred since the last successful Deliver Level Request on this Level, and adds all of them to this Level Request.
For example:
Suppose we have built the following Builds: Build 3 with Issue 3, Build 4 with Issue 4, Build 5 with Issue 5 and 6. Previously, Build 2 was delivered. If we now deliver Build 5, Issues 3,4,5 and 6 will be attached to the Deliver Level Request.
For an Atlassian JIRA, MF ALM, GitHub or TFS Issue Tracking System, the Issue Tracking Phase will also synchronize all the issues attached to the Deliver Level Request: it will compare the info about the issue in IKAN ALM with the current information in JIRA, MF ALM, GitHub or TFS and update description, status, owner or priority if necessary.
If the Level Request was not successful, the Issue Tracking Phase does nothing, and exits with status Success, reporting that it did not process any Issues.
When no Issue Tracking System was attached to the Project of this Level Request, the Issue Tracking Phase does nothing, and exits with status Success.
|
When you attach an Issue Tracking System to a Project after it has been created, you must manually add the Issue Tracking Phase to the Levels you want Issue Tracking to be performed on. |
Link File Revisions
The Link File Revisions Phase links the involved File Revisions to the Level Request.
For a Build Level Request this is done based on the File Revisions that have been checked out from the VCR during the Retrieve Code Phase.
For a Deliver or Rollback Level Request, this is done based on the File Revisions linked to the Level Request (from the previous Level) that will be delivered or rollbacked. Although these File Revisions are also linked to the Package, this Phase is necessary in order to take a snapshot of the Package content at Level Request execution time, since this content will probably change in time.
As this Phase is only applicable to Level Requests for Packages, it will only appear in the Levels of Package-based Projects.
Cleanup Work Copy Phase
The Cleanup Work Copy Phase cleans up the Work Copy Location where the sources of the Level Request were checked out.
It fails when it can’t find the folder. Typically, this Phase’s Fail On Error flag is set to ‘No’, causing the Level Request to end with status Warning instead of Fail when this Phase goes in error.
If the Level has its Debug flag set to “Yes”, the Cleanup Work Copy Phase does nothing, and exits with status Error, reporting that the Debug flag was set for the Level.
Execute Script Phase
The Execute Script Phase executes a script on the IKAN ALM Server Machine using the specified Scripting Tool and the pre-defined Level Parameters. Both the script (alm.phase.mainScript) and the Scripting Tool (alm.phase.builder) must be defined by a mandatory Phase Parameter after inserting this Phase into a Level.
The Execute Script Phase has been introduced on the Level from IKAN ALM 5.5 onwards, together with the Custom Phase. The log generated by the script is saved in the IKAN ALM database. Note that this Phase is never inserted into the default workflow of a Level (i.e., when creating a new Level from scratch).
When the script is executed successfully, the Execute Script Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Level Phases).
Next to the Core Phases, you may define your own Phases in Global Administration (Creating a Phase Definition) and specify that they may be used on a Level. Once inserted into the workflow of a Level, we call them Custom Level Phases.
Custom Level Phase
|
The Display Name of a Custom Level Phase, as defined in Global Administration and provided by the creator of the Custom Phase, is used in the ALM interface when inserting it into a Level or viewing the log on the View Level Request Log screen. So, the name displayed could be something like “Retrieve from Archive” or “Filter Sources”. |
A Custom Level Phase executes a script on the IKAN ALM Server Machine using the specified Scripting Tool and the pre-defined Level Parameters. The Display Name of this Phase and the executed script (alm.phase.mainScript) are specified in the definition of this Custom Phase in Global Administration. The Scripting Tool (alm.phase.builder) that executes the script depends on the Execution Type of the Phase definition and its value must be set after inserting this Phase into a Level.
The Custom Level Phase has been introduced from IKAN ALM 5.5 onwards, together with the Execute Script Phase. The log generated by the script is saved in the IKAN ALM database. Note that this Phase is never inserted into the default workflow of a Level (i.e., when creating a new Level from scratch).
When the script is executed successfully, the Custom Level Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Level Phases).
|
A Custom Level Phase may also be a Custom Build or Deploy Phase: the definition in Global Administration can also specify that it may be used on a Build or Deploy Environment. |
Build Phases
Build Phases are the actions that must be performed to complete a Build. A vanilla IKAN ALM installation only contains Build Phases of the “Core” type. You can search for them in the Phases Overview, by restricting the search to Core Phases that can be used on a Build Environment. Next to those Core Phases, you may enrich the functionality of IKAN ALM by creating your own Custom Phases that can be used on a Build Environment.
Build Phases may be inserted into a Build Environment (Build Environment Phases). Their actions during the handling of a Build are logged on the Phase Logs tab page of the Level Request Detail screen (Build Actions).
They are executed by the Builder Thread of the IKAN ALM Agent, so they run on an IKAN ALM Agent Machine!
The following section describes each of the Core Build Phases in detail:
Next to the Core Build Phases, you can create your own Custom Build Phases:
Transport Source Phase
The Transport Source Phase transports the Source code and, possibly, the build results of Child Projects from the Work Copy Location on the IKAN ALM Server Machine to the Build Environment Source Location on the IKAN ALM Agent Machine, using the Transporter associated with the IKAN ALM Agent Machine.
When doing a Partial Build, the Transport Source Phase may also transport the build results of the previous Build from the Build Archive Location on the IKAN ALM Server Machine to the Environment’s Source Location on the IKAN ALM Agent Machine. Set the alm.phase.transport.source.partialBuild.copyPreviousBuildResult (Environment) Phase Parameter to true to obtain this behavior. Note that the default value of this Parameter is false.
See also Retrieve Code Phase.
Verify Build Script Phase
The Verify Build Script Phase tries to locate the defined Build Script, and fails if it cannot.
First, it determines what Build Script to look for. If there’s a Build Script defined on the Build Environment (Creating a Build Environment), it will try to find that. If not, it will look for the Build Script defined on the Project (Editing Project Settings).
Then, it tries to find the Build Script in the Build Environment’s Source Location.
If not found, it tries to copy the Build Script from the IKAN ALM Script Location as defined in the System Settings.
If not found there either, the Verify Build Script Phase exits with status Error.
If found, the Verify Build Script Phase exits with status Success, and reports where it located the Build Script.
Execute Script Phase
The Execute Script Phase executes the Build Script on the defined Machine using the specified Scripting Tool and the defined Build Parameters.
It saves the Build log generated by the Build Script in the IKAN ALM database.
When the Build Script is executed successfully, the Execute Script Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Build Actions).
Transport Deploy Script Phase
The Transport Deploy Script Phase copies the Deploy Scripts that are defined in the Deploy Environments linked to the Build Environment of this Build from the Build Environment’s Source Location to the Target Location.
This action is performed, so that the Deploy Scripts are included in the compressed Build File created by the Compress Build Phase.
Transport Package Results Phase
This Phase is only relevant for Package Builds.
If the Package is part of a Package Build Group, it will retrieve the latest Build Results of some (or all, dependent on the configuration of the Package Build Group) of the Packages in the Package Build Group. It will use the Transporter defined for the Agent to transport the Results from the IKAN ALM Build Archive on the IKAN ALM Server to the ${sourceRoot}/packages directory on the Build Environment. The Phase also creates a PackageBuildGroup.xml file in the ${sourceRoot}/packages directory on the Build Environment that can be used as input in later Phases, e.g., for the Mainframe Compilation workflow, to transfer these Build Results and build up the correct PDS structure on the Mainframe.
The Retrieve All Build Results attribute of the Package Build Group, and the setting of the Dependency Level of the Packages in the Package Build Group determine which Build Results will be retrieved: the latest build results of all Packages in the Package Build Group in case Retrieve All Build Results has been set to true, or only the latest Build Results of Packages with a lower Dependency Level in case Retrieve All Build Results has been set to false.
Compress Build Phase
The Compress Build Phase compresses the Build result files in the Build Environment’s Target Location.
The Archive format is determined by the alm.phases.compress.result.archiveFormat Environment Phase parameter. If set to zip, tgz or 7z, the chosen archive format will be used. If not set or set to auto, a format will be chosen based on the OS of the Agent Machine. If the Agent Machine runs a Windows OS, the Compress Build Phase creates a .zip file, otherwise it creates a .tar.gz file.
Archive Result Phase
The Archive Result Phase transports the compressed Build file from the Build Environment’s Target Location on the IKAN ALM Agent Machine to the Build Archive Location on the IKAN ALM Server Machine, using the Transporter associated with the IKAN ALM Agent Machine.
Cleanup Source Phase
The Cleanup Source Phase deletes all files in the Build Environment’s Source Location.
If the Build Environment has its Debug flag set to ‘Yes’, the Cleanup Source Phase does nothing, and exits with status Error, reporting that the Debug flag was set in the Build Environment.
Cleanup Result Phase
The Cleanup Result Phase deletes all files in the Build Environment’s Target Location.
If the Build Environment has its Debug flag set to ‘Yes’, the Cleanup Result Phase does nothing, and exits with status Error, reporting that the Debug flag was set in the Build Environment.
Next to the Core Phases, you may define your own Phases in Global Administration (Creating a Phase Definition) and specify that they may be used on a Build Environment. Once inserted into the workflow of a Build Environment, we call them Custom Build Phases.
Custom Build Phase
|
The Display Name of a Custom Build Phase, as defined in Global Administration and provided by the creator of the Custom Phase, is used in the ALM interface when inserting it into a Build Environment or viewing the log on the View Build Phases Log screen. So, the name displayed could be something like “Generate Documentation” or “Run Unit Tests”. |
The Custom Build Phase executes a script on the IKAN ALM Agent Machine using the specified Scripting Tool and the defined Build Parameters. The Display Name of this Phase and the executed script (alm.phase.mainScript) are specified in the definition of this Custom Phase in Global Administration. The Scripting Tool (alm.phase.builder) that executes the script depends on the Execution Type of the Phase definition. When this Execution Type differs from the Scripting Tool linked to the Build Environment, its value must be set after inserting this Phase into a Build Environment.
The Custom Build Phase has been introduced from IKAN ALM 5.5 onwards. The log generated by the script is saved in the IKAN ALM database. Note that this Phase is never inserted into the default workflow of a Build Environment (i.e., when creating a new Build Environment from scratch).
When the script is executed successfully, the Custom Build Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Build Actions).
|
A Custom Build Phase may also be a Custom Level or Deploy Phase: the definition in Global Administration can also specify that it may be used on a Level or Deploy Environment. |
Deploy Phases
Deploy Phases are the actions that must be performed to complete a Deploy. A vanilla IKAN ALM installation only contains Deploy Phases of the “Core” type. You can search for them in the Phases Overview, by restricting the search to Core Phases that can be used on a Deploy Environment. Next to those Core Phases, you may enrich the functionality of IKAN ALM by creating your own Custom Phases that can be used on a Deploy Environment.
Deploy Phases may be inserted into a Deploy Environment (Deploy Environment Phases) and their actions during the handling or a Deploy are logged on the Phase Logs tab page of the Level Request Detail screen (Deploy Actions).
They are executed by the Deployer Thread of the IKAN ALM Agent, so they run on an IKAN ALM Agent Machine!
|
The number of running Deploys on an IKAN ALM Agent is managed by specifying the Concurrent Deploy Limit attribute for the Machine representing the IKAN ALM Agent. By default, this limit is set to 0, meaning that all Deploys on the Agent will run concurrently (i.e., in parallel). If another number is specified, a Deploy can only be started if there are not more running Deploys as indicated. So if the number is limited to 1, this means that all deploys will run sequentially on the Agent. If the number is set to 2, only 2 deploys can run concurrently, meaning that if there is a third Deploy with status Run , this third one will be added to a “Waiting queue” and it will only be started if one of the other (running) Deploys has finished. |
The following section describes each of the Core Deploy Phase in detail:
Next to the Core Deploy Phases, you can create your own Custom Deploy Phases:
Transport Build Result Phase
The Transport Build Result Phase transports the Build result from the Build Archive Location on the IKAN ALM Server Machine to the Deploy Environment Source Location on the IKAN ALM Agent Machine, using the Transporter associated with the IKAN ALM Agent Machine.
When doing a Partial Deploy, only the modified and added files in the Build result are transferred. See the description of the Partial Deploy field in the section Creating a Deploy Environment.
Decompress Build Result Phase
The Decompress Build Result Phase decompresses the Build result file that was transported by the Transport Build Result Phase into the Deploy Environment’s Source Location, and afterwards, deletes the Build result file.
Verify Deploy Script Phase
The Verify Deploy Script Phase tries to locate the defined Deploy Script, and fails if it cannot.
First, it determines what Deploy Script to look for. If there’s a Deploy Script defined on the Deploy Environment (Creating a Deploy Environment), it will try to find that. If not, it will look for the Deploy Script defined on the Project (Editing Project Settings).
Then, it tries to find the Deploy Script in the decompressed Build result available in the Deploy Environment’s Source Location.
If not found, it tries to copy the Deploy Script from the IKAN ALM Script Location as defined in the System Settings.
If not found there either, the Verify Deploy Script Phase exits with status Error.
If found, the Verify Deploy Script Phase exits with status Success, and reports where it located the Deploy Script.
Execute Script Phase
The Execute Script Phase executes the Deploy Script on the defined Machine using the specified Scripting Tool and the defined Deploy Parameters.
It saves the Deploy log generated by the Deploy Script in the IKAN ALM database.
When the Deploy Script is executed successfully, the Execute Script Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Deploy Actions).
Cleanup Build Result Phase
The Cleanup Build Result Phase deletes all files in the Deploy Environment’s Source Location.
If the Deploy Environment has its Debug flag set to ‘Yes’, the Cleanup Build Result Phase does nothing, and exits with status Error, reporting that the Debug flag was set in the Deploy Environment.
Next to Core Phases, you may define your own Phases in Global Administration (Creating a Phase Definition) and specify that they may be used on a Deploy Environment. Once inserted into the workflow of a Deploy Environment, we call them Custom Deploy Phases.
Custom Deploy Phase
|
The Display Name of a Custom Deploy Phase, as defined in Global Administration and provided by the creator of the Custom Phase, is used in the ALM interface when inserting it into a Deploy Environment or viewing the log on the View Deploy Phases Log screen. So, the name displayed could be something like “Update Database” or “Deploy to web server”. |
The Custom Deploy Phase executes a script on the IKAN ALM Agent Machine using the specified Scripting Tool and the defined Deploy Parameters. The Display Name of this Phase and the executed script (alm.phase.mainScript) are specified in the definition of this Custom Phase in Global Administration. The Scripting Tool (alm.phase.builder) that executes the script depends on the Execution Type of the Phase definition. When this Execution Type differs from the Scripting Tool linked to the Deploy Environment, its value must be set after inserting this Phase into a Deploy Environment.
The Custom Deploy Phase has been introduced from IKAN ALM 5.5 onwards. The log generated by the script is saved in the IKAN ALM database. Note that this Phase is never inserted into the default workflow of a Deploy Environment (i.e., when creating a new Deploy Environment from scratch).
When the script is executed successfully, the Custom Deploy Phase exits with status Success. If not, it exits with status Error and logs the errors on the Phase Logs panel of the Level Request Detail screen (Deploy Actions).
|
A Custom Deploy Phase may also be a Custom Level or Build Phase: the definition in Global Administration can also specify that it may be used on a Level or Build Environment. |