/
Configuring a Project

Configuring a Project

Select Projects from the menu.

Double click on an existing project and click on the Configuration tab (second tab).


Enter/modify values for the following different configurations for the Project.

Project Configuration

Field Name

Required

Description

Active

Yes

Whether or not the project is active. Build and Deploy workflows cannot be executed on inactive projects.

SCM Type

Yes

Type of the Source Control Management. Default value can be configured using Project Defaults.

Priority

Yes

Provides a mechanism for establishing dependencies between projects at deployment time. When multiple deployments are queued they will be processed in order of priority (lowest priority takes precedence). The scope of the priority is defined by the Priority Scope.

Priority Scope

No

Defines the scope in which priorities are evaluated at runtime. Application scope indicates this project's priority will be evaluated against other projects in this application only. Folder scope indicates this project's priority will be evaluated against other projects in this application's parent folder. Global scope indicates this project's priority will be evaluated against all other FlexDeploy projects.

Description

No

A description of the project.

Build Workflow

Yes

The build workflow to run for this project's builds. Build workflow will execute on specified Build Instance.

Build Instance

Yes

The instance to run the build workflow on.

Deploy Workflow

Yes

The build workflow to run for this project's deployments.

Deploy Instance(s)

Yes

One or more deploy instances available to run deploy workflows on.

SCM Configuration

The SCM configuration is based on the SCM Type that is selected for the project, and is currently applicable for SubVersion, Git, Microsoft TFS, CVS, ClearCase, and PVCS SCM types only.

SCM Configuration values (except Instance drop down) are specified as Groovy scripts. This provides users with more flexibility, as values for each element is evaluated for Project Version and Stream being used for Build. Refer to the table below.

Variable Name

Description

ProjectName

Name of current project being built.

StreamName

Name of current stream being built.

MainStream

Evaluates to true if current stream being built is main stream.

ProjectVersion

Project version name being built.

StreamAttribute1

Attribute 1 of stream being built.

StreamAttribute2

Attribute 2 of stream being built.

StreamAttribute3

Attribute 3 of stream being built.

Subversion SCM Configurations

For Subversion one or more project sources can be configured with the details as described in the table below. FlexDeploy provides flexibility by supporting groovy script to define these values. Click on the expression button to include variables as part of the value. Additional sources can be added by Clicking on the Add Source button.

Defaults for Subversion source configurations can be configured using Project SVN Setup Defaults. This can be configured such that

  1. All Subversion project sources will get same values (including SVN Instance), or
  2. you can configure defaults by SVN Instance.

First approach works well if you have single Subversion repository. If you have multiple Subversion repositories in your environment, then you can utilize second approach to configure project based on some criteria. You can accomplish this by placing an "if" statement within Groovy script for the defaults. With this approach all attributes in Subversion configurations will be empty initially, and when user selects SVN Instance, configuration values will be defaulted appropriately.

In example below, if Project Name is Project1 and Stream Names are trunk and fixpack1, here is what will be actual values of various configurations.

  • Trunk Path (used only for main stream) - /trunk/HumanResources/Project1
  • Branch Path (used for all streams other than main) - /branches/HumandResources/Project1/fixpack1
  • Tag Path - /tags/HumanResources/Project1/1.0.0

This structure does not need to match with your Subversion repository. You just need to define Groovy scripts to match your repository structure.

Field Name

Required

Description

SVN Instance

Yes

An SCM Instance representing a Subversion repository. See Instances section of this guide to create SCM Type Instance. Refer to the Instances page for more on SCM Instances.

Trunk Path Script

Yes

Path for the trunk within selected repository.

Branch Path Script

No

Path for the branches within selected repository. Use StreamName variable to identify branch name used at runtime.

Tag Path Script

No

Path for the tag within the selected repository. Use ProjectVersion variable to specify identifier of current build.

Checkout Folder Script

Yes

Optional sub-folder to use for export/checkout operations during build workflow execution.

Git SCM Configurations

For Git one or more project sources can be configured with the details as described in table below. FlexDeploy provides flexibility by supporting groovy script to define these values. Click on expression button to include variables as part of the value. Additional sources can be added by Clicking on the Add Source button.

Defaults for Git source configurations can be configured using Project GIT Setup Defaults. This can be configured such that

  1. All Git project sources will get same values (including Git Instance), or
  2. you can configure defaults by Git Instance. First approach works well if you have single Git repository.

If you have multiple Git repositories in your environment, then you can utilize the second approach to configure the project based on some criteria. You can accomplish this by placing an "if" statement within Groovy script for the defaults. With this approach all attributes in Git configurations will be empty initially, and when user selects Git Instance, configuration values will be defaulted appropriately.

In example below, if Project Name is Project1 and Stream Names are master and fixpack1, here is what will be actual values of various configurations.

  • Branch Name - master or fixpack1 depending what is selected during Build request
  • Tag Name - 1.0.0

This structure does not need to match with your Git repository. You just need to define Groovy scripts to match your repository structure. In many cases you might be sharing Git repository with other folders, so you may have to configure Sparse Checkout Folders for efficient build process.