Besides the ability to drop your APEXcl unto version control, using APEXcl gives you clear benefits. Here are a few areas that will help your development operations:
- Code review
- Code history
- Code search
Code review is crucially important in the life cycle of an application development. Code reviews come in when a developer completed the development of a functionality, and it’s time to look back at the quality of the code with a peer.
This section describes a typical code review of an APEX application without APEXcl and then explains the advantages of doing a code review with APEXcl.
Code review (without APEXcl)
Typically, a code review in APEX is a very manual process. You have to go in the APEX builder and browse around the different components which you remember have changed.
Code review (with APEXcl)
After the files are committed and pushed to GitLab, all team members are able to benefit from a full fledged changelog regarding their APEX application.
In the above screenshot, GitLab reveals that changes were made to 3 components:
- A new dynamic action was added, with the `console.log` code.
- The label changed for button VIEW_MONTH_ORDERS
- The SQL query of an interactive report was changed
This process makes it crystal clear what happened in the application. You don’t have to randomly look at places in the APEX builder to verify the new code of your application. It’s all right here.
When something goes wrong in an application (in all technology stacks), it is common practice to look at the change history a a particular component. That allows you to locate and understand the code changes that introduces a defect in your application.
Code history (without APEXcl)
APEX has always been hard to play with when it comes to tracking changes at a particular component level. APEX keeps an audit trail of who changed what:
but it doesn’t show the content that has changed. So we can find the faulty developer, but we can’t find the faulty code.
It’s also not very intuitive because as you make changes to a region, APEX registers a change to the page (its parent component) so it’s very hard to track exactly what has changed.
Typically, if we wanted to return to an earlier version of code inside of APEX, one effective way would be to import an older application and set a application ID. Then compare the code. Then apply the code fix to the master application.
Code history (with APEXcl)
APEXcl greatly enhances the component history model because it allows to track changes to the code over time. For instance, a developer that has made a few changes to a SQL query of a classic report on page 1 can review the history of the component on GitLab like this:
This view shows me the timestamps, the author and the content of the modified code. It makes code reviews and debugging vastly easier.
APEXcl allows to easily compare older versions of the code, so rolling back to older code is a breeze.
APEX has a search mechanism integrated in the builder, but APEXcl now provides an alternative. It is very convenient to use modern code editors to search for files on the file system.
Searching for files on the file system is extremely fast, next to instantaneous. Also, it doesn’t require to be connected to the APEX builder.