The latest APEX release, 23.2, introduces new functionality for creating an application working copy. It allows developers to create their own copy of the application and make changes on the branch. This can be effective when adding new features during an ongoing development process or to add a bug fix. This approach gives more confidence in building applications by creating as many working copies as required, allowing multiple developers to make changes simultaneously.
Moreover, once changes are made, you have an option to select components to merge into the main application. This new functionality is worth looking at, especially if developers want to apply changes quickly without affecting the main applications.
In this blog, I will present how to use the Application Working Copies feature, with examples, and explain the options available.
Firstly, I logged in to the APEX workspace as USER1 and selected the DSP application. Once the application opens, there are various options on the right-hand side, including 'Create working copy'. By choosing this option, the screen below appears. I then created a working copy of my app by providing the name WC_U1_CHANGE_NAME and a description. An agreed naming convention and description can be helpful for other developers to know what the branch contains.
Once a working copy has been created, an extra symbol will appear on the application icon, which helps to identify which applications have working copies. There is no limit to how many copies you can create. You can work on them simultaneously and switch easily by selecting them from the list.
In addition, under your branch, you can perform other actions related to the branches, such as switch branches, update details, compare, refresh or merge into main applications.
In my example, I created the branch WC_U1_CHANGE_NAME and then modified the application. I changed some column names and labels to a customer report on page 2 and then added a new page called 'Departments' with a simple Classic Report. To review all the changes on your branch, you can use the 'Compare changes' option, which allows you to view the summary of your changes in detail.
The summary above presents the status of each change, the component type, name, and ID. There is also an option to visualise changes using a built-in side-by-side difference viewer. My changes have been labelled as 'Added' and 'Changed'. For each change, I can view changes individually.
Below, the View Differences editor highlights where the differences are, and I can ensure everything is in the right place. For 'Added' changes, the wizard displays only newly added elements with all details. The View Differences editor allows you to easily navigate between changes using arrows or scrolling. It is a helpful feature, and I recommend using it before merging changes.
At the same time USER1 was working on their copy, a second developer, USER2, created another working copy based on the main app. This user changed a Text item to a select list, added a blank page for the development of some new features, and deleted a page that was no longer required.
Some advice to developers on how to avoid conflicts during development is to reserve a range of pages for each developer to work on and agree on the naming standard for shared components.
Developer USER1 is ready to merge their changes back into the Main branch. Before merging, the developer can review and make a final decision on which changes will be merged into the main branch.
In the wizard, there is an option to select/unselect the changes to deploy – this may be helpful if not all changes require merging. In this example, I would like to merge everything, apart from the changes to page 5, 'Locations', as it has not been fully tested.
On the next screen, we can see a summary of changes and have the option to make a backup of the target application and to delete the working copy after a successful merge. A backup copy of the application can be helpful if the changes cause issues.
Once the merge is complete, you can automatically delete the old working copy. However, in this case, I don't want to do that because I would like to continue my unfinished work.
Once confirmed, selected changes are merged into the main branch, and the work is left for further use. The application is also backed up successfully. When USER1 goes back to the working copy, the only difference remaining is the component which was not selected for the merge (the changes to page 5).
Another beneficial option available in branching is the refreshing of a working copy. The changes merged into the main branch by USER1 are not in the working copy created by USER2, however, it can be updated to the latest version using this option. Before making any changes, it is possible to compare the branches to see the differences. Several changes are missing from the working copy created by USER2.
USER2 can easily pull all changes applied to the main branch by selecting the option 'Refresh Working Copy'. The screen below shows that the refreshed working copy looks very similar to the standard merge process with the option to select components and compare changes. Some components, which have been highlighted as Missing in the compare option, can be added again while refreshing. The refresh option allows you to pull missing objects back, but if those objects are not needed anymore, they can be skipped.
This is different from the merge process, where all missing objects must be removed manually in the main app. It is also one of the limitations that components listed as Missing may have been removed in the working copy or may only exist in the main branch. It can happen, for example, when a developer adds a component in the main branch. It does not exist in the working copy or in the opposite situation when a developer removes a component in the working copy while it still exists in the main branch. Once the refresh is completed, USER2 can continue working on their copy without affecting the application on the main branch.
I found the working copy functionality very useful, and I am sure many other APEX developers will also. Creating a copy of an application to develop various functionality without affecting the main application can be used in day-to-day work. Applications can be run and tested on separate branches.
Oracle has provided some tips to avoid merge conflicts, such as following naming conventions for components and reserving page ranges for specific functions and/or developers. Locking a page on the main branch before creating a working copy is also a good practice. In the merge help, there are some tips related to working copy, which I encourage you to look at.
As I mentioned earlier, one of the working copy limitations is that pages or components deleted in the working copy must be deleted manually in the main branch. The merge process does not support it, and the developer must remove it manually, which can sometimes be problematic if there is a lot to remove. Also, creating a working copy based on an existing one is not possible, however, in my opinion, this is not a massive issue.
As it is the first release, not everything is perfect, and some components are not supported, such as Translations, Themes, Templates, Supporting Objects, etc. However, for this first release, the working copy functionality is effective and will hopefully be improved and enhanced in subsequent APEX releases.
For more information, check out our APEX services, and if you liked this blog, check out our other APEX blogs here.
Remember to follow us on LinkedIn. We publish insight blogs on the latest technology developments every week.