How it works in practice
Say a developer fixed a bug in an online store's shopping cart. Without automation, they manually move files to the server and hope nothing breaks. With a pipeline in place, it works differently:
- the developer pushes the change to the Git repository;
- the system automatically runs checks and tests;
- if everything passes, the change goes to a staging server where it can be reviewed;
- once approved, the change goes live — and with the right setup, with zero downtime for visitors;
- if something goes wrong, the previous version is restored in one step.
The acronym is simple. CI is continuous integration — constant automated checking of changes. CD is continuous delivery — automated deployment of tested changes.
What it means for your business
- Fewer post-release failures. Bugs are caught during checks, not by customers on the live site.
- More frequent, smaller releases. New features ship as soon as they're ready instead of piling up into one big, risky release.
- No dependence on one person. Deployments don't hinge on whether the developer who "knows how it's done" is on vacation.
- Clear change history. You can always see what was deployed, when, and by whom — and which version to roll back to.
- Easier onboarding. A new developer can run the project locally with a few commands instead of building the environment by hand.
Why containers
A container is a "box" holding the application along with the right language version, libraries, and settings. Docker lets you run that box the same way on any server. This eliminates a whole class of problems where everything worked on staging but not in production because of a different PHP version or a missing library.
Containers also make it easier to move between servers and cloud providers, and let you run multiple copies of the application as traffic grows. Large systems with many containers use Kubernetes, but for most projects it's overkill.
There's a flip side. Containers add another layer that needs to be understood and maintained: keeping base images updated, watching disk space and logs. So we don't containerize everything indiscriminately — we start with the parts where environment differences are already causing problems, and we show your team how to work with them.
Who needs this — and who doesn't yet
Automation pays off when several developers work on a project, updates ship often, and mistakes on the live site are costly: ecommerce stores, online services, portals, and mobile apps with their own backend.
A small corporate website updated a few times a year doesn't need a complex pipeline. But even there, it's worth keeping the code in Git with a simple automated deployment: it's inexpensive and saves you from accidental mistakes.
A special case is when development is split among several contractors or part of the work is done by your in-house team. Shared deployment rules are especially useful then: everyone sees what others changed, and "who broke the site" disputes are settled by the change history.
Options: from simple to full-scale
- Simple automated deployment. Code from the repository goes to the server automatically after approval. Minimal effort, and it already eliminates manual file copying.
- A pipeline with checks and a staging server. Adds automated tests and a separate environment for review. The best fit for most commercial projects.
- Full containerization. Every part of the project runs in containers, and the infrastructure is defined as code, for example with Terraform or Ansible. Offers the most flexibility, but takes more time to set up and more expertise to maintain.
What to prepare on your side
- access to the code repository, or the code itself if it isn't in Git yet;
- access to the servers or cloud account where the project runs;
- information about who currently develops and deploys changes;
- a list of external services and access keys the application uses.
Common implementation mistakes
- Storing passwords and access keys directly in the repository code.
- Trying to build a "perfect" Kubernetes pipeline right away for a small website.
- Setting up automated deployment without a way to roll back.
- Having a staging server so different from production that testing on it proves nothing.
- Forgetting about database migrations: the code is updated, but the table structure is still the old one.
How to tell automation is working
The results show up not in the configuration but in day-to-day work. Some time after rollout, it's worth looking at a few things:
- how often you have to rush a fix on the live site after an update;
- how long it takes from a finished change to it appearing on the site;
- whether anyone on the team can deploy an update, not just one person;
- how long it takes to roll back to the previous version if something goes wrong.
If these metrics aren't improving, we figure out where the pipeline is getting in the way instead of helping, and change it.
What affects the cost
- Project state: whether the code is in Git, whether there are tests, how hard it is to spin up the project from scratch.
- Number of components: one website or several services, background workers, a mobile app.
- Number of environments: production only, or staging and demo copies too.
- Depth of automation: simple deployment, a pipeline with checks, or full containerization with infrastructure as code.
FAQ
Will development have to stop during implementation? No. We set up the pipeline alongside ongoing work and switch the team over once it's tested.
Can CI/CD be added to an older project? Yes, although sometimes the code and dependencies need cleaning up first. For very outdated systems, this is usually part of gradual modernization.
Do containers require the cloud? No. Docker containers run perfectly well on a regular rented server. The cloud is useful when you need to add resources quickly — see our cloud infrastructure page.
Do we need to write automated tests right away? Not necessarily. A pipeline is useful even without them: it eliminates manual deployment and gives you fast rollback. We add tests gradually, starting with the scenarios that matter most to the business — checkout, payments, sign-up.
Who will maintain the pipeline after setup? Your team, using our documentation, or us as part of technical support.
Why Promodex
We build websites and applications ourselves — since 2015, with 750+ projects launched — so we set up automation from the perspective of the team that will be working with it every day. Everything is done by our in-house team, with no outsourcing. The result is a deployment process the whole team understands, not just one person, plus a clear description of what was set up and why.
