A Life-Cycle Model allows you to create a reusable template that maps your organizational structure. For example, a typical set-up would be DEV, QA, PROD process (i.e., pipeline or life-cycle): a build starts out in development, is deployed to quality assurance for testing, and then finally sent to production for release. You would configure the Life-Cycle Model to apply a new status when a build is sent to QA, and one when the build is sent to PROD. Likewise, a stamp style (essentially a build identifier) can be applied to each build that corresponds to the status. This enables you to know exactly which build is in which environment because the status and stamp are recorded on the Dashboard.
Life-Cycle Models, then, give you control over how a build is identified, the different stages a build must go through on its way to the end user, how artifacts are handled, and which clean-up policies are enforced.
| Life-Cycle Models are closely associated with AnthillPro's Build Life concept: Much of what you configure in the Life-Cycle Model determines how a Build Life is identified and used. See Build Life for more. |
Once a Life-Cycle Model is created, it may be used for multiple projects with similar Life-Cycles without having to reconfigure a list of Statuses, Stamps, Artifact Sets, and Cleanup for the new project. This enables you to create system-wide standards that every team must use when configuring projects.
Make sure you have administrative permissions before continuing. See Manage Security.
Go to System > Life-Cycle Models under the Project Support menu, and click the Create New button.
Give the Model a name and a brief description (optional). Click Save.
Success and failure statuses are applied by default (because they are required), but common status names such PROD or QA can be created and associated with a color (using a drop-down menu) for ease in spotting Build Lives at a given status. As an indication of what stage a Build Life has reached, status names similar to those of environment groups can be useful in identifying which environment groups a Build Life has been deployed to.
| If you have a number of statuses in your Life-Cycle Models, you can reorder them using the drag-and-drop tool so that the ones you are most interested in appear at the top of the list. The order set here will be displayed on the Dashboard Workflow page once a workflow is complete. |
To create a new status, select the Status link from the New Life-Cycle Model main page.
Click the Create New button.
Name, give a description of, and assign a color to the new status. When selecting a color, you can use the up/down keys to quickly scroll through the picker.
Click Save.
Arrange order by using the Move Status Up and/or Move Status Down icons under the Operations menu.
Stamps are essentially numbers or labels used to identify a build, and are used to help identify a particular build. Stamp styles (or stamp types), then, are used to apply different stamps to a single build, and allow you to help track a build throughout its life-cycle. While most projects will only need a single stamp representing the build number, many AnthillPro users find it helpful to apply multiple stamp styles to specific projects, such as those released into production.
Typically, apply a new stamp to a build when it is promoted (or deployed or released) to a new stage in the life-cycle by creating multiple stamp styles. So a DEV stamp style would be used to identify development builds; a QA stamp style would be used for identifying the build when it is sent to QA; and a PROD (production) stamp style would be used to identify when the build has been released into production.
In this way, you can set up AnthillPro to stamp a build according to the protocol of each individual environment (or stage) that the build goes through. For example, a single build may have 3 (three) stamps throughout its life, each represented by a different stamp style:
DEV Stamp Style. Typically, this stamp style uses a simple Build Number stamp for development builds, often using a source-control version number or just counts successive builds: i.e., dev-500, dev-501, dev-502; or simply 100, 101, 102, etc. See Stamping.
Though stamps can be used as the basis of version control baseline, label or tag, that is strictly optional.
QA Stamp Style. When a build has been deployed to quality assurance, the QA stamp style will typically contain a stamp such as qa-100, qa-101, qa-102, etc., identifying that the build has reached the quality assurance stage of the life-cycle. See Applying Multiple Stamps to a Build.
PROD Stamp Style. Will usually contain a different number (or identifier) that's easier for customer's to understand: i.e., 1.1, 1.2, 1.3. This stamp style may correspond with your release numbers, but it does not have to. See Applying Multiple Stamps to a Build.
Once a stamp style is created, AnthillPro ties the stamp to the workflow, and automatically identifies all successive builds. When multiple stamp styles are used, AnthillPro will assign a new stamp to a build based on criteria you define when configuring the stamp style or based on the Create Stamp job step of the secondary workflow. See Applying Multiple Stamps to a Build.
To create a new Stamp Style, select the Stamp Styles link and click Create New.
Give the Stamp Style a name and description.
Click Save.
In AnthillPro, an Artifact Set is a label for a collection of build artifacts. AnthillPro allows you to create as many Sets as you want, and then associate the build artifacts with a particular Artifact Set. This gives you fine-grained control over how the artifacts are used.
Some types of commonly used Artifact Sets:
A code library used by multiple projects.
A platform-specific client.
Images or video incorporated into a product.
Documentation of the shared library to be rolled into developer documentation (JavaDoc).
The deployable executable of a top-level project.
In general, similar projects often have similar artifacts. In
AnthillPro, instead of managing these artifacts on every project, you
manage them as part of the Life-Cycle Model by creating Artifact Sets.
When you create an Artifact Set on a Life-Cycle Model, that Artifact Set
will be available to every project that uses the Model. Once that is done,
you then associate the build artifacts with an Artifact Set during
workflow configuration. For example, projects that generate a shared
library might have an Artifact Set called lib which contains
the library. On the build workflow, you associate the library with the
lib Artifact Set. This makes the artifacts (the library)
available to be used in dependencies, deployments, or other
processes.
In AnthillPro, Artifact Sets are used to define dependency relationships: Any project that another project depends on generates one or more collections of files used by the dependent project. These collection of files are called an Artifact Set in AnthillPro. When configuring a dependency, you select which Artifact Sets a project depends on (see Dependency Management for more information on how AnthillPro manages dependencies). Artifact Sets are also used to specify files that may be used in secondary workflows. The most common secondary workflow that uses Artifact Sets is the deployment workflow: AnthillPro will send the artifacts to a different location (say a server in QA) based on the Artifact Sets you configure (see Setting Up a Deployment Process for more information on how Artifact Sets are used in deployments).
To create a new Artifact Set, select the Artifact Sets link and click Create New.
Give the Artifact Set a name and description (optional).
Click Save.
See also Artifact Set Security and Setting an Artifact Retention Policy (under Cleanup).
Once an artifact set has been configured, it is possible to secure it. This will enable you to control, based on the default permissions for user roles, who can download/resolve an artifact set and who can set security permissions for an artifact set. If you do not see a security icon (a yellow badge) in the Operations menu, Artifact Set Security has not been enabled or you do not have the appropriate permission.
Please see Securing Artifact Sets for detailed instructions. To properly secure an artifact set, you will need to first enable default permissions, change a system setting (System > Server Settings > Security) and then set the artifact security for the artifact set(s) by selecting the Security icon on the Operations menu.
The Cleanup configures AnthillPro to periodically clean up old Build Lives, build requests, and miscellaneous jobs generated by a project. Cleanup is on a per-project basis, so every project that uses the same Life-Cycle Model will have the same policy.
| If you set a cleanup policy that keeps the 5 most recent successful Build Lives for 1 week, AnthillPro will enforce the policy on a per-workflow basis. So, if you have a "trunk" and a "branch" originating workflow in the same project, AnthillPro will keep the 5 most recent successful Build Lives of "trunk" AND of "branch" for 1 week. |
There are three basic options for Build Life cleanups:
Delete. Fully deletes the Build Life, artifacts and logs from the server. See Setting an Artifact Retention Policy for more.
Inactivate. Deletes the Build Life's artifacts and marks the Build Life as inactive, preventing execution of workflows on the Build life and any use of the inactive Build Life to satisfy dependencies. See Setting an Artifact Retention Policy for more.
Archive. Deletes the Build Life's artifacts and marks the Build Life with an archived status. The Build Life can later be unarchived and its artifacts rebuilt with an unarchive process. See Setting an Artifact Retention Policy for more.
Click the Cleanup link to determine a Cleanup Schedule, choose how Builds Requests are handled, and set how Build Lives are cleaned-up.
There is no one-size-fits-all "policy": what you want to keep and for how long depends on your organizational guidelines/processes. Eventually, you will need to decide how long to keep the artifacts in order to save disk space. Following is a general guideline that should work for most organizations:
CI/Daily Builds (Success): 15 days: the 5 most recent builds marked as "success" (for CI and/or nightly builds. Any build sent to testing, generally released requires different retention policy).
Any Build (Failure): 3 days / 0 builds for failed. No reason to keep them -- often failures do not result in artifacts.
Builds Sent for Testing: 30 days for testing builds (or the minimum testing cycle, whichever is longer). Most Agile testing cycles are shorted than 1-month, so keeping the artifacts around for at least that long is a good idea. If your testing cycle is longer than 30 days, then keeping the artifacts until the testing cycle is complete is a good idea.
General Release Builds: Production should be kept around until the build has reached its end of life or regulations allow for deletion.
See also Artifact Sets above.
Cleanup is kicked-off via a schedule, which must created at System > Schedules under the Project Support menu (see Create Schedules). AnthillPro will automatically execute the cleanup rules you set in the Cleanup Build Requests and Cleanup Build Lives sections, based on the cleanup-policy schedule. In addition, the cleanup policy allows you to configure cleanups of lockable resources, operational workflows and operational jobs.
Go to System > Cleanup under the Project Support menu.
Click the Edit icon and configure the cleanup policy:
Schedule. Select the schedule. If you do not have an appropriate schedule, please create one before continuing. See Create Schedules.
How often the schedule should fire is determined, in part, by the cleanup rules set on the Life-cycle Model. For example, if you have cleanup run on a weekly schedule and the Cleanup Build Request set to Never, no build requests will be cleaned up. Likewise, if you have Cleanup Build Lives for "All Build Lives" set to be kept for 2 weeks, the first time the cleanup schedule runs (one week from the starting date) no Build Lives will be deleted because the policy only allows Build Lives to be cleaned up every 2 weeks. However, the second time (two weeks from the initial creation of the schedule) the schedule runs all Build Lives 2 weeks and older will be cleaned up. Active. Check the box to activate the cleanup schedule. Make sure the schedule you selected above is also marked as Active. To do this go to System > Schedules and ensure that it says "Yes" under the Active menu. If you select an inactive schedule, your cleanup policy will not run, even if it is marked as active here.
Days to Keep Lockable Resources. Give the number of days that lockable resources should be kept after they are last used. This applies to limited resources (e.g., working directories). If you are using unique resources (such as unique working directories), this setting can come in handy to save space. Default value is 30 days. Use -1 to never clean up.
Days to Keep Operation Workflows. Give the number of days you want to keep operational workflow executions. Use -1 (the default value) to never clean up. If you rarely use operational projects, the default values should suffice. The only cleanup option is to delete the workflow.
Days to Keep Operation Misc Jobs. Give the number of days that operational miscellaneous jobs, such as cleanup jobs and notification jobs, are kept for. Default value is 1 day. Use -1 to never clean up. If you rarely use operational projects, the default values should suffice. The only option is to delete the jobs.
Click Done.
Use this section to determine when Build Requests are cleaned up. Once set, the Cleanup Schedule will apply these settings every time it automatically fires. For example, if your cleanup schedule fires once a week, but you set the Misc. Job field to 100 days, when the cleanup schedule fires, only jobs that are older than 100 days will be cleaned up.
To schedule the automatic deletion of build requests, select the Edit icon of the Cleanup Build Request menu.
In the Misc. Jobs field, enter the number of days a miscellaneous job will exist before it is cleaned up. To keep jobs indefinitely, leave this field blank.
In the Build Requests Without Build Life field, enter the number of days a build request that did not produce a build life will exist. To keep all requests, leave this field blank. Click Save.
The cleanup of Build Lives is based on the status the Build Life has achieved. For example, set the cleanup to keep all Build Lives a minimum number of days or choose a specific status, such as failure, to expire after a minimum number of days, etc. Once set, the Cleanup Schedule will apply these settings every time it automatically fires. For example, if your cleanup schedule fires once a week, but you set the All Build Lives field to 100 days, when the cleanup schedule fires, only Build Lives that are older than 100 days will be cleaned up. To set the Build Life cleanup policy:
Under the Cleanup Build Lives menu, select the Edit icon for the appropriate status.
Keep Days. Give the minimum number of days to keep all Build Lives that have been assigned this status (leave the field blank to keep all Build Lives).
For example, setting the days at "5" will keep every Build Life that has been assigned this status for a minimum of 5 days, unless overridden by the Keep Latest Build Life specification. When the cleanup schedule fires, it will clean up Build Lives that are older than 5 days.
Keep Latest. Specify the number of the most recent Build Lives that have been assigned this status from being cleaned up, regardless of the Keep Days policy.
For example, if the Keep Days field is set to "5" (days) and the Keep Latest field set to "2" (Latest Build Lives), when the 2 most recent Build Lives that have been assigned this status are 5 days old, they will not be cleaned up by the Keep Days policy. This allows you to keep a copy of the most recent Build Lives no matter how old they are.
Cleanup Type. Select the cleanup type from the drop-down menu. Options are Delete (see Delete a Build Life), Inactivate (see also Inactivate Build Life), and Archive (see also Archive and Unarchive Build Life).
Click Save.
Repeat Items One thru Five for every status.
Edit a Life-Cycle Model any time by following the procedures outlined in the Creating a Life-Cycle Model section of this tutorial. Simply select the Model to edit and click the Edit icon for the feature to be change. Click Save.
Projects using the same Life-Cycle Model may not all respond the same to changes. Each project may need to be reconfigured if any changes are made to its Life-Cycle Model.
Migrating a Life-Cycle Model will transfer all Projects, Library Workflows and Library Jobs using it. The Status, Artifact Sets, and Stamps will be reconfigured during the migration.
Go to System > Life-Cycle Model under the Project Support menu.
On the Life-Cycle Models page, click the Migrate icon of the Life-Cycle Model you want to migrate.
Migrate To. Select the Life-Cycle Model to migrate to from the drop-down menu and click Migrate.
On the Migrate Life-Cycle Model, select:
Status Migration. Select one or more new statuses to migrate each of the old statuses to.
Artifact Migration. Select a new artifact set to migrate each of the old artifact sets to.
The Life-Cycle Model being migrated to must have artifact sets configured that AnthillPro can map to. See Artifact Sets.
Stamp Migration. Select a new stamp style to migrate each of the old stamp styles to.
The Life-Cycle Model being migrated to must have stamps configured that AnthillPro can map to. See Stamp Style.
Click Migrate then Done.
User access to a Life-Cycle Model is managed on the Security tab. Administrators can define what roles have access to read, write, or determine security for Life-Cycle Models. You need administrative permissions to set environment security. See Manage Security.
Go to System > Life-Cycle Models under the Project Support menu.
On the Life-Cycle Models page, select the appropriate Life-Cycle Model from the list.
Select the Life-Cycle Model's Security tab and click Edit.
Check the Roles and permissions for this agent. See Define Roles and Set and Manage Permissions.
Click Save then Done.