“We push to production by hand over FTP.” “Only one specific person can deploy.” This setup will inevitably cause an accident someday. CI/CD is a mechanism that automatically runs work such as testing, building, and deploying, triggered by changes to your code. CI (Continuous Integration) refers to “automatically testing and verifying on every change,” and CD (Continuous Delivery/Deployment) refers to “getting verified changes into a state where they can be deployed automatically.” This article explains what’s dangerous about manual deployment, and how to start small without a major reorganization.
Typical accidents of manual deployment
- Missing or misplaced file overwrites — Forgetting to transfer some files over FTP, or overwriting files from another environment. There’s no way to prevent it by hand, and it tends to be caught late.
- Errors you only notice in production — Code that worked locally breaks only in production due to differences in dependency packages or the PHP version. Without automated tests, verification is just “look at the screen after deploying.”
- The “can’t roll back” problem — Manual deployments often don’t preserve the pre-deploy state, so rolling back when something breaks takes a long time.
- Reliance on one person — The procedure lives only in one person’s head, and when they’re away you can’t even push an emergency fix. Deployment becomes something to fear, and release frequency drops.
What changes when you introduce CI/CD
| Aspect | Manual deployment | After introducing CI/CD |
|---|---|---|
| Human error | Missed transfers and overwrite accidents can occur | The same steps run automatically every time, and manual errors disappear |
| Quality checks | Visual check after deploying | Tests run automatically before deploying, and it stops if they fail |
| Rollback | Manual recovery, takes time | Just redeploy the previous version |
| Reliance on individuals | Only a specific person can do it | The steps are codified, and it’s the same no matter who runs them |
| Release frequency | Batched to monthly because it’s scary | Small changes can be shipped frequently |
What’s especially effective is the property that “it stops if it fails.” Because quality is assured by the mechanism rather than by human attention, you can escape the state of being tense on every release.
Three stages to start small with GitHub Actions
There are various CI/CD tools, but if you manage your code on GitHub, GitHub Actions—usable with no additional server—is the first choice. You don’t need to automate everything at once; the realistic way is to proceed in these three stages.
- Stage 1: Automated testing (CI) — First, create a workflow that just automatically runs tests and lint (syntax checks) on every push or pull request. For a project without tests yet, even just confirming “does the build pass” and “are there syntax errors” is a solid first step. Since it touches deployment not at all, there’s no risk of breaking your existing operations.
- Stage 2: Automating the build — Move the “manual steps you do before deploying”—building CSS/JS, installing dependencies—into the workflow. Inserting the intermediate state of “automated up to producing the build artifact, placement still manual” lets you migrate safely.
- Stage 3: Automating deployment (CD) — Trigger placement onto the server automatically on a merge to the main branch. Start with automatic deployment to a staging environment rather than production, and keep production as an approval-gated “it runs when you manually press a button”; that lowers the psychological resistance.
Each stage can proceed on a scale of days to a few weeks. Even Stage 1 alone produces the effect that “a broken change won’t be merged,” so your investment isn’t wasted even if you stop partway.
Points where people commonly stumble
- Hardcoding secrets — Never write server passwords or API keys directly into the workflow file. Register them in GitHub Actions’ Secrets feature and reference them.
- Differences between production and test environments — When it passes in CI but doesn’t work in production, environment differences are the cause. Pin PHP and Node.js versions within the workflow to match production.
- A codebase with no tests — If you think “write tests, then do CI/CD,” you’ll never start. The order is the reverse: first lay down CI with just syntax checks, then add tests from subsequent changes onward—that’s more realistic.
- Deploying to shared servers — On environments with restricted SSH such as rental servers, options are limited, but automation itself is possible using an Action that supports automatic transfer over FTPS or rsync.
How to measure the impact
The impact of CI/CD tends to become a matter of feeling, but comparing the following metrics before and after adoption makes the investment decision easier.
- Deployment frequency — Can a monthly batched release become weekly or daily? The more often you deploy, the smaller each change, and the easier it is to isolate defects.
- Time spent on deployment work — Work that took 30 minutes to an hour following a runbook turns into a few minutes’ wait after a merge. You can convert that into money as the person’s tied-up time.
- Recovery time from production incidents — With rollback becoming “one redeploy,” the time to handle incidents shrinks greatly.
Even for a small team, adding up the time spent on deployment work and production trouble often comes to several to a dozen-plus hours a month. That time returning to development is the real return of CI/CD.
Summary｜Make “deployment isn’t scary” your first goal
The goal of adopting CI/CD is not advanced automation itself, but “a state where anyone can release safely, anytime.” A small first step of automated testing is enough. SHANNON runs CI/CD daily in developing and operating its own SaaS, and builds the same mechanism into contract development and system maintenance we provide. We can propose an adoption plan tailored to your current development flow even from the stage of “we want to stop deploying by hand but don’t know where to begin,” so please feel free to reach out.