Safe online store releases: acceptance, CI/CD and rollback
After an update, the store opens, but a dealer sees the retail price and a paid order never reaches the accounting system. The technical status “deployed successfully” does not explain this. Safe online store releases start with a different question: what evidence justifies making a change available to customers, and what will the team do if the business scenario fails?
The owner needs to agree on the scope of the change, acceptance criteria and the authority to stop the launch. Separate code delivery, feature activation and confirmation of the result: automation should speed up a controlled process.
What exactly CI/CD should authorise
CI, continuous integration, helps regularly check code changes with automated tests. CD can mean continuous delivery of a prepared version or automatic deployment of changes. Agree on which meaning the contractor uses: a version being ready to launch does not necessarily mean permission to release it to customers without a separate decision.
A build passing its checks, a version being installed and a feature becoming available to customers are different events. Approvals and a test purchase may come between them. A feature flag — a feature switch — allows availability to be managed separately, if the architecture supports it.
The release record should contain the version, changes, dependencies, test evidence and the point beyond which reverting is unsafe. The business approves the expected behaviour; the technical lead confirms that the environment is ready; the designated person carries out the deployment.
Launch approval must rest on business criteria
Business acceptance of a release means checking the outcome for the customer and the operations team. Instead of requiring that “the cart works”, write down: a customer in the relevant group receives the agreed price, selects an available delivery option, the payment is linked to the correct order, and the manager sees it with the required details. Add evidence and a person responsible for checking each criterion.
What blocks a release and what can wait
Classify defects by their consequences. An incorrect amount, access to someone else’s account, a duplicate order or the loss of payment confirmation should block the affected scenario. A minor visual discrepancy can be accepted separately if it does not hinder purchasing or accessibility. This is an editorial example of rules, not a universal classification for every store.
Approve the criteria before development is complete. For the accounting workflow, identify who owns statuses and stock reservations: the article on choosing an OMS for an online store will help define what needs approval.
How to formalise approval in the tool
The GitHub documentation on deployment environments describes protection rules and deployment approvals. Feature availability depends on the plan and repository visibility. Check the actual settings: who approves, whether self-approval is allowed and who can bypass the restrictions. Having a confirmation button does not prove that the business criteria have been met.
Choose a release method by risk, not by name
Choose the release method based on the state of the data, customer sessions, background jobs and the ability to limit the audience without compromising the integrity of a purchase.
| Approach | When it helps | What to check separately |
|---|---|---|
| Scheduled deployment with a pause | The change requires an agreed pause in writes | Unfinished purchases, queues and customer notifications |
| Blue-green: switching between environments | A new version needs to be prepared separately | The shared database, sessions and compatibility of both versions |
| Canary: a limited release | There is enough traffic and reliable audience segmentation | Keeping a customer on the same version and monitoring business signals |
| Feature switch | The feature can be disabled independently of the rest of the code | Server-side restrictions, new records and the behaviour of the old path |
A limited release does not prove that a rare B2B scenario works correctly if the relevant dealer was not included in the test group. Nor do two environments create two independent order histories when they use the same database. Routing traffic back to the old version must remain compatible with what the new version has already written.
Rollback plan: code and data are separate
A rollback plan must name a specific action for each type of change. The previous code package, the previous configuration, disabling a feature and restoring the database are different operations. They are not interchangeable and cannot always be performed together. What matters is not just having a backup, but also what happens to purchases made after it was created.
If the new version deleted a field or wrote an incompatible format, the old code may be unable to read the data. In its article on rollback safety during deployments, AWS describes preparing compatibility in stages before activating a new format. For a store, this means first teaching components to understand both formats, and only then changing how data is written.
Where the safe rollback boundary lies
Mark the step after which simply reverting the code is no longer safe. This could be starting the conversion of historical orders or changing data exchange with the ERP. Before that boundary, the team performs the agreed rollback; afterwards, a compatible fix forward and reconciliation of transactions may be needed. The exact procedure is defined for the specific system, not improvised after an error.
In Drupal, configuration is also part of a release. The official configuration management documentation recommends testing changes outside the live site and transferring them between environments. A configuration export is not a backup of orders. Align it with the code version and database structure changes, and manage environment access and secrets separately.
A hypothetical example: new dealer discount logic
Suppose a store changes how dealer discounts are calculated. This is a hypothetical example, not a GL.ua case study. The acceptance criterion: the agreed price is the same on the product page, in the cart, in the payment request and in the order in the accounting system. An existing order must not change its amount simply because a new version was installed.
The team first deploys compatible code with the new logic disabled. Using test accounts, it checks both dealer and retail scenarios, as well as a cart created before the update. The rule for such a cart is agreed separately: preserve the offer or recalculate it with an explicit notice to the customer. Predictability matters, not choosing one option for every situation.
After activation, a discrepancy emerges between the order amount and the accounting system. If the architecture allows it, the team disables the new calculation for subsequent transactions. It does not automatically delete or overwrite orders already accepted: it identifies them by their release marker and reconciles payment and transfer to the ERP. Restoring the old database without accounting for these orders could remove genuine purchases.
Repeated payment notifications are checked separately. The Stripe documentation on webhooks warns about possible duplicate events and the lack of a delivery-order guarantee. These are Stripe’s characteristics, not a claim about all gateways. Check your provider’s own rules; make it an acceptance requirement that a repeated event does not execute the same business operation again.
The acceptance sequence before and after launch
Test the actual package you intend to install, not an arbitrary test branch. The test environment should reproduce the important dependencies without sending real orders to the warehouse. Use permitted test data and providers’ test modes; record differences from the live environment as limitations of the evidence.
- Record the version, configuration and list of data transformations. Check that no untested changes were added to the package after acceptance.
- Follow the customer journey: role and price, product, cart, delivery, payment, confirmation. Compare amounts and identifiers at every boundary.
- Test negative scenarios: a declined payment, a repeated notification, an unavailable product, an interrupted session. Confirm the agreed behaviour, not merely the absence of an on-screen error.
- Match the store’s record with the ERP or OMS. Make sure the queue has been processed and retransmission does not duplicate an order or stock reservation.
- Rehearse reverting in the test environment after new records have appeared. Save evidence of which data remains available and what needs manual reconciliation.
- Obtain approval from those responsible, carry out the launch and perform the agreed check in the live environment. Allow real payments or shipments only under a separately defined procedure.
- Close the release after checking delayed events and integrations. If a stop condition is triggered, pause the expansion of access and follow the agreed plan.
This is acceptance of a specific change, not a drill in how support responds to an arbitrary failure. Checking support readiness is a related task, covered in the article on a training incident in a store. For a release, the priority is evidence that the new state is acceptable and control over the transition to it.
Which signals to monitor and when to stop
Alongside server errors, watch checkout completion, amount discrepancies, accounting delays and unprocessed messages. Agree on thresholds and the observation period based on this particular store’s normal operation. Do not borrow someone else’s percentages: low customer traffic or the start of a promotion can make a short comparison misleading.
A drop in conversion alone does not prove that the new code is at fault. Check the version, audience and external dependencies. A confirmed amount or access error, however, requires action without waiting for statistical significance. Agree on the authority to disable the feature before launch.
Timelines, costs and a sufficient level of automation
Timelines depend on more than writing a pipeline — a sequence of automated steps. First, you need to describe critical scenarios, prepare the environment and test data, agree on partner access, check compatibility and rehearse reverting. An unknown historical data format or the lack of a payment test environment may affect duration more than the choice of tool.
Separate one-off work from recurring costs in the estimate. The former includes dependency analysis, delivery setup, test automation and the migration procedure. The latter includes the test environment, running checks, storing builds and backups, monitoring and maintaining test scenarios. Account separately for the business team’s time spent on acceptance and checking changes to external services.
Start with a minimal, manageable process: a reproducible build, a designated approver, a verified purchase and a documented way to revert. Add a more complex release method when its benefits justify the infrastructure and maintenance. If the next update changes pricing, payments or accounting, contact GL.ua (Glyanets) about online store development and enhancement: send the list of changes, an integration diagram and your current launch procedure to agree on the scope of a release process assessment.
Just one step to your perfect website
