# Building CI/CD for Oracle APEX – Part 4: From Environment Differences to Reviewable Changes In the previous parts, I built up two essential pieces of the process: a reliable snapshot of the current state, and comparison rules that make DDL differences more meaningful. Once those differences are visible, the next question is almost unavoidable: what changed, who changed it, and what should I do about it? The answer is not a single audit table. It comes from combining two different kinds of evidence. Current state tells me what exists now. Event history can help explain how that state may have been reached. The same distinction becomes even more important for Oracle APEX. A component difference can show me where an application has diverged, but it is not an instruction to import that component on its own. ## Current state and event history answer different questions If a package body differs between DEV and TEST, a snapshot can tell me that both objects exist, that their comparable hashes differ, and which exact source and target snapshots were used. An event record answers a different set of questions: - Which DDL operation was recorded? - Which object did it affect? - When did it happen? - Which database session and application context were available at the time? - Which developer identity, if any, can be resolved from trusted information? The difference matters because an event record is not the source of truth for current state. A snapshot can still reveal a real environment difference even if a historical event is unavailable. Conversely, an event tells me that something happened, but it cannot by itself prove that the same statement should be replayed in another environment. ## The event list is not a deployment plan TMS presents DDL events and APEX Builder activity in a searchable event list. I can filter it by environment, time window, executor, object type and event type. ![](https://cdn.hashnode.com/uploads/covers/6461f51b60bafcc7fa959d8c/d696c0c3-6cca-4534-b90f-964a13aef2b8.png align="center") *Figure 1. The event list makes change activity searchable by time, environment and actor. It is an investigation tool, not a list of statements to deploy unchanged.* An `ALTER` event, for example, does not automatically become an `ALTER TABLE` statement in a release. The target environment may have changed since the event was recorded. Several events may belong to one business change, and some events may be technical operations with no deployment value at all. The snapshot comparison remains the decision point. Events provide context around that decision. ## DDL audit records evidence close to the source The source-side DDL audit records an audited structural change locally, together with the object identity, original DDL, hash, length and available session context. The central TMS retrieves new event headers later, then requests the associated payload only when needed. That separation is deliberate. A database trigger must not depend on the availability of the central TMS or the network while the original DDL is executing. The local event remains available for later collection if the central service is temporarily unavailable. The detailed event view makes that evidence usable. It shows the affected object, operation, event and import times, and the available executor and session information alongside the original DDL preview. ![](https://cdn.hashnode.com/uploads/covers/6461f51b60bafcc7fa959d8c/348ea9df-749c-434f-9dc8-1d181be8ff1a.png align="center") *Figure 2. DDL audit event details showing the affected object, operation, executor, timestamps, session context and original DDL preview.* ## Attribution is evidence, not a verdict The available identities do not all mean the same thing. The Oracle session user identifies the database account that executed a statement. An APEX `APP_USER` identifies an application user. A host name, operating-system user and client identifier can be valuable diagnostic evidence, but they do not necessarily identify a person when a connection pool, shared machine or automated process is involved. For that reason, I do not try to turn every technical value into a supposedly definitive developer name. Where a trusted mapping is available, TMS can show the resolved identity. The remaining context stays visible as supporting evidence. The same caution applies to causation. The latest event for an object may be relevant to its current difference, but it does not prove that it caused that difference. A later change may have occurred, the event may have been only a compilation, or the target may have been changed independently. Events help me ask the right questions faster. Snapshots still answer what is actually different. ## APEX needs a logical component match before a hash comparison APEX adds another layer to the problem. Before I compare a page item, a region, a button or a dynamic action, I need to know that the two records represent the same logical component. An internal numeric ID is not always enough. Imports, copies and separate development histories can produce different technical identifiers for components that serve the same purpose. TMS therefore builds a component key from the available metadata: the application, page, component type, name, parent component and other identifying attributes. Only after this matching step does it make sense to compare the stored component properties and hashes. ![](https://cdn.hashnode.com/uploads/covers/6461f51b60bafcc7fa959d8c/56b21fe9-4a2c-418e-b2e2-c9e503330594.png align="center") *Figure 3. The summary shows where the differences are concentrated. It does not claim that every differing component is an independent deployment task.* The comparison list makes the logical match, source and target snapshots, and any available related events visible for each component. ![](https://cdn.hashnode.com/uploads/covers/6461f51b60bafcc7fa959d8c/05eef9f4-0a80-4f80-af9a-bb7fc74ef923.png align="center") *Figure 4. Component-level differences can point directly to the application area that needs review or testing.* ## A component difference is not an APEX import The component detail view shows exactly what the central audit stored and compared: the component key, source and target hashes, snapshot identifiers, capture status and available modification data. ![](https://cdn.hashnode.com/uploads/covers/6461f51b60bafcc7fa959d8c/f93915a8-99be-41bc-87ed-8eb2a044f8be.png align="center") *Figure 5. The detail view makes the comparison basis visible. It also makes clear when runtime code or client-side conditions are outside the current audit model.* That boundary is important. Some Dynamic Action code, PL/SQL, JavaScript, parameters and client-side conditions are not represented as complete executable definitions in this central component model. It would be misleading to present a component detail as a complete application export. The deployment boundary therefore remains the full, identified APEX application export. The component comparison serves a different purpose: it tells me which pages, regions, items and shared components may have changed, so that I can focus review and regression testing where they matter most. The next and final part of this series brings the pieces together: how TMS turns selected, reviewable differences into a versioned release artifact without turning approval into an automatic deployment.