All types of AnthillPro projects are created, edited, copied, moved, deactivated, activated, deleted, imported, and exported on the Main Administration page by selecting the appropriate icon. Projects may be created within folders or just under the Administration root folder. Only users with read/write appropriate permissions are able to perform these tasks. If you do not have the required permissions, contact your AnthillPro administrator. See Manage Security.
Importing and exporting projects is done from the Administration page. AnthillPro exports the project configurations as an XML file. The exported file may be used to transfer project configurations between multiple instances of AnthillPro, for troubleshooting purposes, etc. A project may be imported either into the Administration folder or into any sub-folder on the Administration page. Once successful, the imported project will have the same configurations as the original.
See also Import and Export Library Jobs and Import and Export Workflow Definitions.
Changing a project's source allows you to remove all source configuration from workflows within the project and then set up the project using a different SCM type, etc. This process cannot be reversed. If you choose to change a project's source type, you will need to reconfigure all the source for your originating workflows. If your reconfigured source is of a different type from what was originally used, you must also replace all the SCM-specific steps within jobs (both library and project) used by the project.
This feature is not intended to be used on any production project, except at the direction of Urbancode support.
To change a project's source type:
Go to Administration and select the project.
On the project's page, click Edit.
Click the Reset All Source Configurations link.
Confirm that you want to change the Source Type. Note that once you click Done, all the source configurations for the project will be removed. You will then have to reconfigure the source for every originating workflow used by this project.
Select the originating workflow(s) associated with this project. You will be prompted with the Repository configuration page. Proceed with source configuration as you would for a new workflow. See Source Configuration.
You will also need to change any SCM-specific steps in your existing jobs if the repository type has changed. When modifying job steps, make sure to use the same step for the new SCM type.
Use Operational (Non-Life-Cycle Based) Projects for administrative, operational, and system maintenance. Operational Projects are not connected to a Life-Cycle Model, and the project's workflows will not create a Build Life when a job is run.
| If you have a lot of Operational Projects, you may want to include them in the Cleanup Policy. This will allow you to determine how long operational workflows and jobs are kept. See Cleanup Schedule. |
Operational Projects are configured like regular projects on the Administration page, are managed identically to other projects, and visible on the Dashboard. Once the project is created, workflows and jobs are added to the project just as with any project.
In general, Operational Projects are used to automate processes ancillary to traditional build and release cycles, and can be thought of as secondary workflows that are not associated with a Build Life.