Generic Package-Based Projects
FlexDeploy provides Generic project type to implement customized package-based deployment for specific type of artifacts. In future, FlexDeploy will provide ability to create specific project type and it's metadata but in meantime Generic project type should be utilized.
Where is this applicable?
This is useful when requirement is to track deployment of individual file. Make sure to check Package-Based flag when creating this project and select Generic as project type. Here are some scenarios where you can utilize Generic project type.
- Source control system has individual files defining WebSphere resource configuration and they needs to be deployed and tracked individually.
- Source control system has individual XML files exported from Oracle Data Integration objects and they need to be deployed and tracked individually.
When is this not applicable?
If you are working with all files of specific source folder to deliver compiled artifact and artifact file is deployed as single unit, you can just use regular projects, i.e. do not check Package-Based flag when creating project. For example,
- Source control system has set of Java files and libraries and it needs to be compiled as Jar file and it needs to be coped to specific folder during deployment.Â
Object Type Identification
- As there is only one object type called File, all files are detected as that type.
- Files are sorted alphabetically.
- In general, you will extract files from SCM like Git, Subversion when using Generic project type.
Object Type Code
- FILE
- Display Name - File
Attributes
Name | Code | Description | Default Value | Supported Values |
---|---|---|---|---|
Source | SOURCE | This is hidden and defaults to SCM | SCM | SCM |
Target Location | TARGET | Target Folder to place the file into. You can ignore this if value is not necessary for deployment. | ||
Attribute 1 | ATTRIBUTE1 | You can ignore this if value is not necessary for deployment. | ||
Attribute 2 | ATTRIBUTE2 | You can ignore this if value is not necessary for deployment. | ||
Attribute 3 | ATTRIBUTE3 | You can ignore this if value is not necessary for deployment. | ||
Attribute 4 | ATTRIBUTE4 | You can ignore this if value is not necessary for deployment. | ||
Attribute 5 | ATTRIBUTE5 | You can ignore this if value is not necessary for deployment. |
Related Project Properties
Name | Code | Description | Default Value | Supported Values |
---|---|---|---|---|
Considerations
- Workflows used by Package-Based projects must use plugin operations compatible with Package-Based deployment capability. Refer plugin guides documentation but in this case use
packageExecute
operations from Unix Shell, Windows Shell and Powershell plugins. Other plugins like File can work with Generic project type, but that is not recommended to avoid confusion on various properties. Plugin SDK is not available for Package-Based operations yet. - Build workflow can be created with simple script code like
echo $SOURCE_FILE
. Files are automatically extracted from source control system when build is executed for Package-Based projects. - Deploy workflow should implement script necessary to deploy individual file.
- Note that script provided with packageExecute is invoked for each individual file by plugin.
- As always build and deploy workflow can define Project or Environment Instance scoped properties.
- style