A remote-sensing product can remain scientifically sound while its identifier begins resolving to the wrong page. Repairing one target is not enough when resolver configuration moves between test and production environments, or when the registry record and local deployment no longer agree.
This guide explains how to promote a resolver change with versioned evidence, trace what the registry recorded, and roll back across environments without confusing a test identifier with a production one. The goal is durable access to the right product identity, not a short-lived green status check.
The examples use fictional identifiers and deployments. Repository operators must follow their registry, security, preservation and change-control requirements. Never test production rollback by deliberately breaking public resolution.
eduKateSG · The Gold Standard · Remote Sensing
Find your next learning step
Follow one identifier from proposed configuration through test evidence, registry provenance, production promotion and rollback readiness.
- ROUTE 1 · Define the configuration — separate identifier, target and resolver behaviour
- ROUTE 2 · Prepare promotion — build environment-specific evidence
- ROUTE 3 · Audit the registry — reconcile local and external histories
- ROUTE 4 · Roll back safely — restore service without losing the change record
- ROUTE 5 · Check transfer — limits, questions and connected reading
Full chapter index · Remote Sensing root guide · Learning that transfers into life · How X Works hub
Chapter contents
Chapters 1–3
Chapters 4–5
Chapters 6–8
CHAPTER 1 OF 12
1. Separate the identifier, registry record and landing page
An identifier such as a DOI is a persistent name. The registry record stores metadata including a target URL. The landing page identifies the resource and provides access. A resolver uses the identifier infrastructure to direct a request toward the registered target.
These layers can fail independently. A valid identifier can point to an unavailable page; a page can be healthy but describe the wrong collection; a local redirect can add an unexpected hop. Monitoring only HTTP 200 status misses identity errors.
CHAPTER 2 OF 12
2. Treat resolver configuration as versioned evidence
Store the proposed target, redirect policy, timeout, allowed host, certificate expectations and environment. Give the configuration a version and immutable review record. A copied screenshot is useful context but cannot replace the machine-readable values that were promoted.
The preceding guide on identifier-target change control and resolver-runbook drills explains target approval. This article follows the configuration into promotion and registry reconciliation.
CHAPTER 3 OF 12
3. Keep test and production identities visibly separate
DataCite’s test and production environments are separate, use separate credentials and have different resolver infrastructure. A successful test DOI proves the workflow can operate in the sandbox; it does not update or validate the production record.
Use distinct hostnames, credentials, prefixes where provided, logs and dashboards. Promotion copies an approved intent, not a database object. Recreate the change through the production interface and capture the resulting production evidence.
CHAPTER 4 OF 12
4. Worked example: a correct test masks a production mismatch
A fictional test identifier resolves to /collection-v4 and the page contains the expected collection ID, sensor name and version. Production still points to /collection-v3. Both pages return 200. Availability monitoring says both are healthy, while identity testing shows production is stale.
The promotion decision should therefore compare the registered target and page identity, not the test result alone. After the production update, repeat the production resolver request from an independent path and verify the final URL and visible identity fields.
| Check | Test | Production | Promotion meaning |
|---|---|---|---|
| Registry target | /collection-v4 | /collection-v3 | Not yet promoted |
| HTTP result | 200 | 200 | Availability alone is insufficient |
| Visible collection ID | C4 | C3 | Identity mismatch remains |
| After update | C4 | C4 | Proceed to observation window |
CHAPTER 5 OF 12
5. Build a promotion package
A promotion package should contain the approved identifier, before and after targets, configuration version, test results, production command or API request, owner, approval and rollback target. Secrets stay in protected systems, not in the package.
Include negative tests: an unapproved host, a page with the wrong collection identifier, a redirect loop and a missing version. The package should show that the controls reject bad outcomes, not only that one good path succeeds.
CHAPTER 6 OF 12
6. Read registry provenance as an external audit trail
DataCite records metadata provenance through activities that identify the action, time, responsible account and record version. This trail helps reconcile what the registry received with the local deployment history.
Do not treat provenance as the whole operational log. It may show that a DOI record was updated, while local evidence explains why, by whom under internal roles, and what tests were run. Join the two using identifier, version and time.
CHAPTER 7 OF 12
7. Reconcile three views after promotion
Compare the local desired configuration, the registry record returned by its API and the public resolution result. Agreement among all three is stronger than a successful update response. Capture the metadata version and final landing-page identity.
Allow for documented propagation behaviour, but do not close the change merely because time passed. If views disagree after the approved window, keep the incident open and follow the runbook rather than repeatedly submitting the same update.
CHAPTER 8 OF 12
8. Measure redirect chains without mistaking hops for identity
Record each status code and Location value to the final page. A planned one-hop redirect may be acceptable; an unexpected chain can add fragility, cross domains or end at a generic homepage. The final page still needs identity tests.
Use an independent request path that does not rely on the same local cache as the promotion tool. Preserve the observation time and user agent. A resolver may behave differently for cached and uncached requests.
| Layer | Evidence | Failure example |
|---|---|---|
| Local desired state | Reviewed configuration version | Wrong environment variable |
| Registry | Target URL and metadata version | Update never reached registry |
| Resolver | Complete redirect chain | Loop or stale cached target |
| Landing page | Collection ID, version and access | Healthy page for wrong resource |
CHAPTER 9 OF 12
9. Design rollback across environments
Rollback restores a previously approved production target and configuration. It should identify the exact prior version, the condition that triggers rollback and the checks that follow. Rolling back production must not modify the test registry by accident.
Preserve the failed promotion and its provenance. A rollback is a new activity, not deletion of the update. This distinction allows later reviewers to reconstruct the interval during which a target was wrong or uncertain.
CHAPTER 10 OF 12
10. Drill without harming public identifiers
Run full destructive drills in the test environment using test identifiers. In production, use read-only verification, a controlled non-public canary where permitted, or a tabletop exercise. The drill should prove credential separation, target restoration, independent checks and notification paths.
A changed-context transfer check might move from one repository host to another with a different redirect policy. Reuse the evidence structure, but re-evaluate allowed hosts, landing-page markers and rollback semantics. Do not copy a host-specific rule as if it were universal.
CHAPTER 11 OF 12
11. Limits, misconceptions and questions
A persistent identifier promises managed persistence, not an immutable URL. Updating a landing-page URL is legitimate when the same resource moves. Major content versions may require a new identifier and explicit relationships rather than silently repointing the old one.
A complete audit trail does not guarantee a correct page, and a correct page today does not prove future persistence. Governance needs both historical traceability and recurring resolution checks.
Does a successful test-environment update prove production is safe?
No. Test and production are separate. The workflow may be rehearsed in test, but production needs its own authenticated update, registry readback, public resolution check and landing-page identity test.
Should rollback erase the failed registry update?
No. Rollback is another versioned activity. Keeping both the failed promotion and restoration preserves the audit trail and makes the affected interval inspectable.
CHAPTER 12 OF 12
12. Evidence route and connected reading
DataCite explains metadata provenance and its activities endpoint, the separation of test and production environments, and how DOI landing-page URLs can be updated. Its versioning guidance distinguishes minor metadata updates from major resource versions.
Follow the local sequence through citation-resolution audits and migration evidence, resolver-failure monitoring and redirect-chain drift, and identifier-target change control. The Remote Sensing root connects data lineage with measurement and validation.
Contents · Previous chapter · Return to the Remote Sensing root