Infor XtendM3 - Guidelines for securing your extensions using a version control system

Introduction:

XtendM3 Extensions are required to be version-controlled outside of M3 using a version-control system. This is a mandatory key requirement for approving extensions for deployment to production. Version controlling the extensions helps us to:

1. Have better visibility of what has changed and by whom, facilitating understanding of the code and easier troubleshooting later on.

2. Ease collaboration between different developers.

3. Provide a centralized overview of current extensions in different tenants.

4. Compile and test extensions regularly on every change to ensure that the extension has not been broken.

Repository Format:

The recommended approach for storing the extension is within a Maven project stored in a Git Repository. Maven is utilized to manage the build and test lifecycle of extensions locally. By using Maven, you can compile your extensions locally with the SDK to ensure the code is compilable. Additionally, unit tests can be created and run to simulate and debug locally or integrated into the build lifecycle and pipeline on the repository to continuously build and test the extensions with every push to the repository.

Local XtendM3 Workspace:

The local XtendM3 workspace refers to the development environment set up on an individual developer's machine for working on XtendM3 extensions. This workspace typically includes the necessary tools, such as the M3 SDK, IDE (Integrated Development Environment), and version control system (e.g., Git), configured to allow developers to efficiently develop, test, and Export extensions locally before pushing changes to the shared repository. 

ACME Corp Template Repository:

To begin, we can initiate the process by setting up a local workspace utilizing the ACME Corp Template available in the Infor Cloud Github repository. This template serves as a foundational framework for configuring the development environment.

Additionally, it's recommended to utilize this template when setting up customer repositories to version control live extensions. This ensures consistency and standardization across different projects and facilitates seamless collaboration among team members.

Please refer to the following link for the ACME Corp Template: ACME Corp. XtendM3 Extensions

To begin, open the pom.xml file in your local workspace and ensure that the latest version of the Maven plugin and Xtend M3 version is being used.

Xtend M3 Maven plugin : 

1. Navigate to the "build" section and locate the "xtendm3-maven-plugin" plugin.

2. Check the version currently used. The latest available version of the Maven plugin can be found here

  

Xtend M3 SDK  : 

1. Navigate to the "build" section and locate the "XtendM3-sdk" plugin.

2. Check the version currently used. The latest available version of the XtendM3 SDK  can be found here and the screenshot for your reference.

You can lint and export the extensions you're working on locally using the XtendM3 Maven plugin.

Lint :

To lint the extensions defined in your project, navigate to the root of the project and run the following command:

 Command - mvnw.cmd xtendm3:lint (Windows)

Export :

To export the extensions defined in your project, navigate to the root of the project and run the following command:

 Command - mvnw.cmd xtendm3:export (Windows)

GitHub Guide: 

Setting up XtendM3 Extensions Version Control System

1. Create an account on GitHub if you don't already have one. Please refer to the following link for creating an account: Creating an account on GitHub - GitHub Docs

2. Create an organization on GitHub in the customer's name.

3. Add the customer to the organization as an administrator.

4. Create a repository from the acme-corp-extensions template under the created organization, naming it xtendm3-extensions.

By following these steps, you'll establish the version control system for XtendM3 Extensions using GitHub, ensuring organized and collaborative development practices for the customer's projects.

Branching : 

The recommended branching strategy involves having the master branch serve as the production branch, containing all extensions deployed in production. Additionally, a separate branch should be created for each tenant, such as DEM and PRD.

For example, we would have one master branch and one dem branch. Developers will primarily work on the dem branch during development. Once changes on the dem branch are fully verified, approved, and signed off, they can be merged into the master branch. This merging process effectively applies the changes made on the dem branch to the master branch, ensuring that only verified changes are deployed to production.