There are two major categories of workflow tools: priorities and requests. Workflow priorities allow you to determine the order in which workflows run -- this is especially helpful in busy build farms for top-level projects (e.g., a project used to deploy to production) need to build as quickly as possible. Priorities are set as part of the configuration process.
Workflow requests, on the other hand, are not part of the normal configuration process (see Workflow Requests for more). Rather, they can be controlled using a request plan set up separate from workflow configuration. Once a build has begun, it is possible to see all the requests spawned by a particular build (e.g., requests for builds of dependent projects).
Use workflow priorities to determine which workflow will run first. AnthillPro has three priority levels: High, Normal, and Low. All workflows with a priority of High will run before any other queued workflows with Normal or Low priorities, and workflows set with a Normal priority will run before those with a Low priority. However, once a workflow begins, it will not be suspended or stopped when a higher priority workflow is requested.
It is also possible to set a dynamic workflow-priority based on the Build Life (if applicable), environment, project, request, user, and/or workflow by creating a workflow priority script. See Workflow Priority Scripts.
Workflow Priorities are set during workflow configuration by selecting the priority from the drop-down menu. Additionally, the priority of an existing workflow may be edited on the workflow configuration page. To do so, go to Administration, select the workflow, and click the Edit Workflow icon on the Main page. Select the new priority from the drop-down and click Save. The next time the workflow runs, the new priority will be used.
The workflow priority will cascade down the dependency graph for either pushed or pulled builds. If a workflow with a higher priority is requested as part of a dependency build (see Workflow Priorities with Pulled Builds and Workflow Priorities with Pushed Builds), all subsequent requests will be assigned the highest priority for the remainder of the process. This holds for all dependency-based requests, including running any secondary workflows. However, the hard-coded workflow priority will not be changed. See also Use Workflow Request Contexts.
If a request for a workflow within a pulled dependency relationship is made, the highest priority within the workflow context will be assigned to all subsequent workflows requested by the dependency build. For example: Project A depends on Project B; and Project B depends Project C. Project A has a High priority; Project B has a Normal priority; and Project C has a Low priority.
With a request to build Project A -- which has a High priority -- the dependency builds of Projects B and C will be assigned a High priority, inherited from the parent project. Likewise, if a build of Project B is requested (i.e., the build is due to a source change in Project B and not a dependency request), the dependency build of Project C will inherit Project B's Normal priority for the duration of the build. See also Use Workflow Request Contexts.
If a request for a workflow within a pushed dependency relationship is made, the highest priority within the workflow context will be assigned to all subsequent workflows requested by the dependency build. For example: Project A depends on Project B; and Project B depends Project C. Project A has a Low priority; Project B has a Normal priority; and Project C has a High priority.
With a request to build Project C -- which has a High priority -- the dependency builds of Projects B and A will be assigned a High priority, inherited from Project C. Likewise, if a build of Project B is requested (i.e., the build is due to a source change in Project B and not a dependency request), the dependency build of Project A will inherit Project B's Normal priority for the duration of the build. See also Use Workflow Request Contexts.
When performing deployments, AnthillPro automatically tracks who performed the deployment and when the deployment was executed, but not "why" (e.g., a deployment may have been performed to send the artifacts to a staging server, to a specific testing machine, etc.). To track "why" a deployment was performed, use a Text Workflow Property to add an input to the deployment workflow that records why the deployment took place. See Create Workflow Property Note.
In order to make the note easily available as a Build Life Note, also use a simple BeanShell script (that includes the reason) in an Evaluate Script step as part of the deploy job. See Add Script to Workflow Property Note.
When the workflow is run, the property will appear on the Run Secondary Process page, and require the user to input a value. See Run Deployment with Workflow Property Note.
You must have administrative permissions. See Security.
An active AnthillPro project must have at least one Build Life.
A deployment workflow must already be created.
Familiarity with AnthillPro Scripting. See Scripting Basics.
To create a workflow property for a Build Life Note:
Go to Administration and select the deployment workflow to add properties to.
On the workflow page, select the Properties tab.
Click New Property, select Text form the drop-down menu, and click Select.
Set property:
Name. The name can be something like "Reason" or "Why". The property <name> will be accessed as ${property:<name>}. When adding the script, the name given here will be used. See Add Script to Workflow Property Note.
Description. Enter the question you want to ask. For example, "Why have you decided to deploy this application to this environment?"
Default Value. This can be left blank when using workflow properties for Notes.
User May Override. Check the box to allow users to override the property. If checked, the user will be able to specify a new value. If the user may override the property, give the following:
Label. Give a label for this Property to be shown when prompting users for value (leave blank to use the Name as the Label).
Is Required. Check to require the user to answer the question.
Click Save.
Add the property to the deployment by using an Evaluate Script step in the deploy job. The script should look up the current Build Life, the current workflow, the user, the environment, and the property. Additionally, the script must also tell AnthillPro to automatically create a Build Life Note. See Build Life Note Scripts.
Go to Administration and select the job associated with the deployment workflow.
On the job configuration page, select the Insert Before or Insert After icon of the step before or after where the script is to be included.
Open the Miscellaneous folder, select the Evaluate Script step, and click Select.
Name the script. For example, "Note".
Description. Give a description such as "Requires person running a deployment to give a reason."
Script. Create the BeanShell script that looks up the user requesting the deployment, the environment the deployment is targeting, and then combines that with the reason given by the user. The script also includes a short string that creates the Build Life Note.
Note that the property "Reason" is requested by the script. Make sure this matches the name given in Create Workflow Property Note.
Click Save.
In AnthillPro, the request is the first action taken by the server when executing an originating (i.e., build) or secondary (e.g., deployment) workflow. It does not matter if a person clicks the Build or Run a Secondary Process button or if a schedule or repository trigger kicks off a workflow: All these actions first generate a request before AnthillPro builds a projects or deploys the artifacts. Even if a workflow fails or does not run, a request is generated and recorded.
In AnthillPro, there are two basic tools available for managing/using requests:
Request Plan. Allows you to save the configuration for running one or more originating workflows and then run the build configuration at will. This can come in handy if you have to build many projects that have no dependency relationship but must be delivered as part of the same context. See Use Workflow Request Plans.
Request Context. Available once a request has been completed and the server has begun a build (deployment, etc.), the context lists all the requests spawned by a single workflow. This can come in handy when you need to know which Build Lives were created by a dependency trigger or need to manage the build order. See Use Workflow Request Contexts.
In addition, AnthillPro provides a specialized request search (go to Search > Request) for Build Life requests. You can search by a combination of project and workflow requests. The results of a search will tell you if a new Build Life was created or not, or if the request itself failed. You can drill down into each request to investigate requests, etc.
Request Plans are a way to save the configuration for running one or more originating workflows. For example, if you have multiple projects that must be delivered together -- but have no dependency relationships -- you can include all the build workflows into a single request plan. When the request plan is run, it will build (depending on your workflow configurations) your projects. When complete, you can then use the request context to see which projects were build.
There is no restriction on which originating workflows are included in a request plan: the same workflow can be part of multiple request plans and a single request plan can contain workflows from any AnthillPro project. Once configured (go to Dashboard > Saved Requests), the request plan can be run whenever you need to. When you create a request plan, it will save the properties that may need to be set when each workflow in the plan runs. The requests created by the request plan will run in the same request context and will take precedence in dependency resolution. To create a request plan:
Go to Dashboard > Saved Requests and click Create Request Plan.
Configure the request plan:
Name the request plan. This name will be displayed on the Saved Request main page.
Description. Give a short description. You can include the workflow name(s), project name(s), etc.
Click Save.
On the main Saved Requests page, click the Run icon under the Actions menu.
If you need to modify an existing request plan, select the View icon (the magnifying glass) under the Actions menu. You can then delete or add workflows.
A workflow request context is a collection of requests for workflows that are processed together. If a request triggers the creation of another request due to dependencies, the requests will be in the same context. For example, all requests that are created by the occurrence of a schedule are created in the same context; and any requests created by a Run Another Workflow or Run Dependency Workflow step are created in the same context. The request context is most helpful if dependencies are configured in AnthillPro (see Configuring Dependencies): the Request Context shows all the requests for a build spawned by a single action.
By viewing the request context, administrators can easily determine how AnthillPro manages build order and consistency along a dependency hierarchy by using the request context page. The request context page displays the project, workflow, environment, status, priority, and date of each request within the context.
The request being investigated will be highlighted with an orange frame.
To view the request for any workflow within the context, click the View Request icon.
To view the Build Life that was created by the request, follow the link at the Status item.
To prioritize every request within a running context, click the Prioritize Context link in the Request Context information box. This will automatically assign a High priority to every request within the context.
To access the workflow request context:
Go to the Dashboard and select the appropriate Build Life.
Click the Request Number under the Request menu.
On the Request page, click the View All Requests in Context icon in the Build Request menu.