What is a CI/CD pipeline, in plain words?
A CI/CD pipeline is a script that runs automatically whenever code changes, checking it and shipping it the same way every time. CI (continuous integration) means every change is built and tested as soon as it is pushed; CD (continuous delivery or deployment) means passing changes are released to staging and production by the pipeline rather than by hand.
Think of it as a checklist the computer follows so people do not have to remember it. Before a pipeline, a release might mean a developer pulling the latest code on their laptop, running a build, zipping files, uploading them over FTP, and clearing a cache. Each of those steps is a chance to forget something. After a proper CI/CD pipeline setup, the developer opens a pull request, the pipeline runs tests and posts a preview link, a reviewer approves, and merging releases the change.
Jenkins’ documentation puts it neatly: a pipeline’s code defines the entire build process, typically with stages for building, testing and delivering the application. That definition lives in a file inside your repository, such as a workflow file for GitHub Actions, a .gitlab-ci.yml for GitLab or a Jenkinsfile, so the release process is versioned and reviewed like the rest of the code.
Why do releases keep breaking production, and will CI/CD fix it?
Releases usually break production because changes reach customers without being tested in a production-like place, because each release is done slightly differently, or because there is no fast way back. A CI/CD pipeline setup attacks all three causes, though it cannot make up for having no tests at all.
The patterns are familiar. A feature works on the developer’s machine but fails on the server because of a different Node or PHP version. A database change runs before the code that needs it. Someone deploys from the wrong branch. A hotfix goes out at night with no review. A dependency update quietly changes behaviour. None of these is a skill problem; they are process gaps, and an automated pipeline closes them by doing the same steps in the same clean environment every time.
What a pipeline will not do is invent quality. If the app has no automated tests, the pipeline can build and deploy it reliably but cannot tell good code from broken code. That is why most of our CI/CD pipeline setup projects include writing a small, targeted test suite for the flows that matter most, rather than aiming for a coverage percentage.
- Environment drift: fixed by building in the same container image every time.
- Wrong branch or forgotten step: fixed by releases only from the pipeline.
- Untested changes: fixed by required checks before merge.
- No way back: fixed by versioned builds and a rollback job.
Use the CI tool that lives where your code already lives: GitHub Actions for GitHub repositories, GitLab CI for GitLab, and Jenkins only when you need full self-hosted control or already run it. Switching code hosts just to get a different CI tool is rarely worth the disruption.
GitHub Actions workflows are YAML files in the repository, with a large marketplace of reusable actions. GitHub’s billing documentation states that Actions usage is free for public repositories on standard GitHub-hosted runners and free on self-hosted runners, while private repositories get an included monthly allowance of minutes, and jobs on Windows and macOS runners cost more than Linux ones. That last point matters for iOS builds, which need macOS.
GitLab CI is configured with a .gitlab-ci.yml file at the root of the project; GitLab’s docs describe runners as the agents that run your jobs, on physical machines or virtual instances. It is a strong choice when you want code, issues, container registry and pipelines in one self-hostable product.
Jenkins is the veteran: a pipeline defined in a Jenkinsfile, huge plugin ecosystem, runs anywhere you install it. It suits teams with on-premise requirements or existing Jenkins servers, but someone must patch and maintain the server and its plugins, which is real ongoing work for a small team. For most small and mid-sized projects we recommend a hosted tool with one or two self-hosted runners if build minutes get expensive.
Stage one: build, lint and type-check on every push
The first stage of any CI/CD pipeline setup runs on every push and answers one question in a few minutes: does this change even build? It installs dependencies from a lock file, runs the linter and type checker, and produces a build artefact.
Speed is the design goal here. If the first stage takes twenty minutes, developers stop waiting for it and merge anyway. We cache dependencies between runs, split independent checks into parallel jobs, and pin the runtime version (Node, PHP, Python, Java or .NET) to exactly what production uses. The build runs inside a container image where possible, so “it worked on my machine” stops being a possible excuse.
The artefact produced here is what gets deployed later, not rebuilt at each stage. Building once and promoting the same artefact through staging to production means the thing you tested is exactly the thing customers get. For container projects the artefact is an image tagged with the commit hash; for a static site it is a folder of files; for a mobile app it is a signed build.
- Install from the lock file only, never floating versions.
- Lint and type-check before anything slow runs.
- Tag every artefact with the commit it came from.
- Fail loudly with a readable message, not a wall of logs.
Stage two: which automated tests should a pipeline run?
Run fast unit tests on every push, integration tests against a real database on every pull request, and a handful of end-to-end browser tests on the flows that earn money. That mix catches most breakages without making the pipeline slow.
We usually begin by asking which failures have hurt you in the past. If checkout broke twice last year, checkout gets an end-to-end test first. If a reports page returned wrong totals, the calculation gets unit tests. This targeted approach gives far more protection per hour than trying to cover everything evenly.
Flaky tests, the ones that fail randomly, are the silent killer of CI. Once people learn to click “re-run” without reading the failure, the pipeline stops protecting anyone. We quarantine flaky tests, fix their causes (usually timing or shared test data), and only then make them required.
The test stage is also where page speed and search health can be protected. A Lighthouse CI check can fail a pull request that makes the home page heavier than an agreed budget, and a simple crawler can catch broken links, missing titles or an accidental noindex tag before release. For sites that depend on organic traffic, this keeps Core Web Vitals and SEO work from being undone by a routine release. Our speed optimisation page covers the budgets themselves.
Stage three: staging and preview environments
A staging environment is a production-like copy where every merged change lands first; a preview environment is a short-lived copy created for a single pull request. Staging catches integration problems, and previews let non-developers review a change before it is merged.
Staging should match production in everything except scale and real customer data: same runtime versions, same type of database, same environment variables with test values, and the same deploy method. If staging is set up differently, it will miss the problems that only production shows, and people will stop trusting it.
Previews are the part clients love most. When a developer opens a pull request, the pipeline deploys that branch to its own URL and posts the link on the pull request. The product owner clicks through the new checkout page on their phone, leaves a comment, and the preview is torn down when the branch merges. For front ends this is easy on most modern hosts; for full-stack apps we spin up the API and a seeded database alongside, which takes more care but saves many rounds of screenshots over WhatsApp.
Test data needs thought. Previews and staging should use seeded or anonymised data, never a raw copy of production, especially where personal data is involved. We write seed scripts so every preview starts from the same known state.
Stage four: releasing to production without downtime
Production releases should need a named approval, deploy the exact artefact already tested on staging, and switch traffic in a way that avoids downtime, typically blue-green, rolling or canary releases. After the switch, automated smoke tests confirm the key pages and endpoints respond.
In GitHub Actions and GitLab, environments can require specific people to approve before a job touching production runs, and that approval is recorded against the release. This replaces the shared server password that half the team used to know.
Blue-green means running the new version alongside the old one and moving traffic across in one switch, keeping the old version ready. Rolling releases replace instances a few at a time. Canary releases send a small share of traffic to the new version first and widen it if error rates stay normal. For most small teams, blue-green or rolling is enough; canary is worth it when you have enough traffic to see a problem in a small slice.
We also add post-deploy checks: hit the health endpoint, load the home page and a logged-in page, run one synthetic purchase or form submission where safe, and watch the error rate for a few minutes. If any check fails, the pipeline alerts the team and, where configured, starts the rollback on its own.
How do automated rollbacks work in a CI/CD pipeline?
An automated rollback redeploys the last known-good artefact when post-release checks fail or when someone presses the rollback button. It works because every release is a versioned, immutable build, so going back means switching to an earlier version rather than rebuilding old code.
The part people forget is the database. Code can be rolled back in seconds; a database migration that dropped a column cannot. That is why rollback planning belongs in the CI/CD pipeline setup from day one, not added after the first bad night. We use the expand-and-contract pattern: add new columns or tables first and deploy code that works with both old and new shapes, then remove the old shape in a later release once nothing depends on it. Every release stays reversible.
For mobile apps, rollback looks different. You cannot pull a version back off users’ phones, so the protection comes earlier: staged rollouts in Play Console that start with a small percentage of users, TestFlight testing before App Store release, and feature flags that switch off a broken feature remotely without a new build.
- Keep at least the last few production artefacts available.
- Make database changes backward compatible for one release.
- Use feature flags for risky features, so a rollback is a toggle.
- Practise a rollback on staging before you ever need one in production.
Keeping secrets and credentials safe in your CI/CD pipeline setup
Pipelines hold the keys to production, so they must be treated as sensitive systems: secrets stored in the CI tool’s encrypted secret store or a cloud secret manager, short-lived cloud credentials instead of long-lived keys, least-privilege deploy roles and protected branches.
A common mistake is a single powerful cloud access key pasted into CI settings years ago and never rotated. Modern CI tools can exchange a short-lived identity token with AWS, Google Cloud or Azure at run time (OpenID Connect), so no permanent key exists to leak. We set that up wherever the cloud supports it, and scope the role so the pipeline can deploy one application and nothing else.
Supply-chain safety matters too. Third-party actions and plugins run with your pipeline’s permissions, so we pin them to specific versions, prefer well-maintained ones, and review what they can access. Dependency scanning flags known vulnerable packages on each pull request, and container images are scanned before they are pushed.
Finally, pull requests from forks or outside contributors should never receive production secrets. Branch protection rules make sure only reviewed code on the main branch can trigger a production deploy. These rules are simple to switch on and are the difference between a pipeline that protects you and one that is a back door.
Mobile app CI/CD with Fastlane: Android and iOS releases without a release laptop
Fastlane automates building, signing and uploading Android and iOS apps, so store releases run in CI instead of on one developer’s laptop. Its documentation calls it the easiest way to automate beta deployments and releases for iOS and Android apps, handling screenshots, code signing and publishing.
iOS signing is where most teams get stuck. Fastlane’s match tool creates the required certificates and provisioning profiles and stores them in a separate encrypted Git repository, Google Cloud Storage or Amazon S3, so every CI run and every developer uses the same signing identity. On Android, the upload key is stored as an encrypted CI secret and Play App Signing holds the app signing key on Google’s side.
A typical mobile pipeline we set up: on each pull request, run Dart or JavaScript tests and a debug build; on merge, build a signed release, bump the build number, upload Android to an internal or closed testing track and iOS to TestFlight, and post the build notes to your team chat. Promotion to production stays a deliberate, approved step.
Play Console rules shape the pipeline too. Google’s developer documentation says that from 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, and Google’s Play Console help states that new personal developer accounts need at least 12 testers opted in to a closed test for the preceding 14 days before applying for production access. We build those testing tracks into the pipeline from the start. More on the app side on our Ionic developer and React Native developer pages.
How much does CI/CD pipeline setup cost?
With our freelance team, a full CI/CD pipeline setup across environments starts at ₹60,000 (US$900), and a narrow job on one repository is quoted after we read the code. Pipeline upkeep sits inside maintenance from ₹8,000/mo once the 2 free months end.
Other providers’ quotes vary widely for CI/CD work, mostly because the phrase covers everything from a ten-line deploy script to a multi-service platform with previews and mobile releases. When comparing quotes, check what is actually included, because the expensive parts are rarely the YAML file itself.
- Repositories and services: each needs its own build, tests and deploy.
- Test writing: existing tests are cheap to wire in; missing tests take time to write.
- Preview environments: easy for front ends, more work for full stacks with databases.
- Database migrations: making releases reversible needs code changes, not only pipeline changes.
- Mobile: iOS signing, Fastlane lanes and store tracks add a distinct chunk of work.
- Runners: hosted runners cost per minute beyond the free allowance; self-hosted runners need a machine and upkeep.
Your own running costs are separate from our fee: runner minutes above the free allowance, macOS minutes for iOS builds, preview hosting, and the US$99 yearly Apple Developer Program fee if you publish on iOS. We estimate these in the quote so the monthly number is known before you commit.
How long does it take to set up a CI/CD pipeline?
A basic build-and-deploy pipeline for one web repository can be running within the first week; a complete CI/CD pipeline setup with tests, staging, previews, approvals, rollback and mobile releases usually takes three to six weeks, depending on how much test writing is needed.
The first days go on reading the repository and current release steps, then writing them down honestly, including the manual fixes someone does after every deploy. That list becomes the pipeline’s specification. Next comes the build stage and staging deploy, because they give immediate value. Tests and previews follow, then the production release path with approval and rollback, then mobile lanes if you have an app.
We run the new pipeline alongside the old release method for a couple of releases before switching off manual deploys completely. That overlap catches forgotten steps, such as a cache that needed clearing or a cron job that needed restarting, without risking a bad production release. The timeline table below shows a typical order of work.
CI/CD pipeline setup for Indian teams on shared hosting, VPS or cPanel
You do not need Kubernetes or an expensive cloud to benefit from CI/CD. Many Indian businesses run on a VPS or shared hosting with cPanel, and a pipeline can still build, test and deploy there over SSH or SFTP with a release-folder switch that avoids half-uploaded sites.
The pattern we use on a budget VPS: the pipeline builds the app in CI, uploads it to a new timestamped folder on the server, runs migrations, switches a symlink to the new folder and reloads the web server. Rolling back is pointing the symlink at the previous folder. It is simple, cheap and far safer than editing live files.
For teams watching every rupee, a self-hosted runner on an inexpensive VPS avoids paying for hosted minutes on private repositories, at the cost of keeping that machine patched. We usually recommend hosted runners until build minutes become a real line in the budget.
India-specific flows deserve tests of their own. If your checkout offers UPI or card payments, the pipeline should run the checkout against the payment provider’s sandbox on staging, and GST invoice generation should have unit tests because rounding and tax splits are easy to break silently. Apps aimed at budget Android phones benefit from a test run on a low-memory emulator profile too.
Choosing someone for CI/CD pipeline setup, and what you should own afterwards
Choose someone who asks about your current release steps and past incidents before naming tools, who keeps every pipeline file in your repository, and who leaves you able to change it. You should own the repository, the CI account, the runners, the secrets and the signing keys.
Useful questions when you speak to anyone offering CI/CD pipeline setup: how will a database change be rolled back? Where will iOS signing certificates live? What happens to the pipeline when a third-party action is abandoned? How long will a typical run take? Can you show a sample pipeline file with client details removed?
- Red flag: deploy keys created under the developer’s personal account.
- Red flag: signing keys or keystores kept only on someone’s laptop.
- Red flag: tests marked “allowed to fail” so the pipeline always looks green.
- Red flag: a pipeline nobody else can read, with no README.
- Good sign: they propose running old and new release methods side by side first.
Our handover includes a README in the repository explaining every job, a recorded walkthrough of a release and a rollback, and a list of every secret the pipeline uses and where it lives. Payment is per approved milestone, by UPI or bank transfer in India, or by Wise, wire or PayPal in USD from abroad. Confidentiality and other contract points are agreed in your written quote; our general terms apply otherwise.
Worked example: a hypothetical Jaipur D2C brand with a web store and a Flutter app
Imagine a Jaipur home-decor brand with a Next.js storefront, a Node.js order API and a Flutter app, built by two developers who deploy by hand. Festive sales keep getting interrupted by broken releases, and the iOS app is built on one MacBook that only one person can use. This is an illustrative scenario, not a client.
Week one: we document the manual steps, move the repositories into a GitHub organisation owned by the brand, and set up builds with caching. Week two: staging deploys on every merge, seeded test data, and smoke tests on the product page, cart and order API. Week three: preview URLs for storefront pull requests so the founder can approve banners and product pages from a phone, plus end-to-end tests on checkout against the payment sandbox.
Week four: the production path, with approval from the founder or lead developer, blue-green release on the API and automatic rollback if the health check fails. Week five: Fastlane lanes for the Flutter app, with match holding iOS certificates in an encrypted repository and builds going to TestFlight and a Play closed track on every merge.
The result would be daytime releases before a sale, not midnight ones, and an app release that no longer depends on one laptop. A scope like this starts at ₹60,000; the final quote depends on the tests that need writing.
CI/CD pipeline setup for teams across India
We set up pipelines remotely for teams anywhere in India, in English or Hindi, with replies on WhatsApp seven days a week. No office visits are involved; access to your repository and CI tool is all we need.
Recent kinds of requests give a flavour: agencies in Jaipur and Surat that want previews to show clients, app teams in Lucknow and Bhubaneswar tired of building iOS on one Mac, SaaS builders in Chandigarh and Vadodara moving off FTP, edtech products in Nagpur and Visakhapatnam preparing for result-day traffic, and ecommerce teams in Mangaluru and Dehradun who need checkout tested before every sale. These describe typical needs by city, not named clients.
If you work with clients abroad, our white-label development page explains how we fit into an agency’s own process and tools.