Application Promotion Process for Oracle APEX Apps

As mentioned above, the APEX platform comes as part of the Oracle Database. That is, all the source code for your application actually lives in the database… yes, in database tables, packages, and other objects [2]. As you can imagine, it would be too risky to actively develop an application within the database that stores all your precious data. You need a place where you can safely develop your application without accidentally breaking anything important that would impact your business. Then, once the app has been deemed “safe” and does what you intend it to do, only then can you move it into “production” where real users interact with it to perform regular business tasks.

What I briefly described above is the concept of “application environments”, and it’s a normal part of most app development, regardless of whether APEX is used or not. IBM defines an environment as “a user-defined collection of resources that hosts an application.” Not including your local environment (running the app on your machine), a project typically has three environments:

1. The Dev environment is used by developers to test features currently under development.
2. The QA [3] environment is used to test stable versions of the application before they are released to production.
3. The Prod environment contains the live production instance of the application.

How does an application get from one of these environments to another? This is accomplished by a process called application promotion.

In loose terms, “application promotion” is the process of moving some version of your application across different environments. The goal of app promotion is to successfully deliver changes to your production application with little to no negative impact on its users. You’ll also see this process referred to as “code promotion” or “server promotion”, but I like the term “app promotion” because it encompasses all aspects of the app that may need to flow through quality assurance: code changes, dependency updates, server or subsystem changes, network configuration changes, database data changes, etc.

The word promotion captures the idea of moving from a lower level to a higher level. Most often you promote the app from Dev to QA or from QA to Prod [4]. For example, when developing a feature or fixing a bug in an application, developers may deploy the app to the Dev environment several times so that they can make sure the changes they made have the desired effect. Once they’re confident in the solution, it can then be promoted to the QA environment, where QA testers, product owners, and/or a handful of other stakeholders can verify that the changes are effective and that no other functionality in the app regressed [5]. If testing is successful in the QA environment, the changes will then be promoted into the Prod environment during the next scheduled release. In any case, having a systematic promotion process will help to ensure a smooth, successful transition from “feature in development” to “feature in production.”

The general challenge with app promotion is that the application logic (code) should transfer from one environment to the next without changing, but any environment-specific configuration details used in the code should remain… well… environment-specific. It is best practice to make the environments as similar as possible so that the app behavior is consistent across environments; however, it’s unavoidable that there will be configuration differences between them. They will likely be hosted on different servers, use different credentials and connection information at integration points, and have different network configurations. For example, one of my current projects integrates with a payment processing service, but it’s configured differently in each environment. The Dev and QA environments use a test biller account so that payments don’t actually charge real money to anyone’s credit card.

One of the challenges with APEX app promotion is that it can’t leverage the same technologies, tools, and services commonly used by more traditional [6], file-based development projects. Traditional projects often use popular third-party CI/CD [7] tools like Jenkins, Travis, or TeamCity for their DevOps [8] pipelines. An example of this approach would be one of our projects (a Java/Struts application) that uses BitBucket Pipelines to automatically build and run unit tests whenever code is pushed or merged in the repository. Once the pipeline’s “build” is complete, it’s then possible to automatically deploy the main build artifact to a given environment depending on certain conditions. At that point, the promotion process becomes very hands-off, which helps remove the potential for human error. Unfortunately, because the APEX development platform is inseparable from the APEX application, you’re not able to (easily [9]) leverage these types of third-party tools to build, test, report on, and deploy your application.

Is this, then, an indictment on APEX as a web application development platform? Not necessarily. As with most architecture decisions, the decision to use APEX has its tradeoffs. The biggest benefit to using APEX is that, depending on the use case, you can develop a robust, secure application in a fraction of the time that it would take with another technology stack. A tradeoff for this rapid development benefit is that the promotion process is a bit less automated than you might see elsewhere; however, the platform does a pretty good job of making the manual promotion steps relatively pain-free.

As I mentioned at the start, despite all projects being similar in many respects, they are also all unique. Each project has different use cases, constraints, and other requirements. As such, implementing the application promotion process can and will look different from one project to the next. Given the complexity of modern application development and the unique challenges that face every project, it is never a bad idea to bring a strategic partner on board to help overcome those challenges.

With 35+ years of experience navigating the ever-changing technological landscape, Zirous can help. Our experts can offer technical guidance for your unique project requirements, help your team implement best-practice development processes, provide development services as needed, and ensure the successful delivery of a high-quality enterprise solution. Working with Zirous means having a partner that cares not only about the immediate needs of your project but also about the long-term success of your organization. For more information or to find out if Zirous would be a good partner for your next project, please contact us!