Overview¶
There are 7 strategic pillars for individual moments of service for customer engagement which is explained in the diagram below. This is the user journey that IFS envisages our IFS Cloud customers to go through from the first touch point up to live deployment of the solution.
The Lifecycle Experience section of the documentation is related to the design and delivery stages of this journey.
Some Terminology¶
Customer Solution:¶
Prior to 22R2: Refers to the entire code base which consists of core IFS components and any customer-specific code developed by the customer.
22R2 & Beyond: Refers to the codebase which consists of customer-specific code developed by the customer.
Customer Baseline:¶
Prior to 22R2: Refers to the code base which only consists of core IFS components. This includes any service or release updates of IFS Cloud applied to the code base.
22R2 & Beyond: Refers to the codebase which only consists IFS Cloud configuration files. This includes corresponding service/release update version maintenance, language translation and core IFS component configuration files.
Find the High-level architecture of the IFS Cloud in the Architectural Overview section of the Technical Documentation.
Main Components of the Solution¶
The main components of the IFS Lifecycle Experience Solution are;
IFS Lifecycle Experience Center - The Lifecycle Experience Center (LEC) serves as the main point of entry to the IFS Lifecycle Experience for the end-users of the system. Administrators use the LEC to setup, manage, and decommission customer solutions. The end users use this platform to trigger actions related to customer solution development. Applying Service Updates released by IFS and investigating support issues related to software faults in the underlying product are also hosted in the solution.
Azure AD - Authentication to all the above components is managed through the IFS Azure Active Directory (Azure AD). All users accessing the system are required to be onboarded to the Azure AD before gaining relevant role-based access to the Lifecycle Experience functionality.
IFS Developer Portal - The IFS Developer Portal is published on developer.ifs.com. The Customer Solution Developers will download the IFS Developer tools required for development on IFS Cloud from the Developer Portal to their local workstations.
IFS Cloud Master Repository - Contains all the source files for IFS Cloud core releases.
VPN - Before accessing the database of a Build Place environment, a connection to the Build Place via Azure VPN gateway needs to be established from the user's workstation.
Artifactory - ALE solution delivery artifacts, binaries, packages, files, logs, and containers are stored in the JFrog Artifactory. This functions as the central hub for storing and retrieving all key artifacts used within the Lifecycle Experience Platform.
GitLab CI/CD - The majority of the backend automation that is triggered via the Lifecycle Experience Center and its integrations are orchestrated using the GitLab CI/CD pipelines, which build, deliver, and manage the infrastructure needed for the Lifecycle Experience.
Azure DevOps Services - This consists of Azure repositories hosting the customer solution and Azure build pipelines hosting some of the LE platform’s legacy automation.
Azure Resources - This comprises of resources belonging to the ALE Central resources as well as resources existing within customer subscriptions. The central ALE resources include the Lifecycle Experience Center (LEC), central table storage, key vaults, and container registries. The customer-specific resources consist of self-provisioned Azure VMs, consisting of IFS Cloud Environments ordered by the users of the IFS Lifecycle Experience. These environments can be provisioned from different stages of the customer solution as requested by the user. Several Azure resource groups will be created per customer solution which groups the customer-specific resources under it.
Other Integrations - The Lifecycle Experience interacts with other services and platforms like the IFS Cloud and Service Now. The IFS Cloud is a web-based ERP solution and Service Now is used for onboarding customers, migrating deliveries to Use Place and for reporting disruptions in services offered by IFS.
The 3 components - Azure Dev Ops Services, Azure Resources, and the IFS Lifecycle Experience Center together form the Customer Solution Cloud Build Place.
User Authorization of the System¶
The following tables describe the user role permissions for the Lifecycle Experience Center (LEC), Azure DevOps (ADO), Build Place, Use Place Environments, and Release Update Studio.
User Role Permissions in Lifecycle Experience Center (LEC)¶
As part of the updated Lifecycle Experience Center layout, several new studios have been incorporated to enhance modularity and optimize the user experience. Each studio is purpose-built to support specific functionalities and workflows, enabling users to engage with distinct system components in a structured and efficient manner. The newly introduced studios, along with their enhancements, are outlined below:
| Studio | Functionality |
| Admin Studio | A centralized platform for granting/ revoking user roles and authentication. |
| Build Studio | The central hub for managing operations related to the Build Place. The new release delivers a range of enhancements aimed at improving functionality, performance, and user experience |
| Environment Studio | Available only for Cloud customers. A dedicated platform for overseeing Cloud Use Place environments. |
| Insight Studio | A unified reporting solution designed to collect, analyze, and present insights across the platform. |
| Access Studio | A centralized system designed to support the administration of security configurations within the IFS AI platform. It provides a unified environment for managing key security-related tasks, including: Authentication policy configuration, Client setup and management, Integration with IFS Cloud Remote installations |
Due to the new studio layout, distinct user roles have been defined to operate exclusively within each studio. All existing user roles are migrated to support the studio-specific functionality.
| Studio | Studio-Level User Role |
| Admin Studio | Customer Admin |
| Build Studio | Build Studio Admin |
| Technician | |
| Customer Solution Developer | |
| Customer Solution Consultant | |
| IFS Product Support Developer | |
| IFS Product Support Consultant | |
| Environment Studio | Environment Studio Admin |
| Insight Studio | Report Studio Admin |
| Access Studio | Customer Admin |
If you are already assigned a user role, please check how the existing user role is replaced with the new user roles in the LEC. For more information, please refer to: Migration of existing LE Portal user roles to new LEC user roles.
The tables below outline user role authorizations for the detailed list of functionalities in the Build Place of Build Studio and Release Update Studio.
Initial Build Place Related Activities¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| BP Activation | Yes | No | No | No | No | No |
| Solution Set Update | Yes | No | No | No | No | No |
| BP Configuration of Implementation Mode | No | Yes | No | No | No | No |
Subsequent Build Place Related Activities¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Analyze Service Updates | No | Yes | Yes | No | Yes | No |
| Manual Sanity Build | No | Yes | No | No | No | No |
| Create Build Home | No | Yes | No | No | No | No |
Build Place Environment Management¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Build Place Environments (Topic, Dev, Baseline, QAS) | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete |
| VM Power operations | Yes | Yes | Yes | Yes | Yes | Yes |
| Extend Environment Lifespan | No | Yes | No | No | No | No |
| Renew IFS Cloud Certificate | No | Yes | No | No | No | No |
Delivery and Deployment¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Create and Delete Deliveries | No | Yes | No | No | No | No |
| Approve Deliveries | Yes | Yes | Yes | Yes | Yes | Yes |
| Download delivery | Yes | Yes | Yes | Yes | Yes | Yes |
| Manage deployment | Yes | Yes | No | No | No | No |
| Generate password for Cloud Customers | Yes | Yes | No | No | No | No |
Operational Management¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Build Place Settings/Environments Quota | Read | Read | Read | Read | Read | Read |
| Build Place Settings/Change Daily Scheduled Shutdown Time | Read | Write | Read | Read | Read | Read |
| Build Place Settings/Feature Management/Enable TDM(Test Data Management) | Read | Read | Read | Read | Read | Read |
| Build Place Settings/Feature Management/Enable ICAM | Write | Read | Read | Read | Read | Read |
| Build Place Settings/Remote Deployment Service Provider (Only for Remote BPs) | Read, Write | Read | Read | Read | Read | Read |
| Job Table | Yes | Yes | Yes | Yes | Yes | Yes |
| Build Place Translation | Read | Read, Write | Read | Read | Read | Read |
Azure DevOps (ADO)¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Customer Solution Repository (ADO) | No | Read, Write, Approve Pull Request, Merge | Read, Write, Approve Pull Request, Merge | No | Read | No |
| Customer Baseline Repository (ADO) | No | Read | Read | No | Read | No |
| Apply Service Updates to Baseline (ADO) | No | Yes | Yes | No | No | No |
| Apply Service Updates to Solution (ADO) | No | Yes | Yes | No | No | No |
Release Update Studio Related Activities¶
| Build Studio Admin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Impact Assessment | Yes | Yes | Yes | Yes | Yes | Yes |
| Request Release Update | No | Yes | Yes | No | No | No |
| Apply Release Update in Baseline Repo | No | Yes | Yes | No | No | No |
| Customization Upliftment Preparation | No | Yes | Yes | No | No | No |
| Apply Release Update in Solution Repo | No | Yes | Yes | No | No | No |
| Update Solution Set | Yes | No | No | No | No | No |
| Impact Analysis | No | Yes | Yes | No | Yes | No |
| Release Update Studio Environments (Topic, Dev, Baseline) | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete | View, Create, Delete |
| Test Data Update (Applicable only for the Build Places that have Test Data Management feature enabled) | No | Yes | No | No | No | No |
| Complete Release Update Process / Cut-over | No | Yes | No | No | No | No |
Use Place Environment Management¶
| Environment Studio Admin | Report Studio Admin | Build Studio-Specific Roles | Admin Studio- Specific Role | |
| Schedule Deliveries | Yes | No | No | No |
| Clone Environments | Yes | No | No | No |
Supporting Functionality¶
| Customer Admin | Report Studio Admin | Build Studio-Specific Roles | Environment Studio- Specific Role | |
| Insight Studio Reports | No | Yes | No | No |
| Access Studio | Yes | No | No | No |
IFS Lifecycle Experience Center¶
When logging into the IFS Lifecycle Experience Center, the user will be redirected to the IFS Azure Active Directory login page. The user can log in using the credentials they have previously registered with IFS.
After a successful login to Azure, the user can view the Lifecycle Experience Center. Go to Build Studio in the Lifecycle Experience Center (LEC) to view Build Places.
All the Build Places the user is registered for are inside the Build Studio of the Lifecycle Experience Center (LEC).
Select one of the available Build Places to view the Build Place details. The following images contain the sub-components in the Build Place detail view.
Customer Information
Repository Information
Prior to 22R2:
22R2 & Beyond
VPN Details
To view VPN Details, click VPN Connection from the left main sidebar.
Users who need access to the database or the Build Home of a Build Place Environment should first configure a connection to the Build Place VPN from the user workstation. The Build Home of a Build Place Environment is the folder of the source code and build files that belong to the environment creation. Read more on configuring a connection to the Build Place VPN on : Configure Point-to-Site VPN on User Workstation.
Build Place Environment Information
Logout
Repository Structure¶
The IFS Lifecycle Experience Cloud Build Place contains 2 repositories: Customer Baseline Repository and Customer Solution Repository.
Customer Baseline Repository¶
Prior to 22R2:
The Customer Baseline Repository is a clone of the master release repository. Initially, the customer's required version will be pulled from the master repository. The Customer Baseline will be tagged with the same tag presented when pulling from the master repository. The Customer Baseline will contain a single branch (master branch) and a single tag at the beginning. However, the number of tags will grow along with time. The Baseline Repository holds all the IFS components released for that specific version (tag). The merges to the master branch of the Customer Baseline do not require pull requests at any point. It is a read-only repository for all Build Place users. The update strategy of the Customer Baseline is straightforward. When there is a need for a new service update, an IFS Support Developer pulls the updated version from the master repository and pushes it directly to the Customer Baseline Repository.
22R2 & Beyond:
The Customer Baseline Repository is a representation of core releases that have been taken to the Build Place. It contains meta files such as,
- fndbas/source/version.txt
- fndbas/solutionset.yaml
- fndbas/server/translation/translationusage.json
- git related files
Initially, the Customer Baseline will be tagged with the version which is used to initialize the Build Place. The Customer Baseline contains only a single branch (master branch) and a single tag at the beginning. The number of tags will grow along with time. The merges to the master branch of the Customer Baseline do not require pull requests at any point. It is a read-only repository for all Build Place users. The update strategy of the Customer Baseline is straightforward.
Customer Solution Repository¶
Prior to 22R2:
The Customer Solution is a cloned repository of the Customer Baseline. It has master as the main branch and many topic branches created by developers. The merge strategy for Customer Solution is designed in two parts. When initializing the Customer Solution Repository, it is basically cloning the entire code from the Customer Baseline. After the initial commit is done, a policy is introduced to accept merges to the master only via pull requests. Reviewers for the created pull request will be automatically included from the customer solution developer, customer solution technicians, and IFS developers security groups. It needs at least a single approval from any of the reviewers. The update strategy for Customer Solution is to pull the necessary tag from Customer Baseline to a topic branch, solve any merge conflicts, push to the remote, and merge to master via pull request. The Customer Solution will be visible to all the users of a Build Place with repository access granted.
22R2 & Beyond:
The Customer Solution Repository includes customizations and configurations with a specific tag to a core release. This would mean if a customer applies a new release or service update, the customer solution repository needs to be uplifted in order to be compatible with the new service update or release update. Initially, the customer solution repository will have the same set of meta files as customer baseline repository and will change over the time when customizations and configurations are done.
It has master as the main branch and many topic branches created by developers. Customer solution repository accept merges to the master only via pull requests. When the pull request is created, the Build Place users: customer solution developer, customer solution technician, and IFS developers security groups will be automatically assigned as Reviewers. It needs at least a single approval from any of the reviewers. All the Build Place users with developer access (Technician, Customer Solution Dev & IFS Product Support Dev) will have either read or write access to Customer Solution Repository. More information can be found in User Role Permissions for LEC Functionality.
Overview of Build Place¶
When a new Build Place has been requested, it is created using the purchased version of the IFS Cloud product and the requested solution set.
During the Build Place creation, the selected solution set is committed to both the Customer Baseline and Customer Solution Repositories. After the solution set has been committed for the Customer Solution Repository, an initial sanity build takes place followed by an initial delivery creation. This initial delivery will be the baseline for the succeeding deliveries created in the Build Place.
Once the Build Place has been created successfully, the following setup must be done before it is used;