Part 2: Good and bad practices at APEX! Development
This is a series of few articles covering good and bad practices at each stage of the application lifecycle
Part 1: analysis
Part 2: development
Part 3: release to production and beyond
APEX Developer = Full stack developer
An APEX developer often acts as a full-stack developer, managing the entire lifecycle of an application - from analysis to production. Additionally, we frequently serve as consultants, sharing our expertise in APEX to empower others and make the development process more efficient and enjoyable. With that foundation in mind, let’s move on to a few words about the development stage.
Number of environments
In an ideal setup, having four environments is the most convenient and efficient arrangement. However, some clients operate with only two or even one environment. It's important to explain the benefits of having multiple environments as early as possible.
At a minimum, there should be:
A development environment, serving as a sandbox for developers.
A UAT (User Acceptance Testing) environment, where testers can demonstrate their skills.
A production environment, where the live application operates.
It would be ideal to also have a preproduction environment for testing complex operations or conversions on anonymized production data, though this is often overlooked by clients.
And since we’re on the subject of production and sensitive data, it’s worth mentioning:
Anonymization
In some cases, the only way to properly develop and test application logic for specific data is to copy some of the production data. This can happen, for example, when users are assigned unique identification numbers or when the solution is customized to a specific person's unique identifier. In such situations, it is necessary to follow best practices by anonymizing sensitive data before starting any work with it.
Accesses
At some point it becomes crucial to define who will have access to each environment and to what extent. This approach depends very much on the client’s standards, but I would like to share an anecdote that inspired me to write about good and bad practices in APEX.
On one project, I worked with a developer from a client team who had access to all environments, including production. When I checked his progress, I found no trace of him working in development or UAT environments.
When I asked where he worked, he casually replied, “I work in production because it has all the data and is faster.” Needless to say, we quickly corrected this behavior and made sure that proper practices were followed.
Dedicated or shared
This topic is highly individual and depends on the client’s approach. For example, I’ve often encountered setups where the development and UAT environments shared the same infrastructure, while the production environment was hosted on a dedicated setup. This separation is typically driven by security concerns and the need to control user access to critical applications. Therefore, the production environment can run faster because it can be hosted on separate, more advanced servers.
Standards of:
code and SQL’s
I understand that there are as many styles of code formatting as there are developers - each one thinks their approach is the best! However, when multiple programmers are working on the same project, it’s important to agree on some basic standards. For example, decisions like whether to use a specific letter as a prefix for variables or whether commas in SQL queries should come before or after column names can make a big difference in consistency. While these issues may seem trivial, I’ve witnessed heated debates among developers about something as simple as where to place a comma.
Standards of:
templates
Establishing a standard for app templates is another good practice, especially when multiple apps are being developed at the same time. For example, a client may have a specific primary color, a proprietary font, or require a consistent home page across all apps.
While this approach is highly individualistic, creating a single template app with all the desired patterns and standards can save a lot of time and effort. Future apps can then be built by simply copying and extending the template. A well-made template, made once, can serve the client’s needs for a very long time.
Standards of:
documentation
We all love writing documentation, right? While it may not be the most exciting part of development, it’s important at this stage to check if there are any documentation standards. Are there any ready-made templates available? (Spoiler: there probably are!)
Let’s not forget that development isn’t just about the fun process of building an application - it also includes preparing proper documentation to ensure its long-term usability and maintainability.
Standards of:
deployment
It’s important to set clear standards for application deployment! Work with your development team to define best practices and guidelines, especially security, for deploying APEX applications.
Additionally, there are many dedicated tools available on the market that can help streamline and secure the deployment process, which brings us to the next topic.
CI/CD - tools
I have worked with tools like Gradle/Flyway and Liquibase that work in a similar way. The most important aspect is maintaining control over what is being deployed and when, ensuring that you know exactly what changes are being made at each stage.
There are also many insightful blog posts, including some from colleagues in our company, that delve into using Liquibase and Gradle/Flyway effectively.
CI/CD - Git
When discussing tools for quickly making changes to your database, don’t forget about GIT. Whether you’re using GitLab, GitHub, Bitbucket, or another solution, it’s important to integrate GIT as early as possible in your development process.
In addition, you need to prepare your database schema for deployment, e.g., set up sequences for identifiers if you want to use the next value in the sequence before creating tables.
Unfortunately, I’ve been involved in projects where GIT wasn’t used initially, and changes were made via SQL Developer scripts. There are many tools available, and it’s important to be aware of them and use them effectively.
CI/CD - Working Copies
When it comes to APEX, there are several options available for managing application development and deployment. You can split the application and make changes to specific parts that are the responsibility of different developers, for example using Oracle SQLcl.
Another option worth exploring is the new feature in APEX called "working copies." This solution, introduced by Oracle, is a significant update and can be very useful for managing versions and changes in your applications. It’s definitely worth your attention.
Conclusion of part 2 …
In APEX development, success comes from a balance between solid standards, the right tools, and effective collaboration. It's not just about coding, but managing the entire development process in an efficient way, adapting to the customer's needs. Clear communication and good documentation provide long-term value.