Continuous integration publishes a change to your website by following the same route every time: the code is written in a separate branch, an automated system builds and tests it, a preview is generated, someone reviews it and only then does it go to production. If something fails, the change stops before it reaches your customers.
The 6 steps to publish a change to your website with continuous integration
Every change goes through six fixed steps, and each one leaves a record: a price, a legal text or a new field in the form. As an example, imagine you want to change the phone number in the footer and add a ‘Company’ field to the contact form.
1. A dedicated branch for the change
The developer creates an isolated copy of the code, called a branch, with a descriptive name such as contact-company-field. The live website is left untouched. If something urgent needs fixing tomorrow, it is done in another branch without mixing in half-finished work.
2. Commit and push to the repository
Each modification is saved with a clear message (‘Add Company field to the form’) and pushed to the repository. That way there is a record of who changed what and when, and any previous version can be recovered.
3. Build and automated checks
When the branch is pushed, a continuous integration server runs a list of tasks: it installs dependencies, builds the website and runs the configured checks. If just one fails, the process is flagged red and the change goes no further.
4. Preview at a temporary address
If everything passes green, a version of the website with the change applied is generated at a temporary address. You can open it on your phone, fill in the form and check that the new phone number displays correctly, without your customers seeing anything.
5. Review and merge into the main branch
Another team member reviews the code and you approve the preview. With both approvals, the branch is merged into the main branch, which is the one that represents the live website.
6. Deployment to production
The merge triggers the automatic deployment. The server builds again from scratch and publishes the new version, with no copying files by hand over FTP and no live editing.
What the continuous integration pipeline checks before publishing
The pipeline is the list of checks that runs on every change, and what it contains is decided when the project is set up. These are the usual ones on a professional website:
| Check | What it detects | Website example | If it fails |
|---|---|---|---|
| Build | Syntax errors or missing files | A deleted image that a page still uses | No preview is generated |
| Linter and formatting | Inconsistent code or obvious errors | A misspelt variable in the form | The exact line is flagged |
| Automated tests | Functions that stop behaving as before | The form stops sending emails | The merge is blocked |
| Links and routes | Pages that return a 404 error | A menu link to a renamed section | List of broken links |
| Size and performance | Oversized files that slow down loading | A photo uploaded without compression | Warning before publishing |
Tests deserve a chapter of their own; what matters here is the principle: the machine repeats the same checks on every change, without getting tired or skipping steps.
How to undo a change published with continuous integration
Each deployment creates a complete, independent version of the website, so going back to the previous one simply means reactivating it. There is nothing to rebuild and no need to hunt for which file was modified.
There are two ways to do it:
- Immediate rollback. From the deployments dashboard, the previous version is marked as active. This is for when the problem is visible and urgent, such as a blank page.
- Revert the change. A commit is created that cancels out exactly the problematic change and goes through the same pipeline. It is the right option when the error is minor and you want a record of the fix.
The difference from a manual deployment is significant. If someone uploads files over FTP and something breaks, nobody knows for sure what the previous state was. With continuous integration, the history always answers that question.
Continuous integration on a corporate website, an online shop or a bespoke CRM
The six-step route is the same on any project, but the checks change depending on what is at stake.
- Corporate website or landing page. Build, links and performance are enough. In a custom web design project, the pipeline is set up at the start and protects the site from the very first release.
- Online shop. Tests for the basket and the payment gateway in test mode are added, so that a design change does not stop you taking payments.
- CRM or ERP. Database migrations come into play: changes to tables that must be applied in order and without losing records. With custom CRM and applications, integrations and process automation are also checked, such as sending invoices or email alerts.
In management software for SMEs, an error does not break a page: it can duplicate orders or leave a salesperson without access. That is why the pipeline is stricter and the preview is tested with dummy data, never with real data.
4 continuous integration questions to ask your web provider
Your provider should answer these questions plainly before you sign:
- Where is the repository? Ideally, it should be in your name. At Sinergia Barcelona the code belongs to the client and we do not work with generic templates.
- Can I see changes before they are published? The answer should be a preview for every change.
- How do you roll back? Ask them to show you in the deployments dashboard.
- Who approves publishing? There must be at least one human review before production.
If you would like us to assess your current website or a new project with this workflow included, you can request an online quote.
Frequently asked questions
Does continuous integration make website development more expensive?
Continuous integration is configured once at the start of the project and then runs on its own with every change. At Sinergia Barcelona it is part of development, with no separate line item. Changes outside the agreed scope are charged at €45-60/h, like any other modification.
Can I see the changes to my website before they go live?
Changes to a website with continuous integration generate a preview at a temporary address. You can open it on your computer or phone, check the copy and test forms. Nothing reaches production until the review is approved and the branch is merged.
What happens if a change breaks the website after it is published?
A change that breaks the website after publication is undone by reactivating the previous version from the deployments dashboard. Every release is stored as a complete version, so the website returns to its previous state while the error is fixed calmly in a separate branch.
Is continuous integration worth it for a simple landing page?
A simple landing page also benefits from continuous integration, albeit with fewer checks: build, links and image size. It prevents launching a campaign with a broken button or a huge photo, and lets you change copy without worry while the campaign runs.