Skip to content

Overview

There are 7 strategic pillars for individual moments of service for customer engagement which is explained in below diagram.

Some Terminology

Customer Solution: Refers to the code base which consists of customer specific code developed by the customer.
Customer Solution Developer: Refers to system-end-users who will be doing code, build and delivery management of the customer solution.
Customer Baseline: Refers to the code base which only consists of core IFS components. This includes any service or feature updates of IFS Cloud applied to the code base.

Main components of the Solution

The main components of the IFS Lifecycle Experience Solution are;

IFS Lifecycle Experience Portal - This Web Portal will serve as the main point of entry to the IFS Lifecycle Experience for the end-users of the system. Administrators will use the portal to setup, manage and decommission customer solutions. End users will use this portal to trigger actions related to Customer solution development. Applying Service Updates released by IFS and Investigate support issues related to software faults in the underlying product 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 requires to be onboarded to the Azure AD prior to gaining relevant role-based access to the Lifecycle Experience functionality.

IFS Developer portal - IFS Developer portal is published on 'developer.ifs.com' Customer Solution Developers will download 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 - Prior to accessing the database or the build home 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 LE portal 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 LE Web Portal, the 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 Lifecyle Experience. These environments can be provisioned from different stages of the customer solution as requested by the user. A single azure resource group 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 disruption in services offered by IFS.

The 3 components - Azure Dev Ops Services, Azure Resources and the IFS Lifecycle Experience Portal together forms the Customer Solution Cloud Build Place.

User Authorization of the System

There a six different user roles in the Lifecycle Experience solution namely; Build Place User Admin, IFS Product Support Developer, IFS Product Support Consultant, Customer Solution Consultant, Customer Solution Developer and Technician.

The following tables describes the user role permissions for the LE portal, Azure DevOps (ADO), and Release Update Studio.

User Role Permissions for LE portal Functionality

BPUserAdmin 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
BPUserAdmin 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
Environment Management
BPUserAdmin 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
Delivery and Deployment
BPUserAdmin 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
Operational Management
BPUserAdmin 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
Job Table Yes Yes Yes Yes Yes Yes
Build Place Translation Read Read, Write Read Read Read Read
Refresh Portal Cache No No No No No No
Azure DevOps (ADO)
BPUserAdmin 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
BPUserAdmin 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 No Yes Yes 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
Complete Release Update Process / Cut-over Yes Yes No No No No
Abort Release Update Process Yes No No No No No

Apart from the newly introduced functionality in the Release Update Studio, the functionality similar to that of the Build Place view, will be granted similar user role permission sets.

IFS Lifecycle Experience Portal

When logging into the IFS Lifecycle Experience Portal, initially the user will be redirected to the IFS Azure Active directory login page to log into the portal. The User can log into the portal using his/her credentials which have been previously registered with IFS.

This is the "My Build Places" view (default home page) which will appear after the user logged into the portal

After selecting one of the available build places, the user can view the build-place details. The following images contain the sub-components in the build-place detail view.

Customer Information

Repository Information

VPN Details

Users needing to access the database or the build home of a build place environment need to first configure a connection to the build place VPN from the user workstation

Build place environment information

Logout

Repository Structure

The IFS Lifecycle Experience cloud build place contains several repositories.

Customer Baseline Repository
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. Customer-baseline contains only a single branch (master branch) and a single tag at the beginning. Number of tags will grow along with time. Merges to the master branch of customer-baseline does not require pull requests at any point. It is a read only repository to all build place users. Update strategy of the customer-baseline is straight forward.

Customer Solution Repository
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 customer solution repository needs to be uplifted in order to be compatible with new service update or release update. Initially customer solution repository will have the same set of meta files as customer baseline repository and will change over the time period when customizations and configurations are done. <<<<<<< HEAD

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 attached to user roles of customer solution developer, customer solution technicians 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 will have the read access to customer solution repository and refer the user roles permission in User Role Permissions for LE portal Functionality =======

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 attached to user roles of customer solution developer, customer solution technicians 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 will have the read access to customer solution repository and refer the user roles permission in User Role Permissions for LE portal Functionality

3a47c483682355119f9dca9208188d0fe3570c87

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 build place creation, the selected solution set is committed to both the customer baseline and customer solution repositories. For the customer solution repository, after the solution set has been committed, an intial sanity build followed by an initial delivery is created. This intial delivery will be the baseline for the succeeding deliveries created in the build place.

Once the Build Place has been created successfully, the following set up must be done before it can be used;