The Opening: A Restaurant Does Not Serve Its Test Kitchen
A Chinese restaurant has a test kitchen at the back. New dishes get their seasoning adjusted there, plating tested, costs calculated. Only once it works does the recipe move to the main kitchen. Nobody serves a half-seasoned dish to a paying table. In software, though, "just change it on the live site" happens every day. One restaurant client's booking system had an engineer edit a single line directly on the production server at 8pm; by the next morning no booking form would submit, and 37 reservations were lost in two hours.
These five terms — staging, production, deploy, rollback, CI/CD — are simply the mechanics of a test kitchen. Understand them and you can tell why one vendor takes three days to fix a bug and another takes thirty minutes, and you can read a quote and see whether the safety net was priced in.
1. Production: The Plate the Customer Actually Eats
Everyday analogy: the main kitchen. Every dish that leaves it gets eaten, reviewed and billed.
Plain definition: the system your users are actually using. The data is real, the money is real, and mistakes cost real money.
Business scenario: a cram school's online enrolment page, where parents enter details and pay tuition by card. An error here is not "the page is broken." It is money not collected, angry phone calls, and a full day of manual data entry at the front desk.
The money connection: every minute of production downtime converts to a number. For an e-commerce business doing NT$3 million a month, average hourly revenue is about NT$4,100, so a three-hour outage is NT$12,000 in direct loss — before support cost and the bump in cancellations.
2. Staging: That Test Kitchen
Everyday analogy: the test kitchen. Same equipment, same ingredients, same process as the main kitchen, but customers never receive it.
Plain definition: a system nearly identical to production but running fake data, used to validate new work. The address usually looks like staging.yoursite.com.
Business scenario: an aesthetics clinic is changing its homepage layout. The vendor builds it on staging, the owner opens the link on their phone, marketing checks the copy, reception submits a test enquiry form. Only then does it go live. Production visitors are never affected.
Why it gets cut, and what that costs: staging needs its own hosting, roughly NT$300–1,500 a month, plus 8–16 hours of initial setup. Many quotes drop it to look cheaper. You save maybe NT$12,000 a year and buy a permanent state of "every change is a gamble."
One critical detail: staging must use anonymised fake data. Copying the production customer list across is a common mistake and puts real personal data into a less protected environment.
3. Deploy: Moving the Dish Into the Main Kitchen
Everyday analogy: formally moving the approved recipe and prep procedure into the main kitchen, and making sure every chef today follows the new version.
Plain definition: the entire act of moving tested code and configuration to production and making it take effect.
Business scenario: a manufacturer's B2B quotation system is adding multi-currency pricing. Deployment is not just copying files. It also means updating the database structure, clearing caches, restarting services and confirming old quotations still calculate correctly. Miss one step and the screen looks fine while the numbers are wrong.
The schedule connection: a manual deploy typically takes 20–60 minutes and is easy to get wrong. An automated deploy takes 2–5 minutes and is identical every time. The difference is not speed, it is not forgetting. At four deploys a month that saves about 30 hours a year, but the real value is removing human step-skipping as a risk source. See the Laravel deployment documentation for production configuration guidance.
4. Rollback: Back to the Old Menu in Three Minutes
Everyday analogy: two tables get the new dish, feedback is bad, and the head chef announces a return to the old recipe. Restored in five minutes.
Plain definition: the ability to switch the system quickly back to the last known-good version after a bad release.
Business scenario: an online store ships a new shopping cart the day before a major sale. Twenty minutes in, shipping fees calculate incorrectly. A team with rollback: back on the old version in 3 minutes, 3 orders affected. A team without: two hours of live debugging, every order wrong in the meantime, and manual refunds afterwards.
The risk connection: rollback converts the cost of failure from unpredictable to bounded. It does not stop you making mistakes; it caps the worst case at minutes instead of hours. One point that gets missed: code can roll back, database changes usually cannot. A real rollback plan therefore requires database changes designed to be reversible — that is the line between professional and amateur.
5. CI/CD: Automating the Path From Test Kitchen to Table
Everyday analogy: a conveyor belt with quality gates. Ingredients are weighed and temperature-checked automatically; fail any gate and the belt stops; pass them all and it moves to the pass.
Plain definition: CI (continuous integration) means every code change automatically runs checks and tests. CD (continuous deployment) means anything that passes goes live automatically. Together they are an automated quality-to-launch pipeline.
Business scenario: a five-location chain whose website and booking system are maintained by two engineers. After adopting CI/CD, every change automatically runs 120 tests (no double bookings, no overselling a slot, correct amount calculation), and a single failure blocks the release. Release frequency went from "once a month and everyone is tense" to "three times a week and nobody works late."
Cost and threshold: GitHub Actions includes a free allowance for private projects, and small-to-mid projects typically spend NT$0–500 a month. The real cost is setup: 16–40 hours initially, about NT$24,000–60,000. Payback usually lands in month 8–12, faster if your system has had two or more release incidents in a year.
Common Misconceptions
- "Staging means we will not have failures." Staging only reduces probability. Data volume, traffic and live payment gateways all differ from production, and some problems only appear there. Staging catches the obvious ones; rollback catches the rest.
- "CI/CD is only for big companies." The opposite. Large companies have dedicated operations staff to check things manually. Small teams do not, which is exactly why they need automation as the reviewer that never forgets.
- "Rollback is just restoring a backup." No. Restoring a backup usually overwrites everything created since — orders, comments, signups all vanish. Rollback swaps the code version and preserves the data. A vendor who conflates the two probably has not done it.
- "These are technical details, not my concern." They determine your quote and your risk directly. A project without staging and rollback quotes cheaper because it transfers the risk to you.
Six Questions to Ask Your Vendor
- "Does this project include a separate staging site, and is it in the quote?" If not, ask for a version that includes it and compare the difference before deciding.
- "If a release breaks production, how long until we are back on the last good version?" A reasonable answer is 5–15 minutes. "It depends" or "redeploying the old version takes an hour or two" means there is no rollback capability.
- "How do database structure changes get reverted?" This question separates the professionals. A good answer mentions a reversible down method for each migration, or an automatic snapshot before changes.
- "Is deployment manual or automated, and where are the steps written?" Manual is not a sin, but there must be a written deployment checklist that does not live only in one engineer's head.
- "Are there automated tests, and which critical flows do they cover?" Full coverage is unnecessary, but payments, orders, inventory and permissions must be covered.
- "When will you deploy, and will there be downtime?" Commerce and booking systems should deploy at the lowest-traffic window, announced in advance.
Decision Checklist: How Many Layers Do You Need?
- ☐ Does the site get more than 100 visitors a day?
- ☐ Does it handle payments or orders?
- ☐ Would an hour of downtime cost revenue directly?
- ☐ Do you make changes more than twice a month?
- ☐ Do two or more people touch the same codebase?
- ☐ Does the system hold customer personal data?
- ☐ Have you ever discovered breakage only after going live?
- ☐ Do you need guaranteed stability during specific peak periods?
One or two ticks: production plus scheduled backups is enough. Three to five: you need staging and a defined rollback process. Six or more: adopt full CI/CD with automated testing.
FAQ
Will Google index my staging site and hurt SEO?
Yes, and it is a common incident. Staging must have password or IP restriction plus an X-Robots-Tag: noindex response header. Relying on robots.txt alone is not safe.
How long and how much to adopt CI/CD?
For small and mid-sized projects, initial setup is 16–40 hours at NT$24,000–60,000, including test environment, deployment scripts and basic automated tests. Ongoing monthly cost is close to zero.
My site is WordPress. Do I need this?
Yes, but differently. WordPress risk concentrates in plugin updates, so aim for three things: automatic snapshot before updating, a staging site where updates go first, and the ability to restore within 10 minutes. Most hosting providers include tools that cover this cheaply.
Can we do staging first and CI/CD later?
Yes, and it is the most pragmatic order. Staging has the highest return and the lowest barrier. Once you have staging and a written deployment checklist, automating that checklist is CI/CD. You do not need it all at once.
Get in Touch
If you are unsure whether your current site or system has these layers, we offer a one-off release process health check: we review your staging setup, deployment method, rollback capability and backup strategy, and give you a concrete remediation list with pricing.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p