Versioning a Fabric project in SCM

Even though the Fabric Console supports versioning of apps, you may want to version your Fabric projects in a source control management system (SCM) instead.

A Fabric app directory must contain unzipped packages of the app. To obtain a zipped package, export an app from the Fabric Console. When you extract the zip file, it creates an export folder for the app source. Make sure that you check-in the Fabric app folder to your repository.

IMPORTANT: Currently, the only SCM supported by App Factory is Git. You can choose a Git vendor based on your preference, for example: GitHub, Bitbucket, Gitlab, AWS CodeCommit, Azure Repos, or a Git server that you're running locally.

You can follow different strategies to create a repository for your Fabric app. For example: Your repository can contain a single project for a Fabric app at the root, this means that your folder structure will look similar to the following screenshot.

For this repository structure, the FABRIC_DIR parameter must remain empty. While this is the simplest strategy for a repository, it may not be the best fit for Fabric apps that leverage custom Java code. Placing the Fabric application at the root leaves no room to add the Java code with it. Therefore, you will need to manage your Java source code in a different repository.

NOTE:
  • If you host the Java assets in a separate repository, you need to prefix the repository name to the Java projects path in the build parameters. For more information, refer to JAVA_PROJECTS_DIR.
  • You can also refer to a sample repository on GitHub, which contains a Fabric app and the dependent Java assets.

Monorepo Strategies in SCM

A common practice to create a repository is to use a Monorepo strategy. A Monorepo for App Factory may contain different sub-directories for different Fabric Apps and their Java dependencies, such as Preprocessors, Postprocessors, and Java services. The Monorepo can also contain Maven configuration files (pom.xml) to manage the Java assets and compiling the source to generate binaries.

You can use the following approaches to implement a Monorepo for your Fabric projects and Java dependencies. You can also use these approaches to version your Fabric projects and Visualizer projects in the SCM.

In the common subdirectory approach, the Fabric project and Java assets together in the same subdirectory, but in different folder structures. Every Java asset contains a Maven config file (pom.xml) to manage the Java assets and to package them into the Fabric App.

NOTE:
The parent Java directory can also contain a common Maven config file to customize the Java packages.

In the multiple subdirectories approach, every asset is stored in a subdirectory that contains the source file, a Maven POM file, and a gitignore file. The parent subdirectory can also contain a common Maven POM file.

 

NOTE:
If you are already using an existing structure (refer to the screenshot) of the Fabric App in Git for the App Factory jobs, you can continue to use the same.

If you want to integrate Java assets from the source code into the Fabric app, you can migrate to one of the Monorepo structures that are mentioned earlier in this section. With the Monorepo strategy, you can easily track and use the buildFabricApp pipeline. You can use Git commands to retain the commit history while migrating to the new structure.