Overview¶
There are 7 strategic pillars for individual moments of service for customer engagement which is explained in below diagram. This is the user journey that IFS envisage our IFS Cloud customers to go through from first touch point upto live deployment of the solution.
The Lifecycle Experience section of the documentation is related to 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 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 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. 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 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, Technician, Customer Solution Developer, Customer Solution Consultant, IFS Product Support Developer and IFS Product Support Consultant.
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¶
Initial Build Place Related Activities¶
| 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 |
Subsequent Build Place Related Activities¶
| 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 |
| Renew IFS Cloud Certificate | 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 |
| Generate password for Cloud Customers | 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 |
| 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)¶
| 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 |
Release Update Studio Related Activities¶
| 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 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 |
| 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 |
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.
Supporting Functionality¶
| BPUserAdmin | Technician | CustomerSolutionDev | CustomerSolutionConsultant | IFSProductSupportDev | IFSProductSupportConsultant | |
| Service Insight Studio | Yes | No | No | No | No | No |
| Service Access Studio | Yes | No | No | No | No | No |
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
Prior to 22R2:
22R2 & Beyond
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 2 repositories; Customer Baseline repository and Customer Solution repository.
Customer Baseline Repository¶
Prior to 22R2:
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 used when pulling from master repository. Customer-baseline will contain only a single branch (master branch) and a single tag at the beginning. Number of tags will grow along with time. It holds all the IFS components released for that specific version (tag). 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. When there is a need for a new service update, an IFS Support developer will pull that certain update version from the master repository and push directly to the customer baseline repository.
22R2 & Beyond:
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¶
Prior to 22R2:
Customer-solution is a cloned repository of the customer-baseline. It has master as the main branch and many topic branches created by developers. Merge strategy for customer-solution is in two parts. When initializing the repository, it is basically cloning entire code from customer-baseline. After the initial commit is done, a policy is introduced to accept merges to the master only via pull requests. Reviewers to the created pull request will be automatically included from customer solution developer, customer solution technicians and IFS developers security groups. It needs at least a single approval from any of the reviewers. Update strategy for customer-solution is pull necessary tag from customer-baseline to a topic branch, solve any merge conflicts, push to the remote and merge to master via pull request. Customer-solution will be visible to all the users of a build place with repository access granted.
22R2 & Beyond:
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.
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 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 LE portal 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 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;