Overview¶
The application life cycle experience has four phases - Explore, Define, Build and Use. Out of these four phases IFS Lifecyle Experience on IFS Cloud 21R1 targets the Build phase.
Some Terminology¶
Customer Solution: Refers to the entire code base which consists of core IFS components and any 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 release 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 Cloud Master Repository This consists of all IFS Cloud core releases.
IFS Developer portal 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.
Azure DevOps Services This consists of Azure repositories and Azure pipelines which are used for code management, build management and delivery management of the customer solution.
Azure Resources This comprises of self provisioned Azure VMs consisting of IFS Cloud 21R1 Environments ordered by the users of the IFS Lifecyle Experience solution. The environments can be provisioned from different stages of the customer solution code base as requested by the user. A single azure resource group will be created per customer solution. It also consists of Azure Storage services used for storing Artifacts and deliveries of the customer solution.
IFS LifeCycle Experience Portal This portal will be used by the 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.
Authentication to all of the above components is managed through the IFS Azure Active Directory (Azure AD). The 3 components - Azure Dev Ops Services, Azure Resources and the IFS Lifecycle Experience User 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 |
| 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 |
| 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 |
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 | 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 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.
Customer Solution Repository
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.
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 customer's required version of the IFS product is pulled from the master release repository to create the customer baseline repository, which in turn is cloned to create the customer solution repository.
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 initial sanity build followed by an initial delivery is created. 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 set up must be done before it can be used;
21R1 to 21R2 Differences¶
| Functionality | 21R1 | 21R2 |
|---|---|---|
| Implementation Mode | IFS sales team must select the option – upgrading customer Yes / No, as part of the onboarding process of the customer. | Customer has the opportunity to select the mode of implementation option of upgrading, new or reimplementation |
| Impact Analyzer | Update Analyzer only supported analyzing the contents from the master branch given the customer-solution repository. Repo URLs should be entered manually by the user. | Update Analyzer supports analyzing contents from not only the master branch but also to analyze contents in a delivery branch and release-update branch.Repo URLs are fetched automatically when .upda files are opened from Update Analyzer. |
| Configuration Analyzer | Previous tool was used up to App10 and was able to do the configuration analysis using the interface report. This was a separate tool outside the IFS application. | Current tool is implemented within the Aurena client itself and supporting all IFS Cloud versions. This tools supports custom entities and customer attributes when analyzing the configurations. This tool supports configuration analysis to be done in both Build Place and Use Place provided all the configurations are maintained. |
| Build Place Logs | Pipeline URLs are used to view the status of a Build Place Activity | Logs are being introduced in a separate screen. Users can use the logs instead of Pipeline URLs. Accordingly, access to Pipeline URLs would be no longer be available. |
| Build Home | Build Home was shared in the Build Place environments | Build Home is not shared in the Build Place environments and Developer Studio now has the capability to do Aurena development without Build Home. |
| Environment (VM) Operating System | MS Window | Introduced Linux as OS as part of the Build Place performance optimization initiative. |