CI/CD
Some links on this page are affiliate links: we may earn a commission at no extra cost to you. Our approach
CI/CD turns a risky release into an ordinary event. Every change is tested, built and deployed the same way, and you gain the ability to fix things fast. ## The chain, step by step A good pipeline: linting and tests on every push, building the artefact, deploying to pre-production, validation, then production. Every step should be visible and its duration kept under control. ## Do not overcomplicate A pipeline that is too long or too fragile gets bypassed. A few solid tests and a simple deployment that works every time are better than an ambitious chain nobody dares to run. ## Security and reproducibility Secrets managed by the platform, dependencies scanned, reproducible Docker images: when well designed, CI/CD is also a security tool, not just a speed tool.When this guide is for you
- Every release is a manual, stressful operation
- A forgotten test has already caused a production outage
- You need to synchronise several environments (development, test, production)
- Several developers commit code and conflicts or regressions keep multiplying
- You want to deploy small changes often rather than big, rare versions
Step by step
- Auditing the current process — List the steps between development and release, identify those that are manual, long and error-prone. Prioritise what is repeated and costly.
- Automated tests — Start with unit and integration tests on critical journeys. Without tests, an automated deployment spreads errors faster.
- Integration pipeline — Configure the build and test on every code push or pull request, with a clear status that blocks merging.
- Deployment by environment — Deploy automatically to pre-production, validate, then to production. Plan a progressive rollout or a rollback procedure in case of problems.
- Security and measurement — Add dependency vulnerability scanning, secret management and pipeline measurement (duration, failure rate, deployment time).
What it costs (in MAD)
| Service | Indicative price | Good to know |
|---|---|---|
| Setting up a simple pipeline | 8,000 – 25,000 MAD (≈ 730 – 2,300 €) | Tests, build and deployment to one environment |
| Full pipeline with pre-production | 20,000 – 40,000 MAD (≈ 1,800 – 3,700 €) | Environments, secrets and rollback |
| Hosted CI/CD platform | 0 – 1,500 MAD / month (≈ 0 – 140 €) | GitHub Actions or GitLab, depending on run volume |
| Writing automated tests | 5,000 – 30,000 MAD (≈ 450 – 2,800 €) | Depending on coverage and complexity |
| Monthly DevOps support | 2,000 – 15,000 MAD / month (≈ 180 – 1,400 €) | Maintenance, improvement and fixes |
Indicative ranges for the Moroccan market in 2026, excluding tax. Prices vary with scope and provider.
Mistakes to avoid
- Automating deployment without any automated tests
- Storing passwords and API keys in plain text in the repository or script
- Deploying straight to production without pre-production or validation
- Making the pipeline slow (over thirty minutes), which encourages people to bypass it
- Not planning a rollback and having to improvise during an outage
Frequently asked questions
What is the difference between CI and CD?
Continuous integration (CI) automatically tests and builds every change. Continuous deployment (CD) goes further and releases to production automatically. Continuous delivery automates everything except the decision to release.
Do you need tests to start?
Yes, at least on critical journeys: login, payment, form. Without tests, automation turns a mistake into a faster incident. You can start with a few well-chosen tests.
How much does a CI/CD pipeline cost?
GitHub Actions or GitLab offer generous free quotas for an SME. Setup and writing the tests make up most of the cost, and monthly support gives the whole thing lasting value.
CI/CD or direct FTP to the server?
Direct FTP works for a static site and a single developer, but leaves no trace, no verification and no reproducibility. CI/CD is the standard as soon as there are several environments or several people.
How should secrets (keys, passwords) be managed?
Store them in the platform's secret manager (environment secrets), never in the code. Rotation and separating keys between environments reduce the risk if one leaks.
Updated on
Related guides
Version française: /services/devops-securite/ci-cd/ · AR · NL