This section details the end-to-end process by which a customer can request a build place to develop their solution and how it is made available for use by the development team.
The processes highlighted in the above diagram are explained in the succeeding sections.
IFS Lifecycle Experience Initialization¶
A customer onboarded to IFS can request the Lifecycle Experience service to develop a customized version of the purchased IFS product.
Upon this request, the customer's IFS account manager will initialize IFS Cloud Lifecycle Experience for the customer. This includes the creation of a cloud hosted Build Place and a Use Place (the Use Place is created only if the customer opts for residency option "Cloud").
To request the Build Place (and Use Place), the IFS account manager will need to use the "IFS Cloud Lifecycle Experience Initialization" form accessed from the Service-Now IT portal.
The following section describes the information filled in the request form;
- To access the form, navigate to Service-Now IT portal, select Request an Item, select General category and then open "IFS Cloud Lifecycle Experience Initialization" form
- Select the LE enabled customer's Account
- Set an IFS representative- an IFS employee, usually the customer's IFS account manager
- Select the person for whom the LE initialization is requested for- select from a list of customer users connected to customer account
- Specify if the customer is an Upgrade Customer - Yes or No
- Set an IFS Project Manager and IFS Technical Project Manager - select from a list of IFS employees
- Set a Customer Project Manager and Technical Project Manager - select from a list of customer users connected to the customer account
- Set Azure related information - This includes selecting the Azure Region for the Build Place and the Azure Region and Server time zone for Use Place (if requested)
- Set the Product Release required by customer - select from a list of IFS Cloud releases
- Set User Administrators for the Build Place- select from a list of customer users connected to the customer account. BP user administrators will be able to activate the Build Place and grant access to it.
Additional information to be specified if a Use Place is to be created includes;
- IFS Cloud Template size
- IFS Cloud Database size
- Add-ons to be enabled - services available include Crystal Web Service (CWS), Demand Planning Server (DPS), Planning Scheduling Optimisation (PSO) and Maintenix (MXI)
- Network connectivity- includes setting the IP Whitelist, VPN requirement (Yes/No), Number of VPN connections (if VPN connectivity is required) and requirement for ExpressRoute (Yes/No).
After the customer details and requirements are correctly filled, the form can be submitted.
Once the request has completed, the customer owned Build Place is created in an "Initialized" state and the Build Place User Administrators defined previously will be informed via email on the availability. The Use Place will also be created, if the customer had opted for Cloud hosted residency.
Next, the User Administrators will need to Activate the Build Place and then grant access to the development team before they can begin their work in the Build Place. Please refer the next sections for this.
Activate Build Place¶
IFS Cloud onboarding team would activate a Build Place. The process of creating a Build Place can be view in IFS Lifecycle Experience Initialization Build Place should go through below status.
When the Build Place is in “Initialized” status, IFS onboarding team can use Lifecycle Experience portal to activate the Build Place. During activation solution set will be fetched from IFS Internal System and committed to the customer baseline and customer solution repositories. Once the activation completes Build Place state will be changed to "Active" while during the activation process the status will be “Activating”. It is estimated that 3- 6 hours of processing time would require to activating a Build Place, depending on whether it is a customer upgrading from a previous IFS Applications release or a new IFS Cloud deployment.
The progress of the Build Place activation can be viewed from pipeline URL (Go to jobs in Lifecycle Experience portal. Find the relevant job for the activating Build Place request and click the pipeline URL).
Backend Process of Initialization to Activation¶
When the Build Place is in the "Initialized" status, the next step for user to process activation. As explained above, user would navigate to Build Place by clicking "Activate" button and update the solution set. Below diagram illustrates the backend process during the Build Place Activation.
Build Place Activation for New IFS Cloud Customers¶
Build Place Activation Customers Upgrading to IFS Cloud from Previous IFS Application Versions*¶
*This functionality is currently not available
For upgrading customers, there is an additional step of creating the Buildhome. The initial delivery is also created during this process.
For additional information on creating Buildhome for upgrading customer, refer Buildhome Creation
Grant or Revoke access to Build Place¶
The development team and other stakeholders must be assigned user roles in a build place before they can access it.
This assignment can be done by a Build Place User Administrator (customer users assigned to this role during LE initialization) from the ServiceNow- Customer Service Portal. The form to be used is " IFS Cloud Build Place User Management".
For more information on the different user roles and their permissions, refer User Authorization of the System.
Grant Access to Build Place¶
To assign users to different roles in a build place and allow access to it, follow the steps below;
- Navigate to Customer Service Portal, select Catalog and then Requests.
- Search for the "IFS Cloud Build Place User Management" form and open it.
- Select your Account and the Build Place ID to which you want to add users.
- Select a Customer Solution Role (i.e: Customer Solution Developer, Consultant or Technician).
- Type in the email of the user to be assigned to that role in the "Users to be added" field.
- Perform the same steps to assign users to an IFS Support Role (IFS users) or Build Place User Admin Role (customer users connected to customer account).
- Click Order Now to submit the request.
- Once request is completed, an email will be sent to the users with instructions to access the build place.
Customer/ partner users can log in to the Lifecycle Experience portal using their email and a code that is sent to the email when logging in. IFS users can log in to the portal using their IFS windows credentials.
Build Place User License Policy¶
- Any user who wish to access Build Place should have an account in IFS Azure Active Directory.
- Build Place user license is applicable for Technician and Customer Solution Developer roles only and 15 such user licenses are bundled with Build Place.
- User license type is named users. For an example, 15 user license would mean 15 named users can be allocated as Technician or Customer Solution Developer and all these 15 can work in Build Place simultaneously.
- If there are more than 15 users who will work as Customer Solution Developer or Technician, customer would need to purchase additional user license in 5 blocks.
- Other roles such as consultants do not need to have a user license to access Build Place.
- As per the latest capacity testing, we recommend total of 75 simultaneous users per Build Place for optimum performance.
- For more information on user role permissions please refer here.
Revoke Access to Build Place¶
To remove a user's access to a build place, follow the steps below;
- Similar to above, open the User Management form and select the Account and the Build Place ID from which you want to remove users.
- Select the role assigned to the user. The user's email will be displayed under "Existing Users" field.
- Copy the email and paste it in the "Users to be removed field".
- Click Order Now to submit the request.
- Once the request is completed, an email will be sent to the user indicating that their access to the specific build place has been removed.
Note: Users who have been removed from one role and added to another will need to log out and log in back to the portal for the new role to take effect.
Set up Build Place¶
Before the new build place can be used by the development team, a user who has been assigned the "Technician" role in the build place should set the Mode of Implementation, set the Daily Sanity Build schedule and the Daily Environment Shutdown time as a part of the Setup Build Place for use* activity. Once this set up is complete, users can order environments and begin their work.
*A Technician could be a Customer or Customer nominated user
Set Mode of Implementation¶
Note : It is recommend that the user read the detailed documentation on setting the Mode of Implementation prior to completing the steps below.
Once the Build Place had been activated and the user roles had been created, the next step is to Setup the Build Place for use. The first step in this process is to Set the mode of Implementation. At this time the Build Place card view will appear as shown below.
The user can now click on the “go to Build Place” which will take him to the Select Mode of Implementation dialog.
The Mode of Implementation dialog
Select the applicable Mode of Implementation from the three options given in the dropdown
- New implementation
- Re-implementation of the current solution
- Upgrading of the current solution
Upon selecting each of the options, the explanation text will give a short description on what the selected Mode of Implementation means
Warning text that educates the user on the importance of choosing the applicable Mode of Implementation carefully and whom to contact in case of doubt.
Confirmation check box that the user needs to check to reconfirm his/her choice.
The apply button only becomes available once a valid mode of implementation is selected and the confirmation check box had been ticked.
Clicking the Cancel button closes the dialog and takes the user into the Build Place detail view with limited functionality.
Clicking Apply prompts the user with the following confirmation dialog box that states the Mode of Implementation selected and provides the user one more opportunity to review his choice.
Clicking okay persists the Mode of Implementation selected and does one of the following
a. If the Mode of Implementation selected is either New implementation or Re-implementation of the current solution, initiates the Create Initial Delivery operation. The initial delivery will be based on the latest Sanity-Ok tag which the system will automatically pick.
b. If the Mode of Implementation selected is Upgrading of the current solution, initiates the Recreate Build Home* operation
This functionality is currently not available
The below toast messages are shown confirming the successful updating of Mode of Implementation and triggering of either the “Create Initial Delivery” pipeline or the “Recreate Build Home” pipeline. The Mode of implementation selected will now be visible next to the Build Place name in the detail view.
- Clicking “Cancel” takes the user back to the Mode of Implementation dialog with the previously selected values.
Behavior while Initial Delivery Creation is in progress¶
While the initial delivery creation is in progress which can take up to 4 hours, the Build Place will be unavailable for other operations and the following banner will be shown to the user in the Build Place detail view.
Once the initial delivery creation had completed, the Build Place will be accessible for the user to complete the next step of the user journey which is setting up the Sanity Build schedule and Environment Shutdown time before the Build Place is ready for use.
Set Daily Environment Shutdown Schedule¶
The shutdown schedule will be applicable for the environments ordered in the build place. For more information, please refer to Daily Shutdown of Environments.
- To set the schedule, go to the build place home page and click on "Settings".
- Change the Daily Environment Shutdown Time to a desired time and click on 'Save'. Please note that this time is the UTC time.
The Build Place is now ready to be used.
Segregate Core and Customization code base¶
Currently, when generating code for Customization projects we need the source code of all three layers BASE, CORE and CUST to be present in the workspace. A requirement to come up with a mechanism to keep the CORE code separated from CUST code arose due to the following reasons:
- High development time – Separation of the core and the Cust layer code for customization projects in the Developer Studio tool reduces development time. When building the CUST layer, it is built against a pre-built artifact of the CORE while having only CUST layer code in workspace.
- Large repository size - Through the simplification of code management automation, we allow Build Place users to reduce repository size for customer solutions when customers move from one Core release to another.
Advantages of this change:
- Customers can easily revert their codebase back to a previous CORE Service Updates or Release Updates.
- Reduces repository size for customer solutions.
- Reduces build time for customers and enables customers to access releases faster.
- Reduces storage cost for cloud-based customer builds.
Following are the effective changes due to CORE-CUST segregation. Developer Studio related changes due to CORE-CUST segregation are updated here.
|User flow||Prior to CORE – CUST Separation||After CORE – CUST Separation|
|Customization development||There was no option in the ALE portal to download the core codes of previously taken service updates as the core and customization codes were integrated.||“IFS Cloud Core Codes” drop down button is introduced to download core codes of service updates which has been taken previously. This drop-down is available next to customer-baseline repository info in the repository information card. more info|
|There was no option in the ALE portal to download the core code of the current service update as the core and customization codes were integrated.||“IFS Cloud Core Code
|User had to clone the customer-solution repository which contains both core code and customization.||User is now able to clone the customer-solution repository which contains only the customizations.|
|During the project set-up, user needs to input the path of the entire cloned repository in developer studio. This was due to the core code and customizations are in the same customer-solution cloned folder.||With the core-cust separation, user needs to input the path of the downloaded core code folder in the developer studio tool. There are additional steps involved in this process and please refer detailed documentation.more info|
|Applying a service update||When applying a service update, user is prompted a side panel to apply a service update to customer-baseline repository.||A new pop-up dialog box is introduced with three options to select 1) whether to apply service update to baseline repository, 2) to do impact analysis 3) to create a topic branch to apply to solution.more info|
|Creating a topic branch when applying a service-update to the customer-solution repository has to be done manually.||Creating a topic branch when applying service-update to the customer-solution repository has been automated. more info|
|User was required to conduct Impact Analysis manually. There was no option to download .upda file.||User is given the option to download .upda file to conduct Impact Analysis for current baseline repository version of the Buildplace. more info|
|Order corrective delivery||Normal delivery and corrective delivery options were in the same side panel.||A new path is introduced for the corrective-delivery option. A drop-down button in the Buildplace navigator and a separate pop-up dialog box to order a corrective delivery is introduced. more info|
|User was not given an option to download .upda file to conduct Impact Analysis for corrective delivery. Users had to manually run the update analyzer tool by using Git Info dialog.||User is given the option to download .upda file to do impact analysis for corrective delivery. In addition, user is given the opportunity to conduct Impact Analysis over any service update that has been taken previously. more info|
|Impact Assessment||There is no any node (eg :
||A new node (
|Impact Analysis||There were no any node(eg :
||A new xml node (
|Apply release update||In the release-update process, the step of applying the release-update to customer-baseline repository is called "Apply Release Update".||Apply release update to customer-baseline repository step is renamed as “Apply release update to customer baseline”. more info|
|User was not given a separate step for customization upliftment preparation in the release studio summary table.||A new step called “Customization Upliftment Preparation” is introduced in the release studio summary table for the apply release update to customer solution repository step. more info|
|User was not given a separate button for customization upliftment preparation in the release studio. Topic branch for the customization upliftment has to be manually created.||A separate button is introduced in the release studio navigator for Customization Upliftment Preparation. Topic branch creation for customization upliftment and updating the customer-solution repository version is automated via click of this button. more info|
|Users have to use a set of git commands.||The number of git commands to uplift customization is considerably reduced in a typical scenario. more info|